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

[bugzilla_noreply at novell.com]

https://bugzilla.novell.com/show_bug.cgi?id=381928

User vargaz at gmail.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=381928#c5





--- Comment #5 from Zoltan Varga <vargaz at gmail.com>  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.