Bugzilla – Bug 324232
[PATCH] Wrong Method Called via Remoting with Explicit Interface Implementation
Last modified: 2007-12-09 15:27:50 UTC
---- Reported by joncham@gmail.com 2007-05-07 15:08:51 MST ---- Please fill in this template when reporting a bug, unless you know what you are doing. Description of Problem: When calling a remote method that is on an explicitly implemented interface in the presence of another method of the same name, an InvalidCastException is thrown. Steps to reproduce the problem: 1. Run attached sample 2. 3. Actual Results: System.InvalidCastException: Return argument has an invalid type. at System.Runtime.Remoting.Proxies.RealProxy.ValidateReturnArg(Object arg, Ty pe paramType) at System.Runtime.Remoting.Proxies.RealProxy.PropagateOutParameters(IMessage msg, Object[] outArgs, Object returnValue) at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage req Msg, IMessage retMsg) at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgDa ta, Int32 type) at Common.ISayHello.SayHello() at ConsoleApplication1.Program.Main(String[] args) in C:\Documents and Settin gs\tmilntho\My Documents\Visual Studio 2005\Projects\ConsoleApplication1\Console Application1\Program.cs:line 24 Expected Results: Console output of: Hello How often does this happen? Everytime Additional Information: Also, note that if I change the method of the same name as the explicitly implemented method public byte[] SayHello() to public byte[] SayHelloABC() I still get an InvalidCastException, although with a different stack trace: System.InvalidCastException: Return value has an invalid type at System.Runtime.Remoting.Proxies.RealProxy.ProcessResponse (IMethodReturnMes sage mrm, System.Runtime.Remoting.Messaging.MonoMethodMessage call) [0x00000] at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke (System.Runtime.Rem oting.Proxies.RealProxy rp, IMessage msg, System.Exception& exc, System.Object[] & out_args) [0x00000] ---- Additional Comments From joncham@gmail.com 2007-05-07 15:11:06 MST ---- Created an attachment (id=171922) Test Case - 81554.zip ---- Additional Comments From joncham@gmail.com 2007-05-07 15:12:34 MST ---- For test case, ConsoleApplication2 is Server. ConsoleApplication1 is Client. ClassLibrary1 has the common library used by both. ---- Additional Comments From robertj@gmx.net 2007-05-07 16:29:01 MST ---- There is another bug entry about this but I cannot find it ATM :-/ Anyhow, I'm looking at the issue. ---- Additional Comments From robertj@gmx.net 2007-05-07 16:30:14 MST ---- Here is it: https://bugzilla.novell.com/show_bug.cgi?id=MONO76295. ---- Additional Comments From joncham@gmail.com 2007-05-07 17:03:21 MST ---- Sorry, I searched as well since this sounded familiar, but a bugzilla search of 'remoting explicit' returned no matches so I filed. Thanks for looking at the issue. ---- Additional Comments From robertj@gmx.net 2007-05-07 20:01:58 MST ---- Created an attachment (id=171923) RemotingServices.diff ---- Additional Comments From robertj@gmx.net 2007-05-07 20:07:14 MST ---- There is still one issue left: MS.NET doesn't accept Mono's MethodCallMessage because it doesn't expect methods to be called "ITest.Foo" (including the interface name). It seems that in some places mono is still not resolving the method correctly. ---- Additional Comments From robertj@gmx.net 2007-06-10 18:48:08 MST ---- Created an attachment (id=171924) remotingservices-execute.diff ---- Additional Comments From robertj@gmx.net 2007-06-10 18:48:37 MST ---- Patch updated to support generics. ---- Additional Comments From robertj@gmx.net 2007-08-30 18:54:01 MST ---- Created an attachment (id=171925) bug-81554.diff ---- Additional Comments From robertj@gmx.net 2007-08-30 18:57:35 MST ---- The patch fixes the issue mentioned above and updates the generics support. ---- Additional Comments From robertj@gmx.net 2007-08-30 19:00:27 MST ---- *** https://bugzilla.novell.com/show_bug.cgi?id=MONO82302 has been marked as a duplicate of this bug. *** ---- Additional Comments From jan.oravec@6com.sk 2007-08-31 08:04:21 MST ---- The patch works perfectly, thanks! It even solves some other issues I was going to report :). ---- Additional Comments From lluis@ximian.com 2007-09-03 07:31:53 MST ---- The patch looks ok to me. ---- Additional Comments From robertj@gmx.net 2007-09-08 19:35:26 MST ---- Fixed in SVN. This bug depended on bug(s) 78882. Imported an attachment (id=171922) Imported an attachment (id=171923) Imported an attachment (id=171924) Imported an attachment (id=171925) Unknown operating system unknown. Setting to default OS "Other".
*** Bug 325501 has been marked as a duplicate of this bug. ***
I get the following exception running my repro for this issue (located in gert/standalone/bug81554 in SVN): Unhandled Exception: System.InvalidCastException: Return value has an invalid ty pe at System.Runtime.Remoting.Proxies.RealProxy.ProcessResponse (IMethodReturnMes sage mrm, System.Runtime.Remoting.Messaging.MonoMethodMessage call) [0x00000] at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke (System.Runtime.Rem oting.Proxies.RealProxy rp, IMessage msg, System.Exception& exc, System.Object[] & out_args) [0x00000]
Fixed in SVN r88433-88435
Running my test case for bug #324971(gert/standalone/bug82302 in SVN) still fails with a SIGSEGV: Stacktrace: at (wrapper managed-to-native) System.Runtime.Remoting.RemotingServices.GetVirtualMethod (System.Type,System.Reflection.MethodBase) <0x00004> at (wrapper managed-to-native) System.Runtime.Remoting.RemotingServices.GetVirtualMethod (System.Type,System.Reflection.MethodBase) <0xffffffff> at System.Runtime.Remoting.Messaging.MethodCall.ResolveMethod () <0x00121> at System.Runtime.Remoting.Messaging.MethodCall..ctor (System.Runtime.Remoting.Messaging.Header[]) <0x00074> at System.Runtime.Serialization.Formatters.Binary.MessageFormatter.ReadMethodCall (System.IO.BinaryReader,bool,System.Runtime.Remoting.Messaging.HeaderHandler,System.Runtime.Serialization.Formatters.Binary.BinaryFormatter) <0x0051b> at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.NoCheckDeserialize (System.IO.Stream,System.Runtime.Remoting.Messaging.HeaderHandler) <0x000c3> at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize (System.IO.Stream,System.Runtime.Remoting.Messaging.HeaderHandler) <0x00010> at System.Runtime.Remoting.Channels.BinaryServerFormatterSink.ProcessMessage (System.Runtime.Remoting.Channels.IServerChannelSinkStack,System.Runtime.Remoting.Messaging.IMessage,System.Runtime.Remoting.Channels.ITransportHeaders,System.IO.Stream,System.Runtime.Remoting.Messaging.IMessage&,System.Runtime.Remoting.Channels.ITransportHeaders&,System.IO.Stream&) <0x00256> at System.Runtime.Remoting.Channels.Tcp.TcpServerTransportSink.InternalProcessMessage (System.Runtime.Remoting.Channels.Tcp.ClientConnection,System.IO.Stream) <0x00193> at System.Runtime.Remoting.Channels.Tcp.ClientConnection.ProcessMessages () <0x000c3> at System.Runtime.Remoting.Channels.RemotingThreadPool.PoolThread () <0x00160> at (wrapper delegate-invoke) System.MulticastDelegate.invoke_void () <0xffffffff> at (wrapper runtime-invoke) System.Security.Cryptography.RNGCryptoServiceProvider.runtime_invoke_void (object,intptr,intptr,intptr) <0xffffffff> Native stacktrace: /home/gert/mono/install/bin/mono [0x816241e] /home/gert/mono/install/bin/mono [0x807d251] [0xffffe440] [0xb6ef20b2] [0xb6ef17a2] [0xb6ef1485] [0xb6eeda44] [0xb6eec9fc] [0xb6eec921] [0xb6eec2af] [0xb71138dc] [0xb71125bc] [0xb71123f1] [0xb710cc12] [0xb7124cd9] /home/gert/mono/install/bin/mono(mono_runtime_delegate_invoke+0x36) [0x80ea966] /home/gert/mono/install/bin/mono [0x80e8bfe] /home/gert/mono/install/bin/mono [0x810ca22] /home/gert/mono/install/bin/mono [0x8120c05] /lib/tls/i686/cmov/libpthread.so.0 [0xb7e7b46b] /lib/tls/i686/cmov/libc.so.6(clone+0x5e) [0xb7dda6de] Debug info from gdb: Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1211083056 (LWP 12705)] [New Thread -1224737904 (LWP 12715)] [New Thread -1223668848 (LWP 12708)] [New Thread -1220346992 (LWP 12707)] [New Thread -1220199536 (LWP 12706)] 0xffffe410 in __kernel_vsyscall () 5 Thread -1220199536 (LWP 12706) 0xffffe410 in __kernel_vsyscall () 4 Thread -1220346992 (LWP 12707) 0xffffe410 in __kernel_vsyscall () 3 Thread -1223668848 (LWP 12708) 0xffffe410 in __kernel_vsyscall () 2 Thread -1224737904 (LWP 12715) 0xffffe410 in __kernel_vsyscall () 1 Thread -1211083056 (LWP 12705) 0xffffe410 in __kernel_vsyscall () Thread 5 (Thread -1220199536 (LWP 12706)): #0 0xffffe410 in __kernel_vsyscall () #1 0xb7e829f6 in ?? () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0810b481 in collection_thread (unused=0x0) at collection.c:34 #3 0xb7e7b46b in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #4 0xb7dda6de in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 4 (Thread -1220346992 (LWP 12707)): #0 0xffffe410 in __kernel_vsyscall () #1 0xb7e7f676 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x080fe19f in timedwait_signal_poll_cond (cond=0xb792d1dc, mutex=0xb792d1c4, timeout=0x0, alertable=0) at handles.c:1443 #3 0x08100c3f in _wapi_handle_timedwait_signal_handle (handle=0x404, timeout=0x0, alertable=0) at handles.c:1523 #4 0x08100cbc in _wapi_handle_wait_signal_handle (handle=0x404, alertable=0) at handles.c:1483 #5 0x080fd3df in WaitForSingleObjectEx (handle=0x404, timeout=4294967295, alertable=0) at wait.c:200 #6 0x080cb59a in finalizer_thread (unused=0x0) at gc.c:843 #7 0x080e8b94 in start_wrapper (data=0x82416e8) at threads.c:550 #8 0x0810ca22 in thread_start_routine (args=0xb77d98a0) at threads.c:264 #9 0x08120c05 in GC_start_routine (arg=0x22f40) at pthread_support.c:1369 #10 0xb7e7b46b in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #11 0xb7dda6de in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 3 (Thread -1223668848 (LWP 12708)): #0 0xffffe410 in __kernel_vsyscall () #1 0xb7e82418 in accept () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x08101687 in _wapi_accept (fd=5, addr=0x0, addrlen=0x0) at sockets.c:201 #3 0x0817c96b in ves_icall_System_Net_Sockets_Socket_Accept_internal (sock=5, error=0xb71041dc) at socket-io.c:779 #4 0xb710d04a in ?? () #5 0x00000005 in ?? () #6 0xb71041dc in ?? () #7 0x082a69d8 in ?? () #8 0x082075e8 in ?? () #9 0x00000000 in ?? () Thread 2 (Thread -1224737904 (LWP 12715)): #0 0xffffe410 in __kernel_vsyscall () #1 0xb7dd32a1 in select () from /lib/tls/i686/cmov/libc.so.6 #2 0xb7ef2780 in g_spawn_sync () from /usr/lib/libglib-2.0.so.0 #3 0xb7ef2b4c in g_spawn_command_line_sync () from /usr/lib/libglib-2.0.so.0 #4 0x081624b9 in mono_handle_native_sigsegv (signal=11, ctx=0xb6efed0c) at mini-exceptions.c:1061 #5 0x0807d251 in mono_arch_handle_altstack_exception (sigctx=0xb6efed0c, fault_addr=0x0, stack_ovf=0) at exceptions-x86.c:854 #6 <signal handler called> #7 0x0816bdc8 in ves_icall_Remoting_RemotingServices_GetVirtualMethod ( rtype=0x2be70, rmethod=0x5ebe8) at icall.c:6300 #8 0xb6ef20b2 in ?? () #9 0x0002be70 in ?? () #10 0x0005ebe8 in ?? () #11 0x08294628 in ?? () #12 0x00000001 in ?? () #13 0x000cbc40 in ?? () #14 0x00000012 in ?? () #15 0x0005ec00 in ?? () #16 0x000ddea8 in ?? () #17 0x0002be70 in ?? () #18 0xb6ffeed4 in ?? () #19 0xb6ef208c in ?? () #20 0xb6ffef08 in ?? () #21 0xb6ef17a2 in ?? () #22 0x0002be70 in ?? () #23 0x0005ebe8 in ?? () #24 0xb6ffef00 in ?? () #25 0x000ddea8 in ?? () #26 0x000d6678 in ?? () #27 0x0005ebe8 in ?? () #28 0x0105ec00 in ?? () #29 0x000cbc40 in ?? () #30 0x00000006 in ?? () #31 0x00062f28 in ?? () #32 0x0005ec00 in ?? () #33 0xb6ffef28 in ?? () #34 0xb6ef1485 in ?? () #35 0x000ddea8 in ?? () #36 0x00000006 in ?? () #37 0x00062f28 in ?? () #38 0x000dbf50 in ?? () #39 0x00060af0 in ?? () #40 0x00060c58 in ?? () #41 0xb6ffefb4 in ?? () #42 0xb6eeda44 in ?? () #43 0x000ddea8 in ?? () #44 0x00062f28 in ?? () #45 0x00060b18 in ?? () #46 0x000d6690 in ?? () #47 0xb6ffef84 in ?? () #48 0x0005ec00 in ?? () #49 0x00062f28 in ?? () #50 0x12060b18 in ?? () #51 0x00060af0 in ?? () #52 0xb6fff004 in ?? () #53 0xb7bd2066 in ?? () #54 0x000ddea8 in ?? () #55 0x000dbf50 in ?? () #56 0x00000001 in ?? () #57 0x0006dea0 in ?? () #58 0x0006dea0 in ?? () #59 0x00000000 in ?? () Thread 1 (Thread -1211083056 (LWP 12705)): #0 0xffffe410 in __kernel_vsyscall () #1 0xb7e821fb in ?? () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0810773a in console_read (handle=0x0, buffer=0xb6ab0, numbytes=1024, bytesread=0xbfac1458, overlapped=0x0) at io.c:1069 #3 0x08108c8d in ReadFile (handle=0x0, buffer=0xb6ab0, numbytes=1024, bytesread=0xbfac1458, overlapped=0x0) at io.c:2271 #4 0x0817d776 in ves_icall_System_IO_MonoIO_Read (handle=0x0, dest=0xb6aa0, dest_offset=0, count=748208, error=0xbfac14c8) at file-io.c:634 #5 0xb7984dbb in ?? () #6 0x00000000 in ?? () #0 0xffffe410 in __kernel_vsyscall () ================================================================= 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. ================================================================= [exec] [exec] Unhandled Exception: System.Runtime.Remoting.RemotingException: Tcp transport error. [exec] [exec] Server stack trace: [exec] at System.Runtime.Remoting.Channels.Tcp.TcpMessageIO.ReceiveMessageStatus (System.IO.Stream networkStream, System.Byte[] buffer) [0x00000] [exec] at System.Runtime.Remoting.Channels.Tcp.TcpClientTransportSink.ProcessMessage (IMessage msg, ITransportHeaders requestHeaders, System.IO.Stream requestStream, ITransportHeaders& responseHeaders, System.IO.Stream& responseStream) [0x00000] [exec] at System.Runtime.Remoting.Channels.BinaryClientFormatterSink.SyncProcessMessage (IMessage msg) [0x00000] [exec] [exec] Exception rethrown at [0]: [exec] ---> System.Runtime.Remoting.RemotingException: Connection closed [exec] at System.Runtime.Remoting.Channels.Tcp.TcpMessageIO.StreamRead (System.IO.Stream networkStream, System.Byte[] buffer, Int32 count) [0x00000] [exec] at System.Runtime.Remoting.Channels.Tcp.TcpMessageIO.ReceiveMessageStatus (System.IO.Stream networkStream, System.Byte[] buffer) [0x00000] --- End of inner exception stack trace --- [exec] [exec] at System.Runtime.Remoting.Channels.Tcp.TcpMessageIO.ReceiveMessageStatus (System.IO.Stream networkStream, System.Byte[] buffer) [0x00000] [exec] at System.Runtime.Remoting.Channels.Tcp.TcpClientTransportSink.ProcessMessage (IMessage msg, ITransportHeaders requestHeaders, System.IO.Stream requestStream, ITransportHeaders& responseHeaders, System.IO.Stream& responseStream) [0x00000] [exec] at System.Runtime.Remoting.Channels.BinaryClientFormatterSink.SyncProcessMessage (IMessage msg) [0x00000]
This is caused by the real issue behind bug #324971: RemotingServices.Marshal (mbr, uri, typeof (SomeInterfaceImplementedByMbr)) was either not supported or it regressed in the meantime. When trunk is open again, I'll commit a patch.
Robert, did you have to look into this?
Gert, I even have a fix for it, but I hesitated to commit it because I don't have another test case than yours. I tried to build one but missed and got distracted. If you want the patches, I could attach them. Just ask.
If you have a patch and it does not introduce (known) regressions, then committing it now would give people more time to spot regressions. I assume the next official release (after 1.2.6) is still several months away...
Fixed in SVN r91003:91004 r91003 is the real fix, while r91004 fixes a missing argument validation that led to the runtime crash.