Bugzilla – Bug 321598
[PATCH] Remoting/generics support missing.
Last modified: 2007-11-08 10:59:34 UTC
---- Reported by paussems@dti-be.com 2006-07-17 10:11:02 MST ---- Description of Problem: When a client tries to invoke a remote method using .NET remoting, the client crashes. Running the same executable from Microsoft .NET works like a charm. The signature of the method that should be called is public Domain OpenDomain(IMultilonClient multilon_client, string user, string password) Actual Results: ** ERROR **: file mini.c: line 3742 (mono_method_to_ir): assertion failed: (!sig->has_type_parameters) aborting... ================================================================= Got a SIGABRT while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application. ================================================================= Stacktrace: at (wrapper managed-to-native) System.Runtime.Remoting.Proxies.RealProxy.InternalGetTransparentProxy (string) <0x00004> at (wrapper managed-to-native) System.Runtime.Remoting.Proxies.RealProxy.InternalGetTransparentProxy (string) <0xffffffff> at System.Runtime.Remoting.Proxies.RealProxy.GetTransparentProxy () <0x0010a> at System.Runtime.Remoting.RemotingServices.GetOrCreateClientIdentity (System.Runtime.Remoting.ObjRef,System.Type,object&) <0x00212> at System.Runtime.Remoting.RemotingServices.GetRemoteObject (System.Runtime.Remoting.ObjRef,System.Type) <0x0001b> at System.Runtime.Remoting.RemotingServices.GetProxyForRemoteObject (System.Runtime.Remoting.ObjRef,System.Type) <0x00059> at System.Runtime.Remoting.RemotingServices.Unmarshal (System.Runtime.Remoting.ObjRef,bool) <0x0011e> at System.Runtime.Remoting.RemotingServices.Unmarshal (System.Runtime.Remoting.ObjRef) <0x0000c> at System.Runtime.Remoting.ObjRef.GetRealObject (System.Runtime.Serialization.StreamingContext) <0x00020> at System.Runtime.Serialization.ObjectRecord.LoadData (System.Runtime.Serialization.ObjectManager,System.Runtime.Serialization.ISurrogateSelector,System.Runtime.Serialization.StreamingContext) <0x003a1> at System.Runtime.Serialization.ObjectManager.DoFixups () <0x00121> at System.Runtime.Serialization.Formatters.Binary.ObjectReader.ReadNextObject (System.IO.BinaryReader) <0x00042> at System.Runtime.Serialization.Formatters.Binary.ObjectReader.ReadObjectGraph (System.IO.BinaryReader,bool,object&,System.Runtime.Remoting.Messaging.Header[]&) <0x000a6> at System.Runtime.Serialization.Formatters.Binary.MessageFormatter.ReadMethodResponse (System.IO.BinaryReader,bool,System.Runtime.Remoting.Messaging.HeaderHandler,System.Runtime.Remoting.Messaging.IMethodCallMessage,System.Runtime.Serialization.Formatters.Binary.BinaryFormatter) <0x002a9> at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.NoCheckDeserializeMethodResponse (System.IO.Stream,System.Runtime.Remoting.Messaging.HeaderHandler,System.Runtime.Remoting.Messaging.IMethodCallMessage) <0x00085> at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.DeserializeMethodResponse (System.IO.Stream,System.Runtime.Remoting.Messaging.HeaderHandler,System.Runtime.Remoting.Messaging.IMethodCallMessage) <0x00013> at System.Runtime.Remoting.Channels.BinaryClientFormatterSink.SyncProcessMessage (System.Runtime.Remoting.Messaging.IMessage) <0x00347> at System.Runtime.Remoting.Proxies.RemotingProxy.Invoke (System.Runtime.Remoting.Messaging.IMessage) <0x002dd> at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke (System.Runtime.Remoting.Proxies.RealProxy,System.Runtime.Remoting.Messaging.IMessage,System.Exception&,object[]&) <0x002e3> at (wrapper runtime-invoke) System.Object.runtime_invoke_object_RealProxy_IMessage_Exception&_object[]& (object,intptr,intptr,intptr) <0xffffffff> at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_remoting_wrapper (intptr,intptr) <0x00004> at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_remoting_wrapper (intptr,intptr) <0xffffffff> at (wrapper remoting-invoke) Multilon.MultilonService.OpenDomain (Multilon.IMultilonClient,string,string) <0xffffffff> at (wrapper remoting-invoke-with-check) Multilon.MultilonService.OpenDomain (Multilon.IMultilonClient,string,string) <0xffffffff> at Multilon.MultilonClient.ConnectToMultilon (System.Net.IPEndPoint) <0x00073> at Client.Main () <0x002a5> at MultilonTest.Program.Main (string[]) <0x0001f> at (wrapper runtime-invoke) System.Object.runtime_invoke_void_string[] (object,intptr,intptr,intptr) <0xffffffff> Native stacktrace: /opt/mono-20060713/bin/mono(mono_handle_native_sigsegv+0xf5) [0x815e015] [0xffffe440] /lib/tls/i686/cmov/libc.so.6(abort+0xeb) [0xa7dc2f9b] /usr/lib/libglib-2.0.so.0(g_logv+0x454) [0xa7f56974] /usr/lib/libglib-2.0.so.0(g_log+0x29) [0xa7f569a9] /usr/lib/libglib-2.0.so.0(g_assert_warning+0x77) [0xa7f56a27] /opt/mono-20060713/bin/mono [0x8132926] /opt/mono-20060713/bin/mono [0x81474cb] /opt/mono-20060713/bin/mono [0x8148e9f] /opt/mono-20060713/bin/mono [0x812b654] /opt/mono-20060713/bin/mono [0x80d88b8] /opt/mono-20060713/bin/mono(mono_remote_class_vtable+0x78) [0x80d8be8] /opt/mono-20060713/bin/mono [0x80e70f6] [0xa7b4fe01] [0xa7b4fce3] [0xa7b4d643] [0xa7b4d314] [0xa6c8226a] [0xa6c8215f] [0xa6c82025] [0xa6c81ff9] [0xa6c81882] [0xa6c8127a] [0xa6c7d3f3] [0xa6c7d347] [0xa70912aa] [0xa7b5b93e] [0xa7b5b70c] [0xa7b52d68] [0xa7b5239e] [0xa7b51194] [0xa7b509dd] /opt/mono-20060713/bin/mono(mono_remoting_invoke+0x48) [0x80da4b8] /opt/mono-20060713/bin/mono [0x80a3c44] [0xa7b507f1] [0xa7091fcc] [0xa7091f34] [0xa7b50594] [0xa75ea756] [0xa75e9b20] [0xa75e9a73] /opt/mono-20060713/bin/mono(mono_runtime_exec_main+0x60) [0x80d9670] /opt/mono-20060713/bin/mono(mono_runtime_run_main+0x171) [0x80dcdc1] /opt/mono-20060713/bin/mono(mono_main+0x102a) [0x805d3ba] /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xd0) [0xa7daceb0] /opt/mono-20060713/bin/mono [0x805be11] Aborted Additional Information: Running mono from CVS checked out on 2006/07/13 ---- Additional Comments From vargaz@gmail.com 2006-07-17 14:16:41 MST ---- Please attach some kind of self-contained testcase. ---- Additional Comments From paussems@dti-be.com 2006-07-18 12:19:27 MST ---- It took me quite some time to isolate the origin of the problem, but I managed to make a small client/server application that reproduces the problem. It seems the origin of the crash is that the result of a method is an object that contains an overloaded generic method. By the way if the MONO defined is not set, the code won't compile. This is another problem that's compiler related (compiler says that 'The as operator requires that the `SubT' type parameter be constrained by a class, but it is in the base). I will file another bug report for this. The attached test case contains a Makefile that has to be edited in order to set the path to gmcs and mono. After a 'make', run 'mono Server.exe' and then 'mono Client.exe', and the client will crash Best regards, Patrick Aussems ---- Additional Comments From paussems@dti-be.com 2006-07-18 12:22:07 MST ---- Created an attachment (id=170124) Test case ---- Additional Comments From paussems@dti-be.com 2006-08-18 11:38:58 MST ---- Hello, Is there somebody working on this problem? I'm asking because this bug prevents us from deploying our application and the deadline is approaching! If I can be of any help, please ask. Patrick Aussems ---- Additional Comments From lluis@ximian.com 2006-08-23 06:47:33 MST ---- Generic methods are not currently supported by the remoting infrastructure. My advice is to stick to the stable .NET 1.1 API in this area. ---- Additional Comments From robertj@gmx.net 2007-01-09 07:24:04 MST ---- Fixed in SVN. ---- Additional Comments From gert.driesen@pandora.be 2007-01-17 16:16:21 MST ---- I get a SIGABRT running Patrick's repro on SVN head: ** ERROR **: file mini.c: line 3905 (mono_method_to_ir): assertion failed: (!sig->has_type_parameters) aborting... Stacktrace: at (wrapper managed-to-native) System.Runtime.Remoting.Proxies.RealProxy.InternalGetTransparentProxy (string) <0x00004> at (wrapper managed-to-native) System.Runtime.Remoting.Proxies.RealProxy.InternalGetTransparentProxy (string) <0xffffffff> at System.Runtime.Remoting.Proxies.RealProxy.GetTransparentProxy () <0x0010a> at System.Runtime.Remoting.RemotingServices.GetOrCreateClientIdentity (System.Runtime.Remoting.ObjRef,System.Type,object&) <0x00212> at System.Runtime.Remoting.RemotingServices.GetRemoteObject (System.Runtime.Remoting.ObjRef,System.Type) <0x0001b> at System.Runtime.Remoting.RemotingServices.GetProxyForRemoteObject (System.Runtime.Remoting.ObjRef,System.Type) <0x00055> at System.Runtime.Remoting.RemotingServices.Unmarshal (System.Runtime.Remoting.ObjRef,bool) <0x0011e> at System.Runtime.Remoting.RemotingServices.Unmarshal (System.Runtime.Remoting.ObjRef) <0x0000c> at System.Runtime.Remoting.ObjRef.GetRealObject (System.Runtime.Serialization.StreamingContext) <0x00020> at System.Runtime.Serialization.ObjectRecord.LoadData (System.Runtime.Serialization.ObjectManager,System.Runtime.Serialization.ISurrogateSelector,System.Runtime.Serialization.StreamingContext) <0x003b5> at System.Runtime.Serialization.ObjectManager.DoFixups () <0x00129> at System.Runtime.Serialization.Formatters.Binary.ObjectReader.ReadNextObject (System.IO.BinaryReader) <0x00042> at System.Runtime.Serialization.Formatters.Binary.ObjectReader.ReadObjectGraph (System.IO.BinaryReader,bool,object&,System.Runtime.Remoting.Messaging.Header[]&) <0x000b6> at System.Runtime.Serialization.Formatters.Binary.MessageFormatter.ReadMethodResponse (System.IO.BinaryReader,bool,System.Runtime.Remoting.Messaging.HeaderHandler,System.Runtime.Remoting.Messaging.IMethodCallMessage,System.Runtime.Serialization.Formatters.Binary.BinaryFormatter) <0x00283> at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.NoCheckDeserializeMethodResponse (System.IO.Stream,System.Runtime.Remoting.Messaging.HeaderHandler,System.Runtime.Remoting.Messaging.IMethodCallMessage) <0x00095> at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.DeserializeMethodResponse (System.IO.Stream,System.Runtime.Remoting.Messaging.HeaderHandler,System.Runtime.Remoting.Messaging.IMethodCallMessage) <0x00013> at System.Runtime.Remoting.Channels.BinaryClientFormatterSink.SyncProcessMessage (System.Runtime.Remoting.Messaging.IMessage) <0x00347> at System.Runtime.Remoting.Proxies.RemotingProxy.Invoke (System.Runtime.Remoting.Messaging.IMessage) <0x002dd> at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke (System.Runtime.Remoting.Proxies.RealProxy,System.Runtime.Remoting.Messaging.IMessage,System.Exception&,object[]&) <0x002e3> at (wrapper runtime-invoke) System.Object.runtime_invoke_object_RealProxy_IMessage_Exception&_object[]& (object,intptr,intptr,intptr) <0xffffffff> at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_remoting_wrapper (intptr,intptr) <0x00004> at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_remoting_wrapper (intptr,intptr) <0xffffffff> at (wrapper remoting-invoke) Test.ServerLib.Test () <0xffffffff> at (wrapper remoting-invoke-with-check) Test.ServerLib.Test () <0xffffffff> at Test.Program.Main (string[]) <0x0009b> at (wrapper runtime-invoke) System.Object.runtime_invoke_int_string[] (object,intptr,intptr,intptr) <0xffffffff> Native stacktrace: /home/monohead/mono/install/bin/mono [0x816677a] [0xffffe440] /lib/libc.so.6(abort+0xeb) [0xb7db3093] /usr/lib/libglib-2.0.so.0(g_log+0) [0xb7f1b86c] Debug info from gdb: Using host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1210550592 (LWP 27005)] [New Thread -1224504416 (LWP 27015)] [New Thread -1223386208 (LWP 27013)] [New Thread -1219044448 (LWP 27011)] [New Thread -1213342816 (LWP 27007)] 0xffffe410 in ?? () 5 Thread -1213342816 (LWP 27007) 0xffffe410 in ?? () 4 Thread -1219044448 (LWP 27011) 0xffffe410 in ?? () 3 Thread -1223386208 (LWP 27013) 0xffffe410 in ?? () 2 Thread -1224504416 (LWP 27015) 0xffffe410 in ?? () 1 Thread -1210550592 (LWP 27005) 0xffffe410 in ?? () Thread 5 (Thread -1213342816 (LWP 27007)): #0 0xffffe410 in ?? () #1 0xb7add438 in ?? () #2 0x081f5ba0 in ?? () #3 0x00000000 in ?? () Thread 4 (Thread -1219044448 (LWP 27011)): #0 0xffffe410 in ?? () #1 0xb756d238 in ?? () #2 0x00000001 in ?? () #3 0x00000000 in ?? () Thread 3 (Thread -1223386208 (LWP 27013)): #0 0xffffe410 in ?? () #1 0xb71491c4 in ?? () #2 0x081f5ba0 in ?? () #3 0xb714919c in ?? () #4 0xb7ed1d78 in accept () from /lib/libpthread.so.0 #5 0x081122b6 in _wapi_accept (fd=11, addr=0x0, addrlen=0x0) at sockets.c:199 #6 0x080cd3d7 in ves_icall_System_Net_Sockets_Socket_Accept_internal ( sock=4294966784, error=0xb7149284) at socket-io.c:793 #7 0xb71511da in ?? () #8 0x0000000b in ?? () #9 0xb7149284 in ?? () #10 0x084679d8 in ?? () #11 0x00021898 in ?? () #12 0x00021ed8 in ?? () #13 0x0008a848 in ?? () #14 0xb7149274 in ?? () #15 0x00043d90 in ?? () #16 0xb7149214 in ?? () #17 0xb71511b4 in ?? () #18 0xb71492a4 in ?? () #19 0xb7150ffa in ?? () #20 0x0000000b in ?? () #21 0xb7149284 in ?? () #22 0xb7150f23 in ?? () #23 0xb7150f70 in ?? () #24 0x084492dc in ?? () #25 0xb7149260 in ?? () #26 0x08076612 in mono_magic_trampoline (regs=0xfffffe00, code=0xb7149284 "", m=0x8a848, tramp=0xb7150f70 "U\213WV\203xE") at mini-trampolines.c:58 Thread 2 (Thread -1224504416 (LWP 27015)): #0 0xffffe410 in ?? () #1 0xb703826c in ?? () #2 0x081f5ba0 in ?? () #3 0xb703824c in ?? () #4 0xb7ed2356 in __nanosleep_nocancel () from /lib/libpthread.so.0 #5 0x08106786 in SleepEx (ms=0, alertable=1) at threads.c:997 #6 0x080b3052 in ves_icall_System_Threading_Thread_Sleep_internal (ms=3000) at threads.c:605 #7 0xb704375e in ?? () #8 0x00000bb8 in ?? () #9 0x0848d190 in ?? () #10 0xb7ad9b20 in ?? () #11 0x00021ed8 in ?? () #12 0x0008a758 in ?? () #13 0x00000bb8 in ?? () #14 0x00000000 in ?? () Thread 1 (Thread -1210550592 (LWP 27005)): #0 0xffffe410 in ?? () #1 0xbfbca6dc in ?? () #2 0x00000000 in ?? () #0 0xffffe410 in ?? () ================================================================= Got a SIGABRT while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application. ================================================================= ---- Additional Comments From robertj@gmx.net 2007-01-18 10:18:02 MST ---- That's an assembly identity issue. I overlooked it because Mono's remoting tests are all implemented in the same assembly, while this test case employs a shared assembly. I'm on this. ---- Additional Comments From robertj@gmx.net 2007-01-20 20:29:29 MST ---- Nah, this was not an "assembly identity issue". I simply didn't test virtual & interface method calls while implementing the code in https://bugzilla.novell.com/show_bug.cgi?id=MONO80383. About the patch: I'm not sure why we need to use mono_marshal_get_remoting_invoke_with_check () for closed generic methods. ---- Additional Comments From robertj@gmx.net 2007-01-20 20:30:11 MST ---- Created an attachment (id=170125) bug-78882.diff ---- Additional Comments From robertj@gmx.net 2007-01-20 20:31:06 MST ---- Created an attachment (id=170126) bug-78882.cs ---- Additional Comments From robertj@gmx.net 2007-01-20 20:32:59 MST ---- bug-78882.cs is just another test case which also checks interface calls. ---- Additional Comments From lluis@ximian.com 2007-05-07 12:26:47 MST ---- I'm unsure about this one. I'm wondering why remoting trampolines are not required for generic methods. ---- Additional Comments From robertj@gmx.net 2007-05-07 16:21:40 MST ---- Because virtual open generic methods (I mean those: Method <T> ()) don't need a trampoline. Those methods are never called. Only the inflated methods are called, and those get their remoting wrappers from mono_get_virtual_method (). ---- Additional Comments From miguel@ximian.com 2007-06-08 13:06:17 MST ---- Ping, is this good to go? ---- Additional Comments From lluis@ximian.com 2007-06-08 13:37:56 MST ---- Looks ok to me. ---- Additional Comments From robertj@gmx.net 2007-06-10 18:51:23 MST ---- The patch depends on https://bugzilla.novell.com/show_bug.cgi?id=MONO81554. Please review it as well. ---- Additional Comments From robertj@gmx.net 2007-06-10 18:59:42 MST ---- "Depends" was the wrong term. This patch is for the client side, https://bugzilla.novell.com/show_bug.cgi?id=MONO81554 is for the server side. ---- Additional Comments From robertj@gmx.net 2007-06-10 19:22:00 MST ---- Created an attachment (id=170127) bug-78882-tcp.cs ---- Additional Comments From robertj@gmx.net 2007-06-10 19:23:05 MST ---- The updated test case exercises both #78882 and ##81554. ---- Additional Comments From robertj@gmx.net 2007-08-25 15:16:16 MST ---- *** https://bugzilla.novell.com/show_bug.cgi?id=MONO82595 has been marked as a duplicate of this bug. *** ---- Additional Comments From robertj@gmx.net 2007-08-25 15:17:44 MST ---- the patches doesn't apply anymore. I'll provide an update ASAP. ---- Additional Comments From jan.oravec@6com.sk 2007-08-25 16:17:36 MST ---- Sorry for filling duplicate, I wasn't sure if it's same or not. I will be happy to test any patches and provide feedback. ---- Additional Comments From jan.oravec@6com.sk 2007-08-26 10:15:09 MST ---- I looked at the patch -- it applies ok to mono 1.2.5 preview 5. I am still getting this exception (printed by client side, but looks like it happens on server side): Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object Server stack trace: at System.Runtime.Remoting.Messaging.MethodCall.ResolveMethod () [0x00000] at System.Runtime.Remoting.Messaging.MethodCall..ctor (System.Runtime.Remoting.Messaging.Header[] headers) [0x00000] at System.Runtime.Serialization.Formatters.Binary.MessageFormatter.ReadMethodCall (System.IO.BinaryReader reader, Boolean hasHeaders, System.Runtime.Remoting.Messaging.HeaderHandler headerHandler, System.Runtime.Serialization.Formatters.Binary.BinaryFormatter formatter) [0x00000] at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.NoCheckDeserialize (System.IO.Stream serializationStream, System.Runtime.Remoting.Messaging.HeaderHandler handler) [0x00000] at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize (System.IO.Stream serializationStream, System.Runtime.Remoting.Messaging.HeaderHandler handler) [0x00000] at System.Runtime.Remoting.Channels.BinaryServerFormatterSink.ProcessMessage (IServerChannelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders requestHeaders, System.IO.Stream requestStream, IMessage& responseMsg, ITransportHeaders& responseHeaders, System.IO.Stream& responseStream) [0x00000] Exception rethrown at [0]: at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke (System.Runtime.Remoting.Proxies.RealProxy rp, IMessage msg, System.Exception& exc, System.Object[]& out_args) [0x00000] ---- Additional Comments From robertj@gmx.net 2007-08-26 10:25:00 MST ---- It's the other dependent patch, that doesn't apply: https://bugzilla.novell.com/show_bug.cgi?id=MONO81554. ---- Additional Comments From jan.oravec@6com.sk 2007-08-26 10:30:52 MST ---- I was able to apply remotingservices-execute.diff as well. In fact, bug-78882-tcp.cs throws exception in native code without this patch. With both patches applied, bug-78882-tcp.cs throws same NullReferenceException from my previous post. ---- Additional Comments From jan.oravec@6com.sk 2007-08-26 10:40:24 MST ---- Hmm, the patch can be applied to 1.2.5p5, but couldn't be applied to SVN trunk -- trivial collision appeared in revision 84154: (bug-78882-tcp.cs) + if (method == null) + // actually an internal error + throw new RemotingException (String.Format ("Cannot resolve method {0}:{1}", tt, reqMsg.MethodName)); vs. (SVN trunk) + + if (method == null) + throw new NullReferenceException (); ---- Additional Comments From robertj@gmx.net 2007-08-26 10:45:02 MST ---- Yes, that's why I have to look at this again and provide a new patch. I'll do it ASAP (tonight). ---- Additional Comments From robertj@gmx.net 2007-09-08 19:34:54 MST ---- Fixed in SVN r85526 This bug depended on bug(s) 80383. This bug blocked bug(s) 81554. Imported an attachment (id=170124) Imported an attachment (id=170125) Imported an attachment (id=170126) Imported an attachment (id=170127) Unknown bug field "cf_op_sys_details" encountered while moving bug <cf_op_sys_details>Debian unstable</cf_op_sys_details> Unknown operating system unknown. Setting to default OS "Other".
It works fine on Linux, but on Win32 (both client and server) the client application hangs.
It works for me on Win32. Are you sure you're on SVN HEAD on Win32?
Yeah, and I'm using the repro which is located in gert/standalone/bug78882 in SVN. Not sure if that one is any different from the test case attached to this bug report.
Okay, I see the hang in gert/standalone/bug78882, but it's not related to this bug. If you insert a WriteLine after the remoting call, you'll see that it performs well. On Win32, the remoting calls used to hang since ages. Have a look at the unit test logs of the System.Runtime.Remoting assembly.
> On Win32, the remoting calls used to hang since ages. Have a look at the unit > test logs of the System.Runtime.Remoting assembly. Correction: not "remoting calls". I meant remoting at large. It is somehow preventing the process or appdomain from being terminated.
Closing
Good evening, Is this supposed to be fixed in 1.2.5.1 or 1.2.6? Mono on PPC still has this error on 1.2.5.1. Thank you
It's fixed in 1.2.6
Gert, FYI, the hang you've experienced is bug #324781.