Turns out that we had two problems, a function pointer from a managed class being passed to an unmanaged function which would get invoked when the debugger which caused a segfault.
In my case, as was happening first while the debugger was paused. The SIGSEGV signal from the unmanaged code trying to invoke a function pointer that was gone then made the debugger-agent try to step. The assert is saying that a thread other than the debugger emitted the signal. I might think about submitting patch to cover this error condition with a better error message. Ian On Tue, Jan 15, 2013 at 10:02:49PM +0000, mickeyf wrote: > Yes, this could well be it. I have a couple of unmanaged libraries that are > continually receiving input and piping that back the the mono app. I'm not > using callbacks as such, but pipes. The unmanaged libraries are quite small > and simple and are not threaded themselves but each is continually looping, > and each is launched in a thread from the mono app. > > As far as the unmanaged code itself goes, if it fails to write back to the > mono app it should just log that and continue. I can see that the mono > runtime might not be so forgiving. > > But this doesn't explain why everything appears to be suspended when I have > no breakpoints at all. > > Thanks, > > Mickey > > > > -- > View this message in context: > http://mono.1490590.n4.nabble.com/remote-debugging-on-ARM-tp4658125p4658148.html > Sent from the Mono - General mailing list archive at Nabble.com. > _______________________________________________ > Mono-list maillist - [email protected] > http://lists.ximian.com/mailman/listinfo/mono-list _______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
