sporadic bjam crashes on WinXP box
When I run Boost.Test unit test for 10 compilers in crashes sometimes (but quite regularly). How could I track the issue? Looks like it depend on amount target it actually need to update with current run. Gennadiy.
"Gennadiy Rozental" <gennadiy.rozental@thomson.com> writes:
When I run Boost.Test unit test for 10 compilers in crashes sometimes (but quite regularly). How could I track the issue? Looks like it depend on amount target it actually need to update with current run.
You could try rebuilding bjam with --debug and then looking at it with JIT debugging. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Gennadiy Rozental wrote:
When I run Boost.Test unit test for 10 compilers in crashes sometimes (but quite regularly). How could I track the issue? Looks like it depend on amount target it actually need to update with current run.
note: I also have some bjam crashes for gcc (on a Win2000 box). After successfully running it once for gcc, if I run it again, it'll crash. Best, John -- John Torjo Freelancer -- john@torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ Professional Logging Solution for FREE -- http://www.torjo.com/code/logging.zip (logging - C++) -- http://www.torjo.com/logview/ (viewing/filtering - Win32) -- http://www.torjo.com/logbreak/ (debugging - Win32) (source code available)
John Torjo wrote:
Gennadiy Rozental wrote:
When I run Boost.Test unit test for 10 compilers in crashes sometimes (but quite regularly). How could I track the issue? Looks like it depend on amount target it actually need to update with current run.
note: I also have some bjam crashes for gcc (on a Win2000 box). After successfully running it once for gcc, if I run it again, it'll crash.
You mean, you can reproduce it 100%? If so, can you produce stacktrace? Or better yet, get it to crash several times and see of stacktrace is the same? - Volodya
Vladimir Prus <ghost@cs.msu.su> writes:
John Torjo wrote:
Gennadiy Rozental wrote:
When I run Boost.Test unit test for 10 compilers in crashes sometimes (but quite regularly). How could I track the issue? Looks like it depend on amount target it actually need to update with current run.
note: I also have some bjam crashes for gcc (on a Win2000 box). After successfully running it once for gcc, if I run it again, it'll crash.
You mean, you can reproduce it 100%? If so, can you produce stacktrace? Or better yet, get it to crash several times and see of stacktrace is the same?
And after you're done collecting data, try renaming the .jamdeps file that's in your bin directory. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Vladimir Prus wrote:
John Torjo wrote:
Gennadiy Rozental wrote:
When I run Boost.Test unit test for 10 compilers in crashes sometimes (but quite regularly). How could I track the issue? Looks like it depend on amount target it actually need to update with current run.
note: I also have some bjam crashes for gcc (on a Win2000 box). After successfully running it once for gcc, if I run it again, it'll crash.
You mean, you can reproduce it 100%? If so, can you produce stacktrace? Or better yet, get it to crash several times and see of stacktrace is the same?
This happened to me about 2-3 weeks ago while trying to build win32gui (I use bjam to build it) - and it also happened when building for multiple compilers. Unfortunately, I was pressed for time, and ignored this error. I do know that it only happened after successfully building for gcc once, and then trying to do it again. I did try to reproduce it now, but can't do it. Anyway, if I get the crash again, I'll do as you sugested. Best, John -- John Torjo Freelancer -- john@torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ Professional Logging Solution for FREE -- http://www.torjo.com/code/logging.zip (logging - C++) -- http://www.torjo.com/logview/ (viewing/filtering - Win32) -- http://www.torjo.com/logbreak/ (debugging - Win32) (source code available)
participants (4)
-
David Abrahams -
Gennadiy Rozental -
John Torjo -
Vladimir Prus