Re: [Nepomuk] The zombie processes bug ( 302143 )
Hey David. Do you think you could please look at this? On Wed, Dec 12, 2012 at 7:58 AM, Simeon Bird bla...@gmail.com wrote: ( the report is https://bugs.kde.org/show_bug.cgi?id=302143 ) The last couple of days (not sure why: I think triggered somehow by the virtuoso deadlocks Vishesh posted a patch for recently) I started hitting the nepomuk zombie processes bug, and so I figured this was a good opportunity to debug it. Turns out the root cause is a (quite silly) QProcess bug. I found the source here: http://qt.gitorious.org/qt/qt/blobs/4.8/src/corelib/io/qprocess_unix.cpp The short version is: QProcess doesn't check errors properly. The longer version: When QProcess-start() is called, Qt creates a pipe to the process to get its exit value and output. It does this with qt_create_pipe, which calls qt_safe_pipe. qt_safe_pipe, on failure, returns 1. If this happens, qt_create_pipe fails, sets errno, prints a warning: [/usr/bin/nepomukservicestub] QProcessPrivate::createPipe: Cannot create pipe 0x1987228: Too many open files and returns void, carefully ignoring the error. The calling function, QProcessPrivate::startProcess, does not check errno, and thus continues on its merry way assuming the pipe has been created successfully, and creates a QSocketNotifier with it. Since the pipe is not valid, this fails and prints a warning: [/usr/bin/nepomukservicestub] QSocketNotifier: Invalid socket specified The calling process again does not check for an error, continues on its merry way and forks off the child process (incidentally obliterating the value of errno from qt_create_pipe). Note that since the child process is actually created correctly, no QProcess error is set, so we can't fix it by checking for error(). The child process then has no way to pass its exit value to the calling process, since the communication pipes it would normally use do not exist, and thus when it exits it becomes a zombie. As a bonus, once the first timeout timer for a broken process happens, waitForFinished is called, which crashes, because it is trying to wait on a pipe which does not exist. (This was reported with a patch a year ago, but not fixed: https://bugreports.qt-project.org/browse/QTBUG-18934 ) There is another KDE bug which seems to have the same root cause: https://bugs.kde.org/show_bug.cgi?id=252602 So far as I can see, this really needs to be fixed in QProcess. The fix would, I guess, make qt_create_pipe return an integer, and then have startProcess check the return value, set processError and abort. Can this be done in a reasonable timeframe? Does anyone know how to submit Qt patches? Simeon ___ Nepomuk mailing list Nepomuk@kde.org https://mail.kde.org/mailman/listinfo/nepomuk -- Vishesh Handa ___ Nepomuk mailing list Nepomuk@kde.org https://mail.kde.org/mailman/listinfo/nepomuk
Re: [Nepomuk] The zombie processes bug ( 302143 )
On Saturday 15 December 2012 16:12:10 Vishesh Handa wrote: Hey David. Do you think you could please look at this? This is Oswald's area of expertise, I forwarded Simeon's mail to him. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Nepomuk mailing list Nepomuk@kde.org https://mail.kde.org/mailman/listinfo/nepomuk
[Nepomuk] The zombie processes bug ( 302143 )
( the report is https://bugs.kde.org/show_bug.cgi?id=302143 ) The last couple of days (not sure why: I think triggered somehow by the virtuoso deadlocks Vishesh posted a patch for recently) I started hitting the nepomuk zombie processes bug, and so I figured this was a good opportunity to debug it. Turns out the root cause is a (quite silly) QProcess bug. I found the source here: http://qt.gitorious.org/qt/qt/blobs/4.8/src/corelib/io/qprocess_unix.cpp The short version is: QProcess doesn't check errors properly. The longer version: When QProcess-start() is called, Qt creates a pipe to the process to get its exit value and output. It does this with qt_create_pipe, which calls qt_safe_pipe. qt_safe_pipe, on failure, returns 1. If this happens, qt_create_pipe fails, sets errno, prints a warning: [/usr/bin/nepomukservicestub] QProcessPrivate::createPipe: Cannot create pipe 0x1987228: Too many open files and returns void, carefully ignoring the error. The calling function, QProcessPrivate::startProcess, does not check errno, and thus continues on its merry way assuming the pipe has been created successfully, and creates a QSocketNotifier with it. Since the pipe is not valid, this fails and prints a warning: [/usr/bin/nepomukservicestub] QSocketNotifier: Invalid socket specified The calling process again does not check for an error, continues on its merry way and forks off the child process (incidentally obliterating the value of errno from qt_create_pipe). Note that since the child process is actually created correctly, no QProcess error is set, so we can't fix it by checking for error(). The child process then has no way to pass its exit value to the calling process, since the communication pipes it would normally use do not exist, and thus when it exits it becomes a zombie. As a bonus, once the first timeout timer for a broken process happens, waitForFinished is called, which crashes, because it is trying to wait on a pipe which does not exist. (This was reported with a patch a year ago, but not fixed: https://bugreports.qt-project.org/browse/QTBUG-18934 ) There is another KDE bug which seems to have the same root cause: https://bugs.kde.org/show_bug.cgi?id=252602 So far as I can see, this really needs to be fixed in QProcess. The fix would, I guess, make qt_create_pipe return an integer, and then have startProcess check the return value, set processError and abort. Can this be done in a reasonable timeframe? Does anyone know how to submit Qt patches? Simeon ___ Nepomuk mailing list Nepomuk@kde.org https://mail.kde.org/mailman/listinfo/nepomuk
