[Monodevelop-devel] Newbie question about soft debugger

[Christoph Müller]

Update:
I tried the second approach - to use AddVectoredExceptionHandler(1,
seh_handler) to inject the mono exception handler first in line into the
queue of exception handlers along the stack frame (with the unhandled
exception handler being last and never reached in my scenario).

It worked! I tried it with directly tweaking the mono sources
(exceptions-x86.c in line 249). To avoid using a tweaked mono I did the
following: right after embedding mono and setting it up for debugging (after
calling mono_jit_init) I added this to my own code (the application plugin
that embeds mono):

	LPTOP_LEVEL_EXCEPTION_FILTER seh_handler =
SetUnhandledExceptionFilter(NULL);
	AddVectoredExceptionHandler(1, seh_handler);
	SetUnhandledExceptionFilter(seh_handler);

So I retrieve the unhandled exception handler set by mono, re-set it as the
unhandled exception handler and additionally set it as the first-in-line
exception handler. And this works, too - without changing the mono sources.

Now I don't know what (probably critical) side effects this might cause. In
general swallowing all exceptions doesn't sound like too a good idea.
Frankly, I don't understand much of what happens in the seh_handler function
(exceptions-x86.c in line 174). I could imagine implementing some filter
function that does not call the original seh_handler on every signal but
only for those which are raised due to breakpoints. Any hints and comments
on that would be greatly appreciated.

Thanks a lot,
Christoph




------------------ old message --------------------------

Sorry to annoy you again. I'm still looking for a way to embed mono into a
C++Plugin-API of a commercial product (I don't have the sources) and still
trying to get the monodevelop soft-debugger connected. So I am initializing
mono from some C++ Plugin for that product I have written. I can start the
app from my self-written Monodevelop-Addon and everything runs quite well.
Whenever I set a breakpoint in Monodevelop, the app crashes when hitting the
breakpoint. 

As it seems, the product wraps every call to Plugins into some sort of __try
{} __except block. At least that's the most probable explanation why the
seh_handler set by SetUnhandledExceptionFilter (exceptions-x86.c) is never
reached - the exception (or segmentation fault) generated by a breakpoint is
swallowed by the application and results in an error message from the
application code. 

>From my plugin, I was able to set my own exception block around some code
calling into mono like the following:

MonoObject *CallPluginStart(MonoMethod *methodStart, void *pluginobject) {
	MonoObject *result = NULL;
	__try
	{
		// plugin.Start();
		result = mono_runtime_invoke(methodStart, pluginobject,
NULL, NULL);
	}
	__except(GetExceptionCode() == EXCEPTION_ACCESS_VIOLATION ?
EXCEPTION_EXECUTE_HANDLER) :
EXCEPTION_CONTINUE_SEARCH)
	{
		volatile int i = 42;
	}
	return result;
}

And I verified that I get into the exception block when a breakpoint is set
and that the invoke call returns without exception when no breakpoint is
hit. 

So now my question is: Is there a way to bypass the application's exception
handling to enable the seh_handler installed by mono to handle the
segmentation fault (and report the breakpoint hit to the to the connected
debugger)?

My first idea was to call the seh_handler directly from the code above, but
I had problems with building my mono-2.0-dll and I wanted to know if that's
a promising solution before carrying on. 

The other idea I had was: Why not install the exception handler using
AddVectoredExceptionHandler instead of (or in addition to)
SetUnhandledExceptionFilter. A handler installed that way can be told to be
the first in line, so it would be called before the application gets
signaled. Also trying this approach would mean that I need to build my own
mono-2.0.dll.

I'd be glad if you could give me some expert opinion what would be the best
way for me to proceed.

Thanks a lot,
Christoph