----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119497/#review66598 -----------------------------------------------------------
Hi Ian, shall I test this on a Mavericks VM before you're committing this? In case I shall do it, do you have a test case for me? Greets, Marko - Marko Käning On Sept. 15, 2014, 3:59 a.m., Ian Wadham wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/119497/ > ----------------------------------------------------------- > > (Updated Sept. 15, 2014, 3:59 a.m.) > > > Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and > Michael Pyne. > > > Repository: kdelibs > > > Description > ------- > > *NOTE: Issues for KCrash have been fixed. Changes to kinit/kinit.cpp > (kdeinit4) have been discontinued. For a summary, scroll to the very end of > this page. > > 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 > > 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 > >
