Re: Prevent infinite recursion in signal->exception converter

[Tom Tromey <tromey at redhat dot com>]

>>>>> "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.
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).

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.

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.


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?

Tom