Thanks for your very prompt reply, Bradley.
On 15/06/2014, at 1:03 PM, Brandon Allbery wrote:
> On Sat, Jun 14, 2014 at 10:25 PM, Ian Wadham <[email protected]> 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 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 loop when
> I get to an invalid one. I know - not perfect … ;-)
>
> Where exactly is it receiving the signal?
Do you mean where is the line of code that causes the second signal?
I don't know. And I don't really know how to find out. My UNIX skills (and
memory) are still rather rusty after years with no use... :-)
My original test used this code, in KGoldrunner's main.cpp:
KGoldrunner * controller = 0; // IDW KCrash test. new KGoldrunner();
controller->show(); // "controller" is supposed to be the main window
ptr, not 0.
and it gave SIGILL (=4) and the second signal was also SIGILL.
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.
> Beware of thread stacks, which may be in the heap; if the per-thread stack
> size is too small, you will definitely see things like this and stack
> allocation/extension in the SEGV handler (like, that struct rlimit) will make
> it worse unless you use sigaltstack.
Possibly, but I don't think that struct is very large (2x64 bits). getrlimit()
is
not on the list of allowed signal-processing functions in "man sigaction",
but it gives a valid return and struct contents in this case.
ATM, I am just looking for a fix for the file-closing code or a workaround
(i.e. don't even compile the call to it, as is done in the MS Windows version
of KCrash). If there is no simple fix, I will go for the workaround. My main
objective is to get through KCrash and get Dr Konqi to run and then produce
some crash info.
Cheers, Ian W.
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
