---- Reported by joe@otee.dk 2005-05-08 11:42:42 MST ----

When a null exception is thrown in mono on os x, it will invoke the crashreporter. 
This is a known bug in os x, where the crashreporter is invoked although there is a null 
exception signal handler. I filed a bug on this with Apple but they refuse to fix the issue.
http://developer.apple.com/technotes/tn2004/tn2123.html (CrashReporter Limitations)


The crashreporter will write the crashlog. In the case of a GUI application it will also popup the 
crashreporter application.

In a GUI application this makes people think the application crashed while it actually is still 
running because mono catched the null exception.

So for gui applications this is a real issue.

One way to solve this is to use mach-o exception handlers instead of signals:
http://www.omnigroup.com/mailman/archive/macosx-dev/2000-June/002030.html

I asked Timothy J. Wood if this will make the crashreporter not popup. And he confirmed that it
will not pop it up and not write a crashlog.



---- Additional Comments From lupus@ximian.com 2005-05-10 10:01:03 MST ----

Whishlist as this is a osx bug and you can disable the buggy
crashreporter.



---- Additional Comments From joe@otee.dk 2005-05-10 12:21:49 MST ----

I can't tell really tell my end-users to disable the crashreporter unfortunately.




---- Additional Comments From grompf@sublimeintervention.com 2005-10-08 16:31:12 MST ----

Created an attachment (id=167875)
managed mach-exception handler




---- Additional Comments From grompf@sublimeintervention.com 2005-10-08 16:32:20 MST ----

I have attached a managed implementation of the mach-exception handler.  I'm using it in 
cocoa# successfully to suppress the crash reporter.

I dont really want to explain it or support it; so use it at your own risk; consider it BSD/X11 
licensed (which is what it is in fact)

-kangaroo




---- Additional Comments From miguel@ximian.com 2005-12-01 17:55:04 MST ----

The link that you provided no longer works.

Could you provide a new link?  



---- Additional Comments From robertj@gmx.net 2006-09-02 17:56:42 MST ----

The attached patch fixes the "problem" by installing a dummy
mach exception handler.

The logging in ~/Library/Logs/CrashReporter/ will be disabled
together with the annoying 1-2 seconds delay.

I didn't test it on x86, just on PPC.

Test case: :-)

class T
{
        static void Main ()
        {
                try {
                        null.Equals (null);
                } catch {
                        System.Console.WriteLine ("ok");
                }
        }
}




---- Additional Comments From robertj@gmx.net 2006-09-02 17:58:35 MST ----

Created an attachment (id=167876)
mini.diff




---- Additional Comments From miguel@ximian.com 2006-10-09 20:16:31 MST ----

Thanks for this patch Robert, I have applied it to SVN.

but we would love to get some feedback from OSX users.



---- Additional Comments From joe@otee.dk 2006-10-10 16:07:42 MST ----

First of all. Great initiative, thanks for looking into this.

The problem is that when the application really crashes. A sigseg in native code, then it 
will not bring up the crashreporter.

This makes it practically impossible to get crashlogs from end-users because they will 
never be printed to the console. We have a fairly large application which sometimes has 
bugs and we rely on users being able to send us crashlogs to fix them.

So for us to be able to use it, the solution would have to differentiate managed null 
reference exceptions and native sigsegvs.

For a managed null referenced exception it should stop the macho exception and continue 
running like nothing happened. For a native null reference, it should pass the exception 
on, thus causing the crash reporter to popup and print the stacktrace and other debug 
info.



---- Additional Comments From joe@otee.dk 2006-10-24 06:55:09 MST ----

Is it going to be possible to fix this issue?

I would really like to use the mach-o exception fix.

Imported an attachment (id=167875)
Imported an attachment (id=167876)

Unknown operating system unknown. Setting to default OS "Other".