Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

Ian Wadham iandw.au-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org
Thu Sep 18 11:46:48 BST 2014



> On Sept. 18, 2014, 9:19 a.m., Thomas Lübking wrote:
> > drkonqi/main.cpp, line 47
> > <https://git.reviewboard.kde.org/r/119498/diff/2/?file=312509#file312509line47>
> >
> >     this sounds fishy - at least the comment to be incorrect?
> >     i hope that OSX does not just actually abort() when you call setuid() but that indeed the tests fail and the applications exits(255)?
> >     
> >     In case of the latter, does the process itself run with suid until this point?
> >     
> >     I assume if we've to consider that drkonqi does not (require) to run suid, the test should be omitted if "geteuid()" (notice the "e"!) isn't 0.
> >     
> >     Skipping this altogether only makes sense for broken by design operating systems which fail to confirm to posix standards (windows ;-)

I am pretty sure Apple OS X does just abort Dr Konqi. It considers use of setuid/setgid a security breach (it calls it "setugid"). It is part of new security rules that came into OS X about 4 versions ago.

The question is moot, because I am not attempting to run Dr Konqi via kdeinit4 any more, only by forking (see review 119497).

So I propose to settle the issue by removing the Q_OS_MAC condition. I intend to leave in the comment, however, to remind me to do something at this point if I ever get the help I have asked for with the many problems in kdeinit4 and friends on Apple OS X, or if the methods of running Dr K from KCrash change in KF5. I heard a rumour that kdeinit is to be dropped in KF5.

All the tests I did on this in July showed that the crashing app, kdeinit4 and Dr Konqi were all running as the logged-in user and no actual setting of uid or gid was needed. They would just set things to what they were before. Also none of the executable files had any special permission bits set. Nevertheless, a few lines later, Apple OS X kicks Dr Konqi off the machine somehow.

FWIW the Apple OS X console log said, back in July:

22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: ENTERING KCrash::defaultCrashHandler (1623294600)...
22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: crashing... crashRecursionCounter = 2
22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: Application Name = palapeli path = /Applications/kde4.13/palapeli.app/Contents/MacOS pid = 14165
22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: Arguments: /Applications/kde4.13/palapeli.app/Contents/MacOS/palapeli --nocrashhandler -psn_0_327760 
22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: Attempting to start /kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi from kdeinit
22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: Connect sock_file=/kdedev/kde4.13/home/.kde4.13/socket-Tara.local/kdeinit4__tmp_launch-KdDfgS_org.x_0
22/07/14 4:30:34.451 PM [0x0-0x4f04f].org.kde.kdeinit4: kdeinit4: Got EXEC_NEW '/kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi' from wrapper.
22/07/14 4:30:34.451 PM [0x0-0x4f04f].org.kde.kdeinit4: kdeinit4: preparing to launch /kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi
22/07/14 4:30:34.545 PM [0x0-0x4f04f].org.kde.kdeinit4: objc[14167]: Object 0x7fc6cb64e5e0 of class NSPathStore2 autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug
22/07/14 4:30:34.545 PM [0x0-0x4f04f].org.kde.kdeinit4: objc[14167]: Object 0x7fc6cb64e660 of class NSPathStore2 autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug
22/07/14 4:30:34.546 PM drkonqi: The application with bundle ID  is running setugid(), which is not allowed.
22/07/14 4:30:34.546 PM [0x0-0x4f04f].org.kde.kdeinit4: 2014-07-22 16:30:34.545 drkonqi[14167:2503] The application with bundle ID  is running setugid(), which is not allowed.
22/07/14 4:30:34.549 PM [0x0-0x4f04f].org.kde.kdeinit4: kdeinit4: PID 14167 terminated.


- Ian


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119498/#review66817
-----------------------------------------------------------


On Sept. 16, 2014, 11:08 a.m., Ian Wadham wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119498/
> -----------------------------------------------------------
> 
> (Updated Sept. 16, 2014, 11:08 a.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Michael Pyne.
> 
> 
> Repository: kde-runtime
> 
> 
> Description
> -------
> 
> When a KDE app crashes in Apple OS X, it just disappears from the screen. At the most, the user is invited to report the crash to Apple. AFAIK this has been a problem in KDE on Apple OS X for years, leading to frustration with KDE among Apple users and MacPorts developers and an attitude among KDE developers of "Why does nobody report the problem(s) on bugs.kde.org?"
> 
> It is my strong belief that the failure to report crashes of KDE apps in Apple OS X also exists in Frameworks.
> 
> So far I have identified a number of portability bugs in KDE on Apple OS X: 1 in KCrash, 1 in kdeinit4 and 5 in Dr Konqi. Three patches for Dr Konqi are submitted in this review. Patches for KCrash and kdeinit4 are submitted in part 1 of this review, against kdelibs. I am still investigating the other two problems in Dr Konqi - and there could be more than two...
> 
> In this review we have three portability problems:
> 
> 1. On Apple OS X, Dr Konqi's dialog box hides itself underneath the main window of the app that has just crashed, so is effectively useless. This appears to be because Dr Konqi is started by a Linux/Unix method (fork() + exec()?). If an app is started with the Apple OS X "open" command, it always appears on top. The patch just raises the dialog box.
> 
> 2. When formatting the backtrace output, Dr Konqi crashes (with an ASSERT) on the last line. This appears to be an error in the algorithm used (i.e. also a bug in Linux KDE), but the patch is treating it as an Apple OS X portability problem for now.
> 
> 3. Dr Konqi checks whether the user can save cookies in kcookiejar and, if not, stops reporting the crash. On Apple OS X, cookies would be kept in another browser (e.g. Safari or Firefox) and not in KDE's default browser (Konqueror) and cookie jar. IMHO, Dr K should report the crash no matter what, as long as it can connect to bugs.kde.org and log in.
> 
> 
> Diffs
> -----
> 
>   drkonqi/gdbhighlighter.cpp 7cd0aa9 
>   drkonqi/main.cpp 75e060e 
>   drkonqi/reportassistantpages_bugzilla.cpp 86ca327 
> 
> Diff: https://git.reviewboard.kde.org/r/119498/diff/
> 
> 
> Testing
> -------
> 
> Using Apple OS X 10.7.5 (Lion) on a MacBook Pro, I have installed KDE libs via MacPorts (at version 4.12.5) and I have adapted kdesrc-build to run in an Apple OS X environment and used it to test against the KDE 4.13 branch. I have been testing with a KDE app that I can crash at will and using stderr and Apple OS X Console log output to determine the outcome.
> 
> Please note that I am the -only- KDE developer who has this kind of setup, but I am NOT a KDE core developer. My experience before now has been in KDE Games. However I used to be a UNIX and database guru before I retired in 1998.
> 
> I NEED HELP from KDE -core- developers to proceed further. These problems will also exist in Dr Konqi for KF 5, but I am as yet unable to build or test Frameworks on Apple OS X and I cannot find Dr Konqi among the Frameworks repositories. I am sure there are many more Apple OS X portability problems in Dr Konqi and other KDE software.
> 
> Without my patches, Dr Konqi, on Apple OS X, remains invisible to the user, often fails to complete the backtrace report and then fails to connect to bugs.kde.org.
> 
> With my patches, Dr Konqi on Apple OS X can generate a full crash report, including the backtrace and the results of the dialog with the user. Sometimes, however, it fails to submit the completed report to bugs.kde.org. This problem is still under investigation.
> 
> I would not have got this far without help from Michael Pyne, Thomas Lübking and several of the MacPorts developers, as well as the unfailing enthusiasm and encouragement of my friend Marko Käning.
> 
> 
> File Attachments
> ----------------
> 
> Log of Dr K ASSERT problem
>   https://git.reviewboard.kde.org/media/uploaded/files/2014/07/30/a3f99f00-94df-4b10-bc47-66b1c966f893__DrKonqiASSERT.kcrash.txt
> 
> 
> Thanks,
> 
> Ian Wadham
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20140918/3c41c391/attachment.htm>


More information about the kde-core-devel mailing list