Automoc hanging for some FreeBSD users

[Thiago Macieira]

On Wednesday, 24 de November de 2010 19:01:22 Raphael Kubo da Costa wrote:
> Thread 2 (Thread 801c07300 (LWP 100509)):
> #0  0x0000000801065edc in select () from /lib/libc.so.7
> #1  0x0000000800e5d4e4 in select () from /lib/libthr.so.3
> #2  0x000000080081886f in qt_safe_select () from
> /usr/local/lib/qt4/libQtCore.so.4
> #3  0x00000008007cd42a in select_msecs () from
> /usr/local/lib/qt4/libQtCore.so.4
> #4  0x00000008007cd8ee in QProcessPrivate::waitForFinished () from
> /usr/local/lib/qt4/libQtCore.so.4
> #5  0x000000080078c21c in QProcess::waitForFinished () from
> /usr/local/lib/qt4/libQtCore.so.4
> #6  0x000000000040a520 in AutoMoc::echoColor (this=0x7fffffffe2d0,
> msg=@0x7fffffffd880) at
> /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:74
> #7  0x0000000000404c8c in AutoMoc::generateMoc (this=0x7fffffffe2d0,
> sourceFile=@0x801c15910, mocFileName=@0x801c15918)
>     at
>     /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:569
> #8  0x0000000000407b21 in AutoMoc::run (this=0x7fffffffe2d0) at
> /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:470
> #9  0x0000000000408c45 in main (argc=6, argv=0x7fffffffe3a0) at
> /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:114
> 
> Thread 1 (Thread 801c07c00 (LWP 100563)):
> #0  0x0000000801065edc in select () from /lib/libc.so.7
> #1  0x0000000800e5d4e4 in select () from /lib/libthr.so.3
> #2  0x00000008007cea93 in QProcessManager::run () from
> /usr/local/lib/qt4/libQtCore.so.4
> #3  0x00000008006fa649 in QThreadPrivate::start () from
> /usr/local/lib/qt4/libQtCore.so.4
> #4  0x0000000800e5b2be in pthread_getprio () from /lib/libthr.so.3
> #5  0x0000000000000000 in ?? ()
> Error accessing memory address 0x7fffffbff000: Bad address.

Thanks, but unfortunately it didn't help.

One thread is in waitForFinished: that means it's in a select call waiting for 
read on two file descriptors. One is the pipe from the sub-process, the other 
is a pipe to QProcessManager.

The other thread, the QProcessManager, is waiting for a wakeup from the 
SIGCHLD signal handler.

Now, it's stuck. It can be because:
1) the subprocess hasn't exited
2) the subprocess has exited but SIGCHLD wasn't handled
3) the subprocess has exited and SIGCHLD was handled, but not by 
QProcessManager signal handler 
4) QProcessManager's signal handler got SIGCHLD and wrote to QProcessManager's 
thread, but the thread did not wake up
5) the QProcessManager thread woke up but did not find the target QProcess to 
notify
6) QProcessManager found the target QProcess and notified it, but QProcess 
didn't wake up.

1, 2 and 3 are bugs outside of Qt -- either in the subprocess or in FreeBSD's 
signal delivery. 4 and 6 would be the same problem, but there's no reason why 
select(2) would not wake up, unless it's a FreeBSD bug. 5 would be a QProcess 
bug.
-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20101124/d6ee0bab/attachment.sig