[Mono-list] Weird crash with Remoting, native code exception

Helge Lenuweit helge at lenuweit.net
Thu Jun 22 06:50:02 EDT 2006

Hello guys,

I am running a client-server application with a remoting server 
operating under mono (1.1.15 compiled from source, running on SuSE 9.1 - 
for the records). The client (SWF) application gets a reference to the 
server's CAO-remoted object and everything runs just fine.

However, one server function attempts to call a method of a (Singleton) 
remoted object of another server (same machine, in this case). The 
object reference on that latter server is acquired via 
Activator.GetObject and this *seems* to work. (I can get the value of a 
remote string property). However, calling the method I intend to call 
crashes my (calling) server. The Singleton provider keeps running (or 
seems to be).

Usually using mono-service together with Robert Jordan's SuSE-compatible 
start script, I tried to run mono-service from the console with 
debugging symbols and all. When it comes to the crash, I see the 
following output:

Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.


Native stacktrace:

        mono(mono_handle_native_sigsegv+0x81) [0x8143c41]
        mono [0x8114a97]
        mono [0x8131001]
        mono(mono_runtime_invoke+0x1b) [0x80cc97b]
        mono(mono_runtime_delegate_invoke+0x2d) [0x80ccc3d]
        mono [0x80ae9e3]
        mono [0x80f4804]
        mono [0x810b5fb]
        /lib/tls/libpthread.so.0 [0x400be9dd]
        /lib/tls/libc.so.6(__clone+0x5a) [0x401aaffa]

Furthermore, this behaviour doesn't always occur. The two other chances 
are that it (a) just works and (b) returns with a handled exception in 
the calling server's code (NullReferenceException). AS I haven't found 
out why it does what and when, I'd appreciate hints on where to look 
further to track this down. I figured it could be related to:
- threading? (huh, bad luck given my current "threading"-skillset ;-)
- registering the remote object. However, in all cases, the called 
server's appropriate port is occupied when the program runs
- mono-service related issues (my call is: mono [--debug] 
-l:/var/run/<servicelock>.pid -m:<servicename> -d:<servicedir> 
<serviceassembly> --- and seems to work fine for both programs)

Many thanks for your assistance!
Best regards,

More information about the Mono-list mailing list