Created attachment 61311 [details] Correctly check cmake QProcess start / Fixes automoc4 freeze under FreeBSD Version: 4.6 (using KDE 4.6.4) OS: FreeBSD Automoc sometimes freezes under FreeBSD. It appears to happen with the QProcess under echoColor. The attached patch fixes the problem. Reproducible: Always Steps to Reproduce: # cd /usr/ports/games/kdegames4 # make Actual Results: Port stalls while building Expected Results: Port completes build dragon# gdb `which automoc4` GNU gdb 6.1.1 [FreeBSD] (gdb) attach 24682 (gdb) info thr 2 Thread 802c07400 (LWP 101969/initial thread) 0x000000080165080c in select () from /lib/libc.so.7 * 1 Thread 802c08800 (LWP 102119/automoc4) 0x000000080165080c in select () from /lib/libc.so.7 (gdb) bt #0 0x000000080165080c in select () from /lib/libc.so.7 #1 0x0000000800a54f3d in QProcessManager::run (this=0x800e1e600) at io/qprocess_unix.cpp:245 #2 0x000000080094e84e in QThreadPrivate::start (arg=0x800e1e600) at thread/qthread_unix.cpp:320 #3 0x000000080229a224 in pthread_getprio () from /lib/libthr.so.3 #4 0x0000000000000000 in ?? () Error accessing memory address 0x7fffffbfe000: Bad address. (gdb) thr 2 [Switching to thread 2 (Thread 802c07400 (LWP 101969/initial thread))]#0 0x000000080165080c in select () from /lib/libc.so.7 (gdb) bt #0 0x000000080165080c in select () from /lib/libc.so.7 #1 0x0000000800ab66fc in qt_safe_select (nfds=15, fdread=0x7fffffffc780, fdwrite=0x0, fdexcept=0x0, orig_timeout=0x0) at kernel/qcore_unix.cpp:82 #2 0x0000000800a52848 in select_msecs (nfds=15, fdread=0x7fffffffc780, fdwrite=0x0, timeout=-1) at io/qprocess_unix.cpp:880 #3 0x0000000800a538b4 in QProcessPrivate::waitForStarted (this=0x802cff300, msecs=-1) at io/qprocess_unix.cpp:913 #4 0x0000000800a07377 in QProcess::waitForStarted (this=0x7fffffffc900, msecs=-1) at io/qprocess.cpp:1665 #5 0x0000000800a07418 in QProcess::waitForFinished (this=0x7fffffffc900, msecs=-1) at io/qprocess.cpp:1735 #6 0x000000000040a800 in AutoMoc::echoColor (this=0x7fffffffd4c0, msg=@0x7fffffffca70) at /tmp/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:74 #7 0x0000000000404c9c in AutoMoc::generateMoc (this=0x7fffffffd4c0, sourceFile=@0x802c1cd10, mocFileName=@0x802c1cd18) at /tmp/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:569 #8 0x0000000000407b31 in AutoMoc::run (this=0x7fffffffd4c0) at /tmp/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:470 #9 0x0000000000408c55 in main (argc=6, argv=0x7fffffffd598) at /tmp/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:114 (gdb) The program is running. Quit anyway (and detach it)? (y or n) y Detaching from program: /usr/local/bin/automoc4, process 24682 dragon# gdb `which automoc4` GNU gdb 6.1.1 [FreeBSD] (gdb) attach 24683 (gdb) info thr Cannot get thread info: invalid key (gdb) bt #0 0x00000008022a195c in pthread_kill () from /lib/libthr.so.3 #1 0x000000080229bcac in pthread_getschedparam () from /lib/libthr.so.3 #2 0x000000080229ff5a in pthread_mutex_getprioceiling () from /lib/libthr.so.3 #3 0x00000008022a0435 in pthread_mutex_lock () from /lib/libthr.so.3 #4 0x000000080164ff9e in flockfile () from /lib/libc.so.7 #5 0x0000000801625ee5 in fileno () from /lib/libc.so.7 #6 0x0000000800a53d79 in QProcessPrivate::execChild (this=0x802cff300, workingDir=0x0, path=0x0, argv=0x802c17840, envp=0x0) at io/qprocess_unix.cpp:712 #7 0x0000000800a56c33 in QProcessPrivate::startProcess (this=0x802cff300) at io/qprocess_unix.cpp:665 #8 0x0000000800a06eb8 in QProcess::start (this=0x7fffffffc900, program=@0x7fffffffd4e8, arguments=@0x7fffffffc8f0, mode=@0x7fffffffc910) at io/qprocess.cpp:1960 #9 0x000000000040a7f2 in AutoMoc::echoColor (this=0x7fffffffd4c0, msg=@0x7fffffffca70) at /tmp/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:73 #10 0x0000000000404c9c in AutoMoc::generateMoc (this=0x7fffffffd4c0, sourceFile=@0x802c1cd10, mocFileName=@0x802c1cd18) at /tmp/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:569 #11 0x0000000000407b31 in AutoMoc::run (this=0x7fffffffd4c0) at /tmp/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:470 #12 0x0000000000408c55 in main (argc=6, argv=0x7fffffffd598) at /tmp/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:114 (gdb) The program is running. Quit anyway (and detach it)? (y or n) y Detaching from program: /usr/local/bin/automoc4, process 24683
this patch is bogus. waitForFinished() implies waitForStarted(), so the only thing you change is the timeout on waitForStarted().
Although waitForFinished() implies waitForStarted(), waitForFinished() also creates a QElapsedTimer before calling waitForStarted(). At a guess QElapsedTimer creates a separate thread. FreeBSD is rather sensitive when it comes to mixing threads and forks. This test has been tested by multiple people at kde-freebsd@ and does have a definite change in the behavior of automoc.
how about properly investigating rather than guessing? and if this is indeed a problem in qt, how about fixing it instead of working around in kde?
I looked at the implementation of QElapsedTimer and it does not use any threads, however QProcess for unix does. Looking at the traceback from the second automoc4 instance: #0 0x00000008022a195c in pthread_kill () from /lib/libthr.so.3 #1 0x000000080229bcac in pthread_getschedparam () from /lib/libthr.so.3 #2 0x000000080229ff5a in pthread_mutex_getprioceiling () from /lib/libthr.so.3 #3 0x00000008022a0435 in pthread_mutex_lock () from /lib/libthr.so.3 #4 0x000000080164ff9e in flockfile () from /lib/libc.so.7 #5 0x0000000801625ee5 in fileno () from /lib/libc.so.7 it looks like automoc4 encounters a deadlock while trying to get the fileno() of stdout (execChld in qprocess_unix.cpp). As far as I know (another guess) all FILE locks should be released in the child instance of a fork, and my brief attempts to verify that confirms. I do not know how a FILE could be locks at that stage in a child of a fork. While reading through qprocess_unix.cpp I saw the signal handler uses a fprintf() function. That function does not appear in the list of functions that can be safely called from "signal-catching functions" from sigaction(2) man pages. fprintf does eventually call flockfile() in its implementation in FreeBSD, leading me to wonder if this could be the cause of the problem?
Does this also happen with the automoc version which doesn't use Qt ? If not, maybe we should merge that branch into master. https://projects.kde.org/projects/kdesupport/automoc/repository/show?rev=no-qt Alex
I had a look at QProcess and it is not POSIX compliant. The SIGCHLD handler calls functions that are not allowed from a signal handler (according to sigaction(2), section NOTES). FreeBSD has a tendency to trigger such bugs however I am no longer able to reproduce this. I will try and give the no-qt branch a test run and report back my results. I am willing create a patch to "fix" this issue, if someone is willing to upstream the patch?
a fix for qprocess (or at least a precise bug report) would be most welcom
Having a closer look at the signal handler I see it uses qt_safe_write, which calls QT_WRITE, which is originally defined as ::write. Looking at sigaction(2) write(2) is on the list of acceptable functions. It appears this is a FreeBSD specific error and that I incorrectly diagnosed the problem (again). Apologies. It is not apparent to me why Qt uses a pipe and not wait(2) (or some wait variant). P.S. I'm currently running a build with automoc4-noqt and will report back shortly...
I can confirm that automoc4-noqt does not introduce any regressions when used as a replacement for automoc4.
Alexander, can you make a release for automoc4-noqt? We could test it with all packages on FreeBSD build cluster.
(In reply to comment #10) > Alexander, can you make a release for automoc4-noqt? We could test it with all > packages on FreeBSD build cluster. Actually, automoc4-noqt got integrated into CMake itself starting with CMake 2.8.6: http://blogs.kde.org/node/4495
This bug can probably be closed. We have worked around it by enabling -pthread: http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/automoc4/files/patch-CMakeLists.txt?rev=1.1;content-type=text%2Fplain
this isn't exactly a workaround ... *of course* qt4 apps need to be compiled with pthread support, so this is a plain bug in the makefile. alex, can you please deal with the patch (dunno if it's kde-ish enough).
(In reply to comment #13) > this isn't exactly a workaround ... *of course* qt4 apps need to be compiled > with pthread support, so this is a plain bug in the makefile. ldd shows automoc already linked to pthread before on FreeBSD, but it looks like it needs to come as a dependency before libc itself so some threading code is properly initialized (see http://www.freebsd.org/cgi/query-pr.cgi?pr=163512). It looks like this sort of problem does not exist on Linux (does it link to pthread automatically?), so it looks more of a braindead issue on FreeBSD.
well, different does not necessarily mean braindead. ;) in either case the kde buildsystem should abstract this away if reasonably possible.
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
automoc4 is no longer maintained.