Review Request 119497: Report crashes of KDE apps in Apple OS X (1) (fix kcrash, kinit)

Tue Jul 29 08:23:48 BST 2014

> On July 28, 2014, 12:57 a.m., Ian Wadham wrote:
> > kinit/kinit.cpp, line 119
> > <https://git.reviewboard.kde.org/r/119497/diff/1/?file=293442#file293442line119>
> >
> >     The real issue is on this line. I do not know how "MAC_DISPLAY" got into the act, but clearly it has not been tested recently, if ever. There is no "MAC_DISPLAY" in Apple OS X.
> >     
> >     Also "DISPLAY" is a threatened species in Mac OS X and its existence in an installation appears to depend, in more recent versions of Apple OS X, on whether FOSS XQuartz (a non-Apple X11 emulator) is installed.
> >     
> >     It is not clear ATM whether the socket name on which kinit "listens" needs to be qualified in some way on Apple OS X, as opposed to Linux and X11, or whether $DISPLAY could safely have an empty string as its value.
> >     
> >     Also, I find it questionable that kinit.cpp, wrapper.c and kcrash.cpp use different methods or cloned source-code to evaluate the all-important socket name on which they will communicate. See kdeui/util/kcrash.cpp line 637.  There must be a better way to program this...
> >     
> >     That is why I would like to see some KDE core developers reviewing this code. I am not a KDE core developer.
> 
> David Faure wrote:
>     The reason we have $DISPLAY in the kdeinit socket name on X11, is to allow the same user to have more than one graphical session.
>     I don't mean two full KDE-workspace instances running (they'd overwrite config files), but it happened to me sometimes that I would use ssh -X from another machine, then start one app (which wasn't running in the main session).
>     What happens then is that another kdeinit4 starts, in that separate session (which has a separate dbus session). So it should all be separate from the main session, hence $DISPLAY.
>     
>     AFAIK this use case doesn't apply to Mac, so it would be ok to have an empty string in there.
> 
> RJVB Bertin wrote:
>     It doesn't, indeed, and OS X doesn't allow non-X11 apps to be started remotely.
>     
>     (It doesn't really work for me on Linux either, launching a KDE app from an ssh-X session rarely if ever started a new dbus session for me ...)
> 
> David Faure wrote:
>     (It should have, after dbus got support for autostarting session, but otherwise you can always do it by hand
>       eval `dbus-launch` ; kdeinit4 ; kmyapp
>     )
> 
> RJVB Bertin wrote:
>     Ah, yes, I do get something like that printed on the terminal - but since I'm a tcsh-addicted dinosaur I cannot simply copy/paste the suggestion and I've never yet bothered to figure out how to translate them. Easier to start x11vnc and connect to the main session :)

Thank you, David, for taking the time to reply. I know you are always very busy.

So the easiest fix on Apple OS X (all versions) would be to use $DISPLAY whenever the socket name is computed and allow an empty string. I will modify this patch accordingly.

David, can you find a core developer from the Frameworks team to help me occasionally with advice, answers to technical questions and reviews?

I am really struggling with the KDE portability problems on Apple OS X and I am sure I could work many times faster with a little expert help. Michael Pyne has helped me a lot in the last week or two, but he has business commitments coming up.

- Ian

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

On July 27, 2014, 9:15 a.m., Ian Wadham wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119497/
> -----------------------------------------------------------
> 
> (Updated July 27, 2014, 9:15 a.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Michael Pyne.
> 
> 
> Repository: kdelibs
> 
> 
> 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. Patches for the first two are submitted in this review. Patches for three more are submitted in part 2 of this review, against kde-runtime. I am still investigating the other two problems in Dr Konqi - and there could be more than two...
> 
> In this review we have two portability problems:
> 
> 1. KCrash itself crashes (SIGILL) when it tries to close all file descriptors and so Dr Konqi is not started. Some of the FDs belong to the Apple OS X library (COCOA) and it crashes if they are closed prematurely.
> 
> 2. The preferred way to start Dr K is via a socket message to kdeinit4, but that fails in Apple OS X because kdeinit4 is listening with the wrong socket name. The DISPLAY ID is missing from the end of the name. The fallback is for KCrash to use fork() and exec(), which works, but could cause Dr K to be polluted, depending on the nature of the crash.
> 
> This "deafness" of kdeinit4 (and klauncher) could be causing other failures in KDE software in the Apple OS X environment.
> 
> 
> Diffs
> -----
> 
>   kdeui/util/kcrash.cpp 45eb46b 
>   kinit/kinit.cpp e41845a 
> 
> Diff: https://git.reviewboard.kde.org/r/119497/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 also exist in FRAMEWORKS, but I am as yet unable to build or test Frameworks on Apple OS X. And I am sure there are many more Apple OS X portability problems in KDE software.
> 
> Without my patches, Dr Konqi is not started and, if it does get past its own crash, KCrash reports:
> KCrash: Attempting to start /kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi from kdeinit
> sock_file=/kdedev/kde4.13/home/.kde4.13/socket-Tara.local/kdeinit4__tmp_launch-svPd0L_org.x_0
> Warning: connect() failed: : No such file or directory
> 
> With my patches, Dr Konqi can always be started directly (using fork()) and it -will- start via kdeinit4 and klauncher but it immediately runs into a privilege problem with Apple OS X (a problem which I am still investigating).
> 
> 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.
> 
> 
> Thanks,
> 
> Ian Wadham
> 
>

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