[Mono-bugs] [Bug 381928] GLib crashes can hang mono

bugzilla_noreply at novell.com bugzilla_noreply at novell.com
Tue Apr 22 12:28:16 EDT 2008


User vargaz at gmail.com added comment

--- Comment #14 from Zoltan Varga <vargaz at gmail.com>  2008-04-22 10:28:15 MST ---
(In reply to comment #13 from D Bera)
> (In reply to comment #9 from Zoltan Varga)
> > As I said earlier, there is no exception in this case, control goes directly
> > from the SIGSEGV signal handler to mono_handle_native_sigsegv () in
> > mini-exceptions.c, which tries to gather and print the stack traces, then
> > aborts the program.
> You seem to suggest that the try-catch in
> try {
>   native_method();
> } catch {
> }
> is a no-op. The test case suggest the opposite.

I didn't said it was a no-op, just that there is no exception to catch. 
The try-catch causes the JIT to generate different code, might allocate some
more memory etc.

> Also, after the recent discussion about signal-handlers in the mono-devel
> thread, isnt it clear that doing a whole lot of work in a signal-handler is
> dangerous and a deadlock is just waiting to happen ? I was clearly told that
> unix signal handlers allow very limited syscalls - spawning a program is not in
> that list and neither are the lots of other things that mono is doing.

Its dangerous, but we only do it if the program causes a SIGSEGV which means
something went very wrong, and we will abort anyway.

> There is one more catch: unix specification says that if a SIGABRT signal
> handler returns then the process is aborted. There is _no_need_ to call
> "abort()" - I wonder if calling abort from a signal-handler could be causing
> the problem.

Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.

More information about the mono-bugs mailing list