[KDE/Mac] Fixing a crash in KCrash for Frameworks

[Ian Wadham]

Hi Jeremy and René,

This in answer to your several emails on this topic…  I am also copying David
(for info only) to let him know what we are doing re kdeinit5 and friends on OSX.

On 02/02/2015, at 1:03 AM, Jeremy Whiting wrote:
> On Sat, Jan 31, 2015 at 10:21 PM, Ian Wadham <iandw.au at gmail.com> wrote:
> > Attached is a patch to fix a recursive crash in KCrash (the
> > crash-handler class) on Apple OS X with Frameworks.  The
> > comments should explain it.
> 
> > Jeremy, could you forward-port this to Frameworks and test
> > it.  It is already in latest KDE 4 libs and has been for a while.
> > See kdelibs repository kdeui/util/kcrash.cpp.
> 
> Yep, that looks pretty straightforward, I'll give it a shot here. Is there an example way to always crash an application on OS X that will trigger drkonqi?

See [2].

> Actually, since klauncher isn't found by it's .service file (I'll try fixing that manually) we don't even get to this point, correct?

No and yes.  KCrash prefers to have kdeinit5 always running and listening
on a UNIX socket (an inter-process socket, as opposed to a network socket).

In Linux, KCrash sends a message via the socket to kdeinit5, which then starts
klauncher5, if it is not already running, and passes klauncher5 another message…
Eventually Dr K gets started…  At least, that is what happens in KDE 4 [1], and the
relevant code seems (to me, at first glance) to be much the same in Frameworks.

That whole sequence is to AVOID forking Dr K from an app that has crashed
and might have a corrupted stack or heap.  The sequence does not work on
Apple OS X (wait for the next instalment, by email… :-)), so in KDE 4 I patched
it out of KCrash and went for the fork-method only, because I was not getting
any help on fixing it in KDE 4.  If you want know more, see:
    http://mail.kde.org/pipermail/kde-mac/2014-August/001437.html
    "Giving up on kdeinit4 and friends".

In Frameworks on Apple OS X, ATM, KCrash should try going via kdeinit5, fail,
issue an error message and then fall back to "startDirect" mode (i.e. using a fork()).

What I would like us to do now, *step by step*, is get kdeinit5 and friends running
on Apple OS X.  Then we can get a clearer idea of what they do, how they work and
how much of it is needed/useful on Apple OS X and whether there are some
simplifications KF5 on Apple OS X could adopt (maybe also on Linux and Windows).

Fixing KCrash so that it does not itself crash on Apple OS X is just the first step.
Getting Dr Konqi to run "safely", without forking the dying app, is another step.
Finding a simpler way to do that is yet another step, later on… but by then,
someone might have re-written Dr Konqi… :-)

My next email topic (the "next instalment", promised above) will be about getting
the socket used by kdeinit5 and friends to work properly on Apple OS X.  I am
putting together some tentative patches which I hope David can find time to review.

After that, I know of (and will report) several points of failure, on Apple OS X,
during the sequence start kdeinit4/5 ---> start klauncher4/5 ---> start kded4/5 --->
start kbuildsycoca4/5 ---> shutdown kdeinit4/5 and friends.

Cheers, Ian W.

[1]
ATM, I am only able to *read* the Frameworks code, not build and test it.  In
KDE 4, I can build it on Apple OS X and test it (using inserted log messages).
That means I can follow execution paths and find points of failure --- and have
done so in July/August last year.

[2]
Killing an app by command does not seem to do what we want on Apple OS X.
Cocoa gets in and handles it before KCrash gets a look in (via a UNIX signal).

You need to edit an app you know, which is already ported to KF5, and do something
like setting an object-pointer to zero.  Or you can use an app that has a reproducible
crash, as previously reported on bugs.kde.org.  Also see [3].

WARNING: Never go "all the way" with testing Dr Konqi on bugs.kde.org.  You
                     will just upset people by cluttering up the database and sending
                     spurious emails from Bugzilla.  If you ever need to go "all the way",
                     there is a test database at bugstest.kde.org.  To use it, you have to
                     patch and re-build Dr Konqi.

[3]
Palapeli, the jigsaw puzzle game, has a reproducible crash and its initial (not
yet tested) port to KF5 is in the "frameworks" branch of the KDE Games Palapeli
repository.  To activate the crash-at-will:

    - Assign a shortcut key (e.g. Ctrl-R) to the Game->Restart Puzzle… action.
    - Start Palapeli and double-click on any puzzle in the list that appears.
    - Start dragging any piece in the puzzle that appears and, without letting
       go of it, hit your shortcut key for Restart Puzzle…  Bingo!

Actually, the second step might not work on KF5 in OSX, because Palapeli might
not start, come to think of it… :-(  On its very first run on a new system, Palapeli has
to load and slice up its sample puzzles and that involves searching for desktop
files for each puzzle and a desktop file for loading a slicer plugin… :-( … not to
mention having a fully up-to-date SyCoCa5… ;-)