Bug 276461

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.