https://bugzilla.novell.com/show_bug.cgi?id=381928
User [EMAIL PROTECTED] added comment https://bugzilla.novell.com/show_bug.cgi?id=381928#c14 --- Comment #14 from Zoltan Varga <[EMAIL PROTECTED]> 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. _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
