Fixing KDE debug dialog and Dr Konqui to run on OS X

[Ian Wadham]

Hi guys,

I think I have found the reason for two KDE problems on OS X and MacPorts:
    1. When a KDE app crashes, Dr Konqi often fails to run and produce
         the backtrace KDE developers ask for.
    2. Also the debug dialog fails to run and take the user through the
         steps to report a bug on bugs.kde.org.

UNIX signals, such as SIGSEGV, are caught by a default crash handler
in kdelibs/kdeui/kcrash.cpp (void KCrash::defaultCrashHandler (int sig)).
See source code at [1]

That procedure has a crash recursion counter, to protect it from crashes
within the crash procedure itself, then it has three stages:
    1. Emergency save of data, if the app developer has provided it,
    2. Close all open file descriptors,
    3. Log the crash and start the Dr Konqi app to analyse it.

What happens is that the signal comes in for a second time during step 2,
the recursion counter becomes too high and the crash procedure skips
step 3, issues the message "Unable to start Dr. Konqi" and does _exit(255).

If I comment out step 2 (closing all file descriptors), the crash procedure
starts Dr Konqi and runs normally.  The files then get closed anyway, by
a later process, after Dr Konqi gets started.

Can someone more knowledgeable of OS X suggest what is the best
way to fix the problem?

I am using OS X 10.7.5 (Lion) with a KDE 4.13 library I have built myself,
from the KDE repositories.

The simplest fix would be to omit step 2 from the compilation (which is
what happens with the MS Windows version), i.e. use #ifndef Q_OS_MAC.

I cannot tell what is causing the second signal.  Perhaps it is due to a
restriction on what OS X allows an app to do during a crash procedure?

The procedure for closing the file descriptors is a bit brute force.  It uses
"struct rlimit rlp; getrlimit(RLIMIT_NOFILE, &rlp);" to find out how many
open files the user is allowed (my system says 2560) and then does
"close();" on ALL of them except 0, 1and 2 (stdin, etc.).

I thought that might be causing the second signal - there are only about
10 descriptors open - but it still happens even when I insert a test for a
valid file descriptor ("if (fcntl(i, F_GETFL) != -1)") and end the loo when
I get to an invalid one.  I know - not perfect … ;-)

Is there some better way, in OS X, to find all the open files and close them?
Or is just that much activity causing OS X to spit out a second signal?

Ideas welcome,
Cheers, Ian W.

[1] https://projects.kde.org/projects/kde/kdelibs/repository/entry/kdeui/util/kcrash.cpp?rev=KDE%2F4.13