https://bugzilla.novell.com/show_bug.cgi?id=381928
User [EMAIL PROTECTED] added comment https://bugzilla.novell.com/show_bug.cgi?id=381928#c5 --- Comment #5 from Zoltan Varga <[EMAIL PROTECTED]> 2008-04-21 09:17:09 MST --- (In reply to comment #4 from D Bera) > (In reply to comment #3 from Zoltan Varga) > > First of all: crashes which occur in native code are not converted to > > exceptions > > in recent versions of mono, so Glib.ExceptionManager is no use here. Also, > > I see. But shouldn't it be ? Reading the articles on the web seems to indicate > thats how MS.Net works. A lot of MS.Net related docs basically say "Native > exception is bad. Using a handler will not allow you to stop it from crashing > but give you a chance to log/record the crash before exiting". I am just > curious on this one. > This is impossible to do reliably, since after a SIGSEGV in native code, nothing is guaranteed to work. > > adding a try-catch around the g_free () call does not catch the exception, > > since > > there is no exception to catch, it just perturbs the behaviour of the > > program a > > bit, so it crashes instead of hangs. > > If you know, can you elaborate what causes the changed behaviour ? Also, the > location of g_type_init and the presence of g_string_free even though it is > unused directly in the code. > > > the program, nothing is guaranteed to work, so the process of printing > > stack > > traces might itself hang. The only thing we can do about this is to avoid > > printing stack traces, so users would only see a mysterious crash with 0 > > information. I'm not sure that would be better than the current behavior. > > :-) The "current behaviour" being "just hang there without running" in the > worst case. I think mono's intention in printing the stack trace is correct > but > there are some bugs/side-effects which is causing the worst-case hang > behaviour > (probably since mono internally uses glib to get the stack trace). > glib is irrelevant here, since it calls libc malloc/free internally. It is rather hard to print a managed stack trace without allocating memory, so if a programming error corrupts the libc internal data structures, we will hang, there is nothing we can do about that, except as I said, not printing stack traces at all. -- 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
