Re: Prevent infinite recursion in signal->exception converter

["Zack Weinberg" <zackw at Stanford dot EDU>]

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