Version: (using Devel) OS: OS X Installed from: Compiled sources Process: kdeinit4 [42916] Path: /Applications/MacPorts/KDE4/kdeinit4.app/Contents/MacOS/kdeinit4 Identifier: kdeinit4 Version: ??? (???) Code Type: X86-64 (Native) Parent Process: kdeinit4 [42695] Date/Time: 2009-10-08 20:01:30.938 +0200 OS Version: Mac OS X 10.6.1 (10B504) Report Version: 6 Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Application Specific Information: abort() called USING_FORK_WITHOUT_EXEC_IS_NOT_SUPPORTED_BY_FILE_MANAGER Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 libSystem.B.dylib 0x00007fff80af1ff6 __kill + 10 1 libSystem.B.dylib 0x00007fff80b93072 abort + 83 2 ...ple.CoreServices.CarbonCore 0x00007fff87ae89c5 SCSessionUniverseClientDeath + 0 3 ...ple.CoreServices.CarbonCore 0x00007fff87a25d34 _SCSessionUniverseByUIDAcquireAndLock + 70 4 ...ple.CoreServices.CarbonCore 0x00007fff87a254f7 FSNodeStorageGetAndLockCurrentUniverse + 188 5 ...ple.CoreServices.CarbonCore 0x00007fff87a2c2f6 FileIDTreeGetVRefNumForDevice + 39 6 ...ple.CoreServices.CarbonCore 0x00007fff87a2c261 FSMount::FSMount(unsigned int, FSMountNumberType, short*) + 73 7 ...ple.CoreServices.CarbonCore 0x00007fff87a2a931 PathGetObjectInfo(char const*, unsigned int, unsigned int, short*, unsigned int*, unsigned int*, char*, unsigned int*, unsigned char*) + 296 8 ...ple.CoreServices.CarbonCore 0x00007fff87a2a760 FSPathMakeRefInternal(unsigned char const*, unsigned int, unsigned int, FSRef*, unsigned char*) + 114 9 com.apple.CoreFoundation 0x00007fff8182133d _CFGetFSRefFromURL + 829 10 com.apple.CoreFoundation 0x00007fff81820ff0 CFURLGetFSRef + 48 11 ...ple.CoreServices.CarbonCore 0x00007fff87a36808 GetUserDomainRootRef + 152 12 ...ple.CoreServices.CarbonCore 0x00007fff87a3668c GetDomainRootRef + 762 13 ...ple.CoreServices.CarbonCore 0x00007fff87a35fce ResolveSpecialFolder + 135 14 ...ple.CoreServices.CarbonCore 0x00007fff87a3557e FindFolderGuts + 648 15 ...ple.CoreServices.CarbonCore 0x00007fff87a4c747 ResolveRelativeFolder + 60 16 ...ple.CoreServices.CarbonCore 0x00007fff87a355ba FindFolderGuts + 708 17 ...ple.CoreServices.CarbonCore 0x00007fff87a352f3 FlndFolderGuts + 32 18 ...ple.CoreServices.CarbonCore 0x00007fff87a35280 FSFindFolder + 108 19 QtGui 0x00000001017acbca QDesktopServices::storageLocation(QDesktopServices::StandardLocation) + 106 20 libkdeui.5.dylib 0x0000000100d577b1 KGlobalSettings::documentPath() + 33 21 0x0000000100007efe launch(int, char const*, char const*, char const*, int, char const*, bool, char const*, bool, char const*) + 1294 22 0x000000010000b911 main + 3057 23 0x0000000100006458 start + 52
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