This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: Prevent infinite recursion in signal->exception converter
- To: Tom Tromey <tromey at redhat dot com>
- Subject: Re: Prevent infinite recursion in signal->exception converter
- From: "Zack Weinberg" <zackw at Stanford dot EDU>
- Date: Thu, 19 Apr 2001 22:32:48 -0700
- Cc: gcc-patches at gcc dot gnu dot org, java-patches at gcc dot gnu dot org
- References: <20010419190017.J21961@stanford.edu> <87n19cduhl.fsf@creche.redhat.com>
On Thu, Apr 19, 2001 at 11:13:10PM -0600, Tom Tromey wrote:
> >>>>> "Zack" == Zack Weinberg <zackw@stanford.edu> writes:
>
> Zack> I compiled this and verified that a properly-linked Divide_1 now
> Zack> segfaults cleanly instead of going into an infinite loop. I did
> Zack> not run the libjava test suite, because there's still a libtool
> Zack> bug to deal with.
>
> I think Andrew really has to look at this.
> Divide_1 shouldn't segfault at all, of course.
True. This isn't meant as a fix for the real bug, just making the
impact a little less nasty.
> I don't have any feeling for whether the signal handlers can ever
> cause a segv other than when something is horribly trashed (in which
> case maybe an infinite loop isn't much worse than a segv).
Personally, I'd much rather the segv, because then the test suite
keeps going instead of getting stuck for five minutes on most every
test.
> Zack> +static int signal_depth = 0;
> Zack> +struct prevent_signal_recursion {
> Zack> + prevent_signal_recursion(int signo) {
> Zack> + if (signal_depth++) {
> Zack> + signal (signo, SIG_DFL);
> Zack> + raise (signo);
> Zack> + }
> Zack> + }
> Zack> + ~prevent_signal_recursion() { signal_depth--; }
> Zack> +};
> Zack> +#endif
>
> We use GNU style indentation: braces on their own lines.
Oops, sorry, will correct.
> How does the above code work in relation to multiple threads?
> I think it must not work if two threads both dereference a null
> pointer nearly simultaneously.
... probably not, no.
> Hmm... I think our multiple thread support for null pointer exceptions
> is not so great. It seems to me that at the very least every thread
> should have its own null pointer exception object. And even then,
> reusing the object per-thread probably isn't all that great.
>
> I'm sure calling the allocator from a signal handler would be evil.
> Maybe there isn't a really good solution?
We're already calling the allocator from the signal handler at some
point - or at any rate, the strace I did of the infinite segv loop
showed occasional calls to brk(). I don't know where the mallocs are.
zw