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

[RJVB Bertin]

> On July 29, 2014, 5:33 p.m., Aleix Pol Gonzalez wrote:
> > kinit/kinit.cpp, line 1481
> > <https://git.reviewboard.kde.org/r/119497/diff/1/?file=293442#file293442line1481>
> >
> >     do you need $DISPLAY in OS X?
> 
> RJVB Bertin wrote:
>     Nope. It can be set if the user has XQuartz installed and running, but that shouldn't make a difference.
>     
>     In fact, $DISPLAY shouldn't be used on OS X because we wouldn't want things like socket names change when the user starts or quits XQuartz with KDE apps and/or services running.
> 
> Ian Wadham wrote:
>     Perish the thought ($DISPLAY fluctuating between a value and an empty string). On my system, OS X 10.7.5 (Lion), XQuartz was installed by Apple and $DISPLAY is always set to a value, even if XQuartz (X11.app) is not running (i.e. no X11 server running). I presume installing X11 somehow "doctors" the OS X (Darwin) startup procedures so that DISPLAY is already defined in every user's ~/.profile. I do not know if that would be the case if a FOSS version of XQuartz would be installed (e.g. on OS X 10.9.x Mavericks).
>     
>     The big thing is that $DISPLAY -is- used (non-portably) in KDE to help name a socket in kdeinit4 (kinit.cpp), wrapper.c, kwrapper and KCrash - and FAIK it may be used in this way in several other places. If $DISPLAY is not used consistently in all those places, communication with kdeinit4 can break, as it does already in KCrash/kdeinit4 on Apple OS X. And THAT is what we are trying to fix here. KDE apps on Apple OS X MUST be able to report a crash reliably.
>     
>     This is why I keep asking for help from a KDE core developer. How widespread is this problem in KDE on Apple OS X? What are the implication for KDE apps? Should references to $DISPLAY in KDE be eliminated from the OS X version? What do kdeinit4, kwrapper and klauncher really do? Is whatever they do actually portable to Apple OS X? Or are we all, KDE guys and MacPorts guys alike, just crossing our fingers and hoping for the best?
>     
>     I tried using lxr.kde.org to find further references, but there are thousands: mostly because "display" is a commonly-used English word in programming. And I did tick the case-sensitive box, but it does not seem to work.

Hmm, interesting. I should find some time to play with this in my 10.9 VM.
Know however that even if $DISPLAY is always set, it will not always have the same value. At least for me, XQuartz has the annoying habit of increasing the display number after a restart.

If it's too complicated to remove all references to $DISPLAY from KDE code (which wouldn't surprise me at all) there remains another approach. Identify an appropriate location in the startup/initialisation code that all KDE applications and services share, and set $DISPLAY to something sensible (but preferably NOT a valid X11 display specifier). The only possible undesirable side-effect I can see from here would be that shells in konsole risk to inherit that value.
This probably isn't the most elegant solution, but then again that's because KDE apparently never imposed the use of its own internal variable/function (or one from Qt) instead of directly querying $DISPLAY.


- RJVB


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


On July 27, 2014, 11: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, 11: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/20140730/ac7a38e4/attachment.htm>