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

Ian Wadham iandw.au at gmail.com
Sun Jun 15 17:15:00 PDT 2014


On 15/06/2014, at 6:28 PM, Clemens Lang wrote:
>>> On Sat, Jun 14, 2014 at 10:25 PM, Ian Wadham <iandw.au at gmail.com> wrote:
>>> 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 have now re-tested with a crash in another app, which can be induced
>> by doing stuff on the app's screen.  It gave SIGSEGV (=11), but the second
>> signal was still SIGILL (=4), i.e. it is a new signal, not a repeat of the
>> first one (as I originally thought).  So there must be a second crash
>> somewhere in the code that closes the files or handles 2500+ invalid file
>> descriptors.
> 
> I guess you're seeing what can be found by googling for
>  BUG in libdispatch client: Do not close random Unix descriptors.

Thanks, Clemens, that explains a lot.

> Long story short, you'll probably have to stop closing all file descriptors,
> because OS X's libdispatch library has a few file descriptors of its own and
> reacts with this signal if you close those. There doesn't seem to be a way
> to avoid libdispatch (disabling native language support apparently works for
> some people, but I'm sure that's not an option here) and no way to find out
> which file descriptors are used by libdispatch, so all you can do is only
> close descriptors where you know that they have been opened by KDE code.

In an arbitrary app that has crashed that would be unknowable in principle.

KDE apps can open FDs via Qt, KDE or even directly by UNIX calls or
indirectly by calling a library that operates on a cache.  AFAICT there is no
way in UNIX/Linux/OS X to tell what FDs are in use period, which would be
why the crash code "closes" every possible FD.

So indeed, the only way to go is to exclude from compilation on OS X the
code that closes all the file descriptors during the initial crash-processing.

Later the the FDs get closed anyway and it works then, perhaps because
the app gets issued with a STOP.

Thanks again,
All the best, Ian W.


More information about the macports-dev mailing list