Boost logo

Boost-Build :

Subject: Re: [Boost-build] bjam bug invoking codeworker
From: Vladimir Prus (ghost_at_[hidden])
Date: 2009-10-26 07:25:49


On Monday 26 October 2009 Fabien CHÊNE wrote:

> > What system are you on? On Linux, using SVN HEAD, debug build
> > works just fine. Could you either have an incompetely checkout,
> > or somehow passed the source via Windows, which then broke
> > capitalization of file name and convered Jambase into jambase?
>
> Today, I am able to build the debug version ... What was wrong, I don't know.
> Then I have caught a backtrace for te initial broblem:
>
> #0 0x00a5c7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
> #1 0x00b3aa0d in ___newselect_nocancel () from /lib/tls/libc.so.6
> #2 0x0805ee19 in exec_wait () at execunix.c:470
> #3 0x0805e8ff in exec_cmd (
> string=0xa10a0f8 "\n
> /continuus/fc01260/test/CW/CodeWorker4_5_1/codeworker dummy.cws
> bin/gcc-3.4.6/debug/toto.gen -nologo ;\n",
> func=0x80530a7 <make_closure>, closure=0x9fac850, shell=0x0,
> action=0x9e5ecc0 "Jamfile</continuus/fc01260/test>.add-out-suffix",
> target=0x9d0f2d0 "bin/gcc-3.4.6/debug/toto.gen") at execunix.c:328
> #4 0x08052a3e in make1c (pState=0x9c92d50) at make1.c:532
> #5 0x08052392 in make1 (t=0x9facb10) at make1.c:229
> #6 0x08050ffe in make (n_targets=1, targets=0x9d0e6b8, anyhow=0) at make.c:167
> #7 0x0804f577 in main (argc=0, argv=0xbff8f0f8,
> arg_environ=0xbff8f0fc) at jam.c:515
>
> bjam is stucked line 470:
>
> 455 if ( 0 < globs.timeout )
> 456 {
> 457 /* Force select() to timeout so we can terminate expired processes.
> 458 */
> 459 tv.tv_sec = select_timeout;
> 460 tv.tv_usec = 0;
> 461
> 462 /* select() will wait until: i/o on a descriptor, a signal, or we
> 463 * time out.
> 464 */
> 465 ret = select( fd_max + 1, &fds, 0, 0, &tv );
> 466 }
> 467 else
> 468 {
> 469 /* select() will wait until i/o on a descriptor or a signal. */
> 470 ret = select( fd_max + 1, &fds, 0, 0, 0 );
> 471 }
>
> Any ideas ?
> Can it be a bug in CodeWorker ?

Not clear yet. When the hang happens, is there still a codeworker process?
Can you attach to it with gdb, and get backtrace? Please check if it has
multiple threads -- using 'info thread' -- if so, use "thread apply all bt"
to get backtrace as opposed to regular "bt"

I see two possible reasons:

        - somehow, bjam does not drain either stdout or stderr of the spawned process,
        so the process is stuck writing to a pipe that has no free space
        - bjam misses process exit

- 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