From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-03-01 02:13:22
On Monday 28 February 2005 22:03, Joao Abecasis wrote:
> Rene Rivera wrote:
> > It's possible that it's a stack limit problem. I know I had a similar
> > problem on OpenBSD where the process stack is set rather low. Have you
> > tried increasing it?
> In spite of increasing the stack size with 'ulimit -S value' and 'ulimit
> -s value' up to 524288 kB, I only managed to increase the time it takes
> for bjam to segfault.
> The gdb backtrace is similar up to where I can get it... at some point
> after ~600,000 stack frames gdb gets killed attempting to go through
> the backtrace.
> For some reason bjam appears to enter an infinite cycle... btw, this is
> using bbv2 (--v2 command line option).
Indeed, when bjam enters an infinite cycle, this usually ends up with
segmentation fault when bjam runs out of stack. Can you lower the ulimit
again and run bjam with the -d+5 option. This way we can see what Boost.Build
function loops. Off-hand, I don't know why it would hang on macos, but not on
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