Boost logo

Boost-Build :

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

 


Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk