Re: [jamboost] bjam crash information

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-07-07 02:43:13

Hi Beman,

Beman Dawes wrote:
> The problem is an access violation reading location 0x0000001c. It always
> happens at the same place in the code, line 570 of make1.c. The line of
> code reads:
>
> if (t->includes) {

That's interesting. The line of code in question is very new --- added for V2 
M5. So it's possibly a new bug. 

However, I have no idea how "t" can be incorrect here. Two considerations
1. The line 
t = t->original_target 
above may cause the problem. OTOH, t->original_target is always correctly
initialized.
2. There's something really wrong elsewhere.

I've just run bjam under valgrind on a certain test, and it reported a single 
use of uninitialized memory, which I've just fixed, but I don't think it could 
be the cause.

> Depending on the exact command line and the current state of targets and
> dependencies, the access violation usually happens several seconds after
> the start of the program but before any compiles start. At least once,
> however, some compiles and tests ran before the access violation happens.
>
> Please let me know what additional information is needed. Because the
> problem is reproducible under the debugger, it is easy to get more
> information.

Probably, the complete reproduction recipe is best. Reproduction recipe on 
Linux is just excellent.

If at all possible, running bjam under some memory checking tool would be 
great --- the address 0x0000001c looks clearly bogus and since it's not 0, 
situation like double-free is possible. (If I could reproduce this on Linux, 
I'll run under valgrind myself).

- Volodya