Summary: | kdeinit4 4.3.2 (macports / snow leopard) crash | ||
---|---|---|---|
Product: | [Frameworks and Libraries] kdelibs | Reporter: | Joseph Wenninger <jowenn> |
Component: | kdeinit | Assignee: | kdelibs bugs <kdelibs-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | crash | CC: | adam, andresbajotierra, faure, mark.gaylard, papylhomme |
Priority: | NOR | ||
Version: | 4.3 | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | macOS | ||
Latest Commit: | Version Fixed In: | ||
Attachments: |
Patch to work around kdeinit4 crash
Also avoid crashing when loading libraries |
Description
Joseph Wenninger
2009-10-08 20:28:03 UTC
Mh, it looks like a Qt issue. - What are your Qt4 and KDE versions? (svn/git branch/revision) Thanks "port search qt4-mac" tells cutecom-qt4-mac @0.20.0 (comms) Graphical serial terminal qt4-mac @4.5.2 (aqua) Qt Tool Kit (Native Aqua Version) qt4-mac-devel @4.5.0 (aqua) Qt Tool Kit (Native Aqua Version) qt designer works though. I've installed qt4 and qtcreator (from dmg images in parallel) Created attachment 37552 [details]
Patch to work around kdeinit4 crash
I have been able to work around kdeinit4 crashing using the attached patch. Basically as of OS/X 10.6 there are a number of functions which you can no longer call between the moment you fork() and the moment you exec().
However, this does not make kdeinit4 functional: the child process it spawns, most notably klauncher seem to be broken. klauncher does not seem to be able to connect to DBus when run by kdeinit4, where as it connects to DBus just fine if I invoke it manually (with --fd=<SOME_FD>).
Same problem for me with Snow Leopard, Qt 4.5.2, DBus 1.2.16 and kdelibs 4.3.2 Created attachment 37580 [details]
Also avoid crashing when loading libraries
My initial patch only avoided a crash when launching a program. It did not avoid a crash when a library is loaded and it's "kdemain()" invoked. The attached patch introduces a "kdeinit4_helper" executable which does the actual function call. That way the kdeinit4 process does its exec(), keeping OS/X happy.
This patch needs some fine tuning as platforms other than OS/X do not need this hack.
I would much rather see mac and windows use the same code path in kinit/klauncher (launching apps directly rather than via fork+exec), to avoid a 3rd code path to maintain. Something like http://www.davidfaure.fr/2009/klauncher_mac.diff For the launching of kioslaves I had suggested something like http://www.davidfaure.fr/2009/klauncher_kioslave.diff Apparently these patches don't fully work; I couldn't test them myself (no mac here). Just "proofs of concepts". Fixed in master and 4.6 with 19f4bf0c212a28e79ef9b8d0cb35068951e58a85 based on David's ideas. Git commit cb0e915925fc8a854c31b416b33f43e794f11119 by David Faure. on behalf of Till Adam Committed on 06/02/2011 at 20:48. Pushed by dfaure into branch 'KDE/4.6'. Make the KProcess mode for KIO also usable on OSX and use it. On OSX, as of 10.6, one cannot fork with out exec'ing, more or less, which makes the way kdeinit works problematic. In order not to introduce yet another code path, this makes the so far Windows specific way of handling kio processes via KProcess, instead of kdeinit available more generically and uses it on OSX as well. This is based on proof of concept patches by David Faure. CCBUG: 209903 (cherry picked from commit 19f4bf0c212a28e79ef9b8d0cb35068951e58a85) M +10 -3 kinit/kioslave.cpp M +39 -18 kinit/klauncher.cpp M +7 -7 kinit/klauncher.h M +3 -3 kinit/klauncher_main.cpp http://commits.kde.org/kdelibs/cb0e915925fc8a854c31b416b33f43e794f11119 |