Re: [Boost-build] bjam bug invoking codeworker

Subject: Re: [Boost-build] bjam bug invoking codeworker
From: Fabien CHÊNE (fabien.chene_at_[hidden])
Date: 2009-10-26 11:44:49

2009/10/26 Vladimir Prus <ghost_at_[hidden]>:
> On Monday 26 October 2009 Fabien CHÊNE wrote:
>
>> [...]
>> >> 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?
>>
>> Definitely.
>>
>> > 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"
>>
>> There is only one thread in codeworker, stucked on a tcsetattr call:
>>
>> (gdb) bt
>> #0  0x002ca7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
>> #1  0x00bbf400 in tcsetattr () from /lib/tls/libc.so.6
>> #2  0x0808d4bf in initKeyboard () at CGRuntime.cpp:115
>> #3  0x082258ca in Workspace (this=0xbff323d0) at Workspace.cpp:58
>> #4  0x0808e595 in CodeWorker::CGRuntime::entryPoint (iNargs=4,
>>     tsArgs=0xbff32564, executeFunction=0x0) at CGRuntime.cpp:383
>> #5  0x08241c98 in main ()
>> (gdb) f 2
>> #2  0x0808d4bf in initKeyboard () at CGRuntime.cpp:115
>> 115                   tcsetattr(0, TCSANOW, &new_settings);
>> (gdb) l
>> 110                   new_settings.c_lflag &= ~(ICANON | ECHO);
>> 111                   new_settings.c_iflag &= ~(ISTRIP | IGNCR | ICRNL | INLCR | IXOFF | IXON);
>> 112                   new_settings.c_cc[VMIN] = 0;
>> 113                   new_settings.c_cc[VTIME] = 0;
>> 114   #ifndef CODEWORKER_GNU_READLINE
>> 115                   tcsetattr(0, TCSANOW, &new_settings);
>> 116   #endif
>> 117                   signal(SIGINT, catch_sig);
>> 118                   signal(SIGHUP, catch_sig);
>> 119                   signal(SIGTERM, catch_sig);
>>
>> (gdb) set print pretty on
>> (gdb) p new_settings
>> $2 = {
>>   c_iflag = 0,
>>   c_oflag = 1,
>>   c_cflag = 191,
>>   c_lflag = 35377,
>>   c_line = 0 '\0',
>>   c_cc = "\003\034\000\000\004\000\000\000\021\023\032\000\022\017\027\026",
>> '\0' <repeats 15 times>,
>>   c_ispeed = 15,
>>   c_ospeed = 15
>> }
>
> If it's really stuck there, e.g. it remains there after "continue + Ctrl-C" in
> GDB,

Confirmed, we are still waiting for tcsetattr to give up after
"continue, Ctrl-C".
CodeWorker can be compiled with the macro CODEWORKER_GNU_READLINE -- it avoids
tcsetattr; doing that, everything works fine.

> it seems that tcsetattr for some reason hangs if stdin is not a terminal.
> And when run by bjam, it's naturally not a terminal. I don't immediately
> know why this should be a problem, I'll check.

Thanks !

-- 
Fab