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

bugzilla_noreply at novell.com bugzilla_noreply at novell.com
Mon Apr 21 10:37:50 EDT 2008


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

User dbera.web at gmail.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=381928#c4





--- Comment #4 from D Bera <dbera.web at gmail.com>  2008-04-21 08:37:49 MST ---
(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.

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


-- 
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