[Mono-devel-list] Mono crashes on managed null dereference when also using an embedded Mozilla

[Steven Brown]

Hello, I've got a testcase (MonoCrash.cs) that causes Mono (beta 1) to 
crash when a managed null dereference is caused anytime after setting up 
an embedded Mozilla (1.6).  I've tracked the problem down to this:


- Mozilla in nsProfileLock.cpp, when on UNIX and can use symlinks, wraps 
signals like SIGSEGV to assume a crash happened and clean up its locks.

- Mono uses the MMU to catch managed null dereferences, so generates 
such a signal whenever it occurs.

- Mozilla catches the signal first, cleans up its locks (bad!), and 
calls the old handler (Mono's).

- Mono gets into some sort of infinite loop trying to throw the 
exception and eventually the stack is full and cores (stacktrace.txt).


I'm thinking Mono got really confused by a non-mono stack frame in 
mono_arch_find_jit_info, and maybe caused a null dereference itself 
which caused the loop.  Any ideas?

As a related question, due to the way Mono checks for null dereferences 
(just lets them happen and raise a signal), Mozilla will see any null 
dereference anywhere inside of managed code as a reason to prepare to 
die, which is obviously bad, since the exception might not have been 
fatal to the managed code.  Should the Mozilla folks just trust in 
atexit(), or maybe not do this when Mozilla is being used embedded via 
gtkmozembed?


For reference, nsProfileLock.cpp (LockWithSymlink, FatalSignalHandler): 
http://lxr.mozilla.org/mozilla/source/profile/dirserviceprovider/src/nsProfileLock.cpp

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: stacktrace.txt
Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040525/101c0993/attachment.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: MonoCrash.cs
Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040525/101c0993/attachment.pl