Re: [Mono-dev] Mono 3 insert quotation marks instead of special chars in SQL Server
While mailing-list system was offline I've done some further investigation. The problem is during creation of RPC Call. It use tdsParameter.GetBytes method that make an Encoding.Default.GetBytes. As the default Encoding is US ASCII avery special char is converted into a quotation mark. I've tried to change Default to UTF8 and Unicode, just to see what happens and it gives another error about wrong message format so it's not the correct way. The old Mono 2 works because it use Tds70 instead Tds80 and Tds70 works in a different way, without using RPC. I'm trying to workaround the problem downgrading to Tds70 and it seems to work, but there's a chance to have it working also with Tds80? At 10:33 08/01/2014, APS wrote: Hi, I'm using mono 3 for an asp.net web application and inserting or updating data in an SQL Server database, if I enter special characters like 'à' they are inserted as '?' inside the database. Is probably a conversion issue with UTF8 but how can I handle it? I tried with an old mono 2 and the characters has been inserted correctly. Any hint? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da MailScanner, ed e' risultato non infetto. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] (no subject)
What version of mono, and what architecture are you running this on? On 07/01/14 16:20, Greg Young wrote: Interesting issue came up today. All code works fine when run with mono regularly. However when we statically link mono and put the system under pressure we end up getting a SIGABRT on a fairly innocuous call (not right away). We cannot reproduce this with mono not statically linked. Anyone have any ideas where to start looking? at unknown 0x at (wrapper managed-to-native) object.__icall_wrapper_mono_array_new_specific (intptr,int) 0x at System.IO.MemoryStream.set_Capacity (int) 0x00077 at System.IO.MemoryStream.Expand (int) 0x00036 at System.IO.MemoryStream.Write (byte[],int,int) 0x00093 at ProtoBuf.ProtoWriter.Flush (ProtoBuf.ProtoWriter) 0x00034 at ProtoBuf.ProtoWriter.Dispose () 0x0001b at ProtoBuf.ProtoWriter.Close () 0x00023 at ProtoBuf.Meta.TypeModel.Serialize (System.IO.Stream,object,ProtoBuf.SerializationContext) 0x00087 at ProtoBuf.Meta.TypeModel.Serialize (System.IO.Stream,object) 0x0001b at ProtoBuf.Serializer.SerializeT (System.IO.Stream,T) 0x00037 at EventStore.Core.Services.Transport.Tcp.ProtobufExtensions.SerializeT (T) 0x00073 at EventStore.Core.Services.Transport.Tcp.InternalTcpDispatcher.WrapDataChunkBulk (EventStore.Core.Messages.ReplicationMessage/DataChunkBulk) 0x00153 at (wrapper delegate-invoke) System.Func`2EventStore.Core.Messages.ReplicationMessage/DataChunkBulk, EventStore.Core.Services.Transport.Tcp.TcpPackage.invoke_TResult__this___T (EventStore.Core.Message s.ReplicationMessage/DataChunkBulk) 0x at EventStore.Core.Services.Transport.Tcp.TcpDispatcher/AddWrapperc__AnonStorey4D`1.m__10A (EventStore.Core.Messaging.Message) 0x00057 at (wrapper delegate-invoke) System.Func`2EventStore.Core.Messaging.Message, EventStore.Core.Services.Transport.Tcp.TcpPackage.invoke_TResult__this___T (EventStore.Core.Messaging.Message) 0x at EventStore.Core.Services.Transport.Tcp.TcpDispatcher.WrapMessage (EventStore.Core.Messaging.Message) 0x000d6 at EventStore.Core.Services.Transport.Tcp.TcpConnectionManager.SendMessage (EventStore.Core.Messaging.Message) 0x0004c at EventStore.Core.Services.TcpSendService.Handle (EventStore.Core.Messages.TcpMessage/TcpSend) 0x0001f at EventStore.Core.Bus.MessageHandler`1.TryHandle (EventStore.Core.Messaging.Message) 0x00094 at EventStore.Core.Bus.InMemoryBus.Publish (EventStore.Core.Messaging.Message) 0x000fe at EventStore.Core.Bus.InMemoryBus.Handle (EventStore.Core.Messaging.Message) 0x00013 at EventStore.Core.Bus.QueuedHandlerThreadPool.ReadFromQueue (object) 0x00137 at (wrapper runtime-invoke) Module.runtime_invoke_void__this___object (object,intptr,intptr,intptr) 0x Native stacktrace: ./clusternode() [0x6215be] /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0) [0x7f289d4f2cb0] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35) [0x7f289d159425] /lib/x86_64-linux-gnu/libc.so.6(abort+0x17b) [0x7f289d15cb8b] ./clusternode() [0x5803dd] ./clusternode() [0x580472] ./clusternode() [0x524a24] ./clusternode() [0x528c0e] ./clusternode() [0x52cf61] ./clusternode() [0x52e541] ./clusternode() [0x51283f] ./clusternode() [0x5186b3] ./clusternode() [0x518c6b] ./clusternode() [0x50b487] ./clusternode() [0x50b6d8] ./clusternode(mono_array_new_specific+0x36) [0x4e4256] [0x41e25187] Debug info from gdb: = 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. = Aborted -- Le doute n'est pas une condition agréable, mais la certitude est absurde. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] (no subject)
This 64bits-only bug could be the culprit: https://bugzilla.xamarin.com/show_bug.cgi?id=14834 It's fixed already in master branch. Try master. On 10/01/14 11:34, Andrés G. Aragoneses wrote: What version of mono, and what architecture are you running this on? On 07/01/14 16:20, Greg Young wrote: Interesting issue came up today. All code works fine when run with mono regularly. However when we statically link mono and put the system under pressure we end up getting a SIGABRT on a fairly innocuous call (not right away). We cannot reproduce this with mono not statically linked. Anyone have any ideas where to start looking? at unknown 0x at (wrapper managed-to-native) object.__icall_wrapper_mono_array_new_specific (intptr,int) 0x at System.IO.MemoryStream.set_Capacity (int) 0x00077 at System.IO.MemoryStream.Expand (int) 0x00036 at System.IO.MemoryStream.Write (byte[],int,int) 0x00093 at ProtoBuf.ProtoWriter.Flush (ProtoBuf.ProtoWriter) 0x00034 at ProtoBuf.ProtoWriter.Dispose () 0x0001b at ProtoBuf.ProtoWriter.Close () 0x00023 at ProtoBuf.Meta.TypeModel.Serialize (System.IO.Stream,object,ProtoBuf.SerializationContext) 0x00087 at ProtoBuf.Meta.TypeModel.Serialize (System.IO.Stream,object) 0x0001b at ProtoBuf.Serializer.SerializeT (System.IO.Stream,T) 0x00037 at EventStore.Core.Services.Transport.Tcp.ProtobufExtensions.SerializeT (T) 0x00073 at EventStore.Core.Services.Transport.Tcp.InternalTcpDispatcher.WrapDataChunkBulk (EventStore.Core.Messages.ReplicationMessage/DataChunkBulk) 0x00153 at (wrapper delegate-invoke) System.Func`2EventStore.Core.Messages.ReplicationMessage/DataChunkBulk, EventStore.Core.Services.Transport.Tcp.TcpPackage.invoke_TResult__this___T (EventStore.Core.Message s.ReplicationMessage/DataChunkBulk) 0x at EventStore.Core.Services.Transport.Tcp.TcpDispatcher/AddWrapperc__AnonStorey4D`1.m__10A (EventStore.Core.Messaging.Message) 0x00057 at (wrapper delegate-invoke) System.Func`2EventStore.Core.Messaging.Message, EventStore.Core.Services.Transport.Tcp.TcpPackage.invoke_TResult__this___T (EventStore.Core.Messaging.Message) 0x at EventStore.Core.Services.Transport.Tcp.TcpDispatcher.WrapMessage (EventStore.Core.Messaging.Message) 0x000d6 at EventStore.Core.Services.Transport.Tcp.TcpConnectionManager.SendMessage (EventStore.Core.Messaging.Message) 0x0004c at EventStore.Core.Services.TcpSendService.Handle (EventStore.Core.Messages.TcpMessage/TcpSend) 0x0001f at EventStore.Core.Bus.MessageHandler`1.TryHandle (EventStore.Core.Messaging.Message) 0x00094 at EventStore.Core.Bus.InMemoryBus.Publish (EventStore.Core.Messaging.Message) 0x000fe at EventStore.Core.Bus.InMemoryBus.Handle (EventStore.Core.Messaging.Message) 0x00013 at EventStore.Core.Bus.QueuedHandlerThreadPool.ReadFromQueue (object) 0x00137 at (wrapper runtime-invoke) Module.runtime_invoke_void__this___object (object,intptr,intptr,intptr) 0x Native stacktrace: ./clusternode() [0x6215be] /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0) [0x7f289d4f2cb0] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35) [0x7f289d159425] /lib/x86_64-linux-gnu/libc.so.6(abort+0x17b) [0x7f289d15cb8b] ./clusternode() [0x5803dd] ./clusternode() [0x580472] ./clusternode() [0x524a24] ./clusternode() [0x528c0e] ./clusternode() [0x52cf61] ./clusternode() [0x52e541] ./clusternode() [0x51283f] ./clusternode() [0x5186b3] ./clusternode() [0x518c6b] ./clusternode() [0x50b487] ./clusternode() [0x50b6d8] ./clusternode(mono_array_new_specific+0x36) [0x4e4256] [0x41e25187] Debug info from gdb: = 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. = Aborted -- Le doute n'est pas une condition agréable, mais la certitude est absurde. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] (no subject)
Thanks, I'll try this today. Cheers, James On 10 Jan 2014, at 10:42, Andrés G. Aragoneses kno...@gmail.com wrote: This 64bits-only bug could be the culprit: https://bugzilla.xamarin.com/show_bug.cgi?id=14834 It's fixed already in master branch. Try master. On 10/01/14 11:34, Andrés G. Aragoneses wrote: What version of mono, and what architecture are you running this on? On 07/01/14 16:20, Greg Young wrote: Interesting issue came up today. All code works fine when run with mono regularly. However when we statically link mono and put the system under pressure we end up getting a SIGABRT on a fairly innocuous call (not right away). We cannot reproduce this with mono not statically linked. Anyone have any ideas where to start looking? at unknown 0x at (wrapper managed-to-native) object.__icall_wrapper_mono_array_new_specific (intptr,int) 0x at System.IO.MemoryStream.set_Capacity (int) 0x00077 at System.IO.MemoryStream.Expand (int) 0x00036 at System.IO.MemoryStream.Write (byte[],int,int) 0x00093 at ProtoBuf.ProtoWriter.Flush (ProtoBuf.ProtoWriter) 0x00034 at ProtoBuf.ProtoWriter.Dispose () 0x0001b at ProtoBuf.ProtoWriter.Close () 0x00023 at ProtoBuf.Meta.TypeModel.Serialize (System.IO.Stream,object,ProtoBuf.SerializationContext) 0x00087 at ProtoBuf.Meta.TypeModel.Serialize (System.IO.Stream,object) 0x0001b at ProtoBuf.Serializer.SerializeT (System.IO.Stream,T) 0x00037 at EventStore.Core.Services.Transport.Tcp.ProtobufExtensions.SerializeT (T) 0x00073 at EventStore.Core.Services.Transport.Tcp.InternalTcpDispatcher.WrapDataChunkBulk (EventStore.Core.Messages.ReplicationMessage/DataChunkBulk) 0x00153 at (wrapper delegate-invoke) System.Func`2EventStore.Core.Messages.ReplicationMessage/DataChunkBulk, EventStore.Core.Services.Transport.Tcp.TcpPackage.invoke_TResult__this___T (EventStore.Core.Message s.ReplicationMessage/DataChunkBulk) 0x at EventStore.Core.Services.Transport.Tcp.TcpDispatcher/AddWrapperc__AnonStorey4D`1.m__10A (EventStore.Core.Messaging.Message) 0x00057 at (wrapper delegate-invoke) System.Func`2EventStore.Core.Messaging.Message, EventStore.Core.Services.Transport.Tcp.TcpPackage.invoke_TResult__this___T (EventStore.Core.Messaging.Message) 0x at EventStore.Core.Services.Transport.Tcp.TcpDispatcher.WrapMessage (EventStore.Core.Messaging.Message) 0x000d6 at EventStore.Core.Services.Transport.Tcp.TcpConnectionManager.SendMessage (EventStore.Core.Messaging.Message) 0x0004c at EventStore.Core.Services.TcpSendService.Handle (EventStore.Core.Messages.TcpMessage/TcpSend) 0x0001f at EventStore.Core.Bus.MessageHandler`1.TryHandle (EventStore.Core.Messaging.Message) 0x00094 at EventStore.Core.Bus.InMemoryBus.Publish (EventStore.Core.Messaging.Message) 0x000fe at EventStore.Core.Bus.InMemoryBus.Handle (EventStore.Core.Messaging.Message) 0x00013 at EventStore.Core.Bus.QueuedHandlerThreadPool.ReadFromQueue (object) 0x00137 at (wrapper runtime-invoke) Module.runtime_invoke_void__this___object (object,intptr,intptr,intptr) 0x Native stacktrace: ./clusternode() [0x6215be] /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0) [0x7f289d4f2cb0] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35) [0x7f289d159425] /lib/x86_64-linux-gnu/libc.so.6(abort+0x17b) [0x7f289d15cb8b] ./clusternode() [0x5803dd] ./clusternode() [0x580472] ./clusternode() [0x524a24] ./clusternode() [0x528c0e] ./clusternode() [0x52cf61] ./clusternode() [0x52e541] ./clusternode() [0x51283f] ./clusternode() [0x5186b3] ./clusternode() [0x518c6b] ./clusternode() [0x50b487] ./clusternode() [0x50b6d8] ./clusternode(mono_array_new_specific+0x36) [0x4e4256] [0x41e25187] Debug info from gdb: = 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. = Aborted -- Le doute n'est pas une condition agréable, mais la certitude est absurde. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] (no subject)
It's mono 3.2.4, running on an x64 Intel NUC - the errors occur on the same machine as it was compiled on. (I'm working on the same project) Cheers, James On 10 Jan 2014, at 10:34, Andrés G. Aragoneses kno...@gmail.com wrote: What version of mono, and what architecture are you running this on? On 07/01/14 16:20, Greg Young wrote: Interesting issue came up today. All code works fine when run with mono regularly. However when we statically link mono and put the system under pressure we end up getting a SIGABRT on a fairly innocuous call (not right away). We cannot reproduce this with mono not statically linked. Anyone have any ideas where to start looking? at unknown 0x at (wrapper managed-to-native) object.__icall_wrapper_mono_array_new_specific (intptr,int) 0x at System.IO.MemoryStream.set_Capacity (int) 0x00077 at System.IO.MemoryStream.Expand (int) 0x00036 at System.IO.MemoryStream.Write (byte[],int,int) 0x00093 at ProtoBuf.ProtoWriter.Flush (ProtoBuf.ProtoWriter) 0x00034 at ProtoBuf.ProtoWriter.Dispose () 0x0001b at ProtoBuf.ProtoWriter.Close () 0x00023 at ProtoBuf.Meta.TypeModel.Serialize (System.IO.Stream,object,ProtoBuf.SerializationContext) 0x00087 at ProtoBuf.Meta.TypeModel.Serialize (System.IO.Stream,object) 0x0001b at ProtoBuf.Serializer.SerializeT (System.IO.Stream,T) 0x00037 at EventStore.Core.Services.Transport.Tcp.ProtobufExtensions.SerializeT (T) 0x00073 at EventStore.Core.Services.Transport.Tcp.InternalTcpDispatcher.WrapDataChunkBulk (EventStore.Core.Messages.ReplicationMessage/DataChunkBulk) 0x00153 at (wrapper delegate-invoke) System.Func`2EventStore.Core.Messages.ReplicationMessage/DataChunkBulk, EventStore.Core.Services.Transport.Tcp.TcpPackage.invoke_TResult__this___T (EventStore.Core.Message s.ReplicationMessage/DataChunkBulk) 0x at EventStore.Core.Services.Transport.Tcp.TcpDispatcher/AddWrapperc__AnonStorey4D`1.m__10A (EventStore.Core.Messaging.Message) 0x00057 at (wrapper delegate-invoke) System.Func`2EventStore.Core.Messaging.Message, EventStore.Core.Services.Transport.Tcp.TcpPackage.invoke_TResult__this___T (EventStore.Core.Messaging.Message) 0x at EventStore.Core.Services.Transport.Tcp.TcpDispatcher.WrapMessage (EventStore.Core.Messaging.Message) 0x000d6 at EventStore.Core.Services.Transport.Tcp.TcpConnectionManager.SendMessage (EventStore.Core.Messaging.Message) 0x0004c at EventStore.Core.Services.TcpSendService.Handle (EventStore.Core.Messages.TcpMessage/TcpSend) 0x0001f at EventStore.Core.Bus.MessageHandler`1.TryHandle (EventStore.Core.Messaging.Message) 0x00094 at EventStore.Core.Bus.InMemoryBus.Publish (EventStore.Core.Messaging.Message) 0x000fe at EventStore.Core.Bus.InMemoryBus.Handle (EventStore.Core.Messaging.Message) 0x00013 at EventStore.Core.Bus.QueuedHandlerThreadPool.ReadFromQueue (object) 0x00137 at (wrapper runtime-invoke) Module.runtime_invoke_void__this___object (object,intptr,intptr,intptr) 0x Native stacktrace: ./clusternode() [0x6215be] /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0) [0x7f289d4f2cb0] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35) [0x7f289d159425] /lib/x86_64-linux-gnu/libc.so.6(abort+0x17b) [0x7f289d15cb8b] ./clusternode() [0x5803dd] ./clusternode() [0x580472] ./clusternode() [0x524a24] ./clusternode() [0x528c0e] ./clusternode() [0x52cf61] ./clusternode() [0x52e541] ./clusternode() [0x51283f] ./clusternode() [0x5186b3] ./clusternode() [0x518c6b] ./clusternode() [0x50b487] ./clusternode() [0x50b6d8] ./clusternode(mono_array_new_specific+0x36) [0x4e4256] [0x41e25187] Debug info from gdb: = 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. = Aborted -- Le doute n'est pas une condition agréable, mais la certitude est absurde. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] (no subject)
If it still crashes with master, run it with gdb and obtain a backtrace, and attach it to a bug report. On 10/01/14 11:43, James Nugent wrote: Thanks, I'll try this today. Cheers, James On 10 Jan 2014, at 10:42, Andrés G. Aragoneses kno...@gmail.com wrote: This 64bits-only bug could be the culprit: https://bugzilla.xamarin.com/show_bug.cgi?id=14834 It's fixed already in master branch. Try master. On 10/01/14 11:34, Andrés G. Aragoneses wrote: What version of mono, and what architecture are you running this on? On 07/01/14 16:20, Greg Young wrote: Interesting issue came up today. All code works fine when run with mono regularly. However when we statically link mono and put the system under pressure we end up getting a SIGABRT on a fairly innocuous call (not right away). We cannot reproduce this with mono not statically linked. Anyone have any ideas where to start looking? at unknown 0x at (wrapper managed-to-native) object.__icall_wrapper_mono_array_new_specific (intptr,int) 0x at System.IO.MemoryStream.set_Capacity (int) 0x00077 at System.IO.MemoryStream.Expand (int) 0x00036 at System.IO.MemoryStream.Write (byte[],int,int) 0x00093 at ProtoBuf.ProtoWriter.Flush (ProtoBuf.ProtoWriter) 0x00034 at ProtoBuf.ProtoWriter.Dispose () 0x0001b at ProtoBuf.ProtoWriter.Close () 0x00023 at ProtoBuf.Meta.TypeModel.Serialize (System.IO.Stream,object,ProtoBuf.SerializationContext) 0x00087 at ProtoBuf.Meta.TypeModel.Serialize (System.IO.Stream,object) 0x0001b at ProtoBuf.Serializer.SerializeT (System.IO.Stream,T) 0x00037 at EventStore.Core.Services.Transport.Tcp.ProtobufExtensions.SerializeT (T) 0x00073 at EventStore.Core.Services.Transport.Tcp.InternalTcpDispatcher.WrapDataChunkBulk (EventStore.Core.Messages.ReplicationMessage/DataChunkBulk) 0x00153 at (wrapper delegate-invoke) System.Func`2EventStore.Core.Messages.ReplicationMessage/DataChunkBulk, EventStore.Core.Services.Transport.Tcp.TcpPackage.invoke_TResult__this___T (EventStore.Core.Message s.ReplicationMessage/DataChunkBulk) 0x at EventStore.Core.Services.Transport.Tcp.TcpDispatcher/AddWrapperc__AnonStorey4D`1.m__10A (EventStore.Core.Messaging.Message) 0x00057 at (wrapper delegate-invoke) System.Func`2EventStore.Core.Messaging.Message, EventStore.Core.Services.Transport.Tcp.TcpPackage.invoke_TResult__this___T (EventStore.Core.Messaging.Message) 0x at EventStore.Core.Services.Transport.Tcp.TcpDispatcher.WrapMessage (EventStore.Core.Messaging.Message) 0x000d6 at EventStore.Core.Services.Transport.Tcp.TcpConnectionManager.SendMessage (EventStore.Core.Messaging.Message) 0x0004c at EventStore.Core.Services.TcpSendService.Handle (EventStore.Core.Messages.TcpMessage/TcpSend) 0x0001f at EventStore.Core.Bus.MessageHandler`1.TryHandle (EventStore.Core.Messaging.Message) 0x00094 at EventStore.Core.Bus.InMemoryBus.Publish (EventStore.Core.Messaging.Message) 0x000fe at EventStore.Core.Bus.InMemoryBus.Handle (EventStore.Core.Messaging.Message) 0x00013 at EventStore.Core.Bus.QueuedHandlerThreadPool.ReadFromQueue (object) 0x00137 at (wrapper runtime-invoke) Module.runtime_invoke_void__this___object (object,intptr,intptr,intptr) 0x Native stacktrace: ./clusternode() [0x6215be] /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0) [0x7f289d4f2cb0] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35) [0x7f289d159425] /lib/x86_64-linux-gnu/libc.so.6(abort+0x17b) [0x7f289d15cb8b] ./clusternode() [0x5803dd] ./clusternode() [0x580472] ./clusternode() [0x524a24] ./clusternode() [0x528c0e] ./clusternode() [0x52cf61] ./clusternode() [0x52e541] ./clusternode() [0x51283f] ./clusternode() [0x5186b3] ./clusternode() [0x518c6b] ./clusternode() [0x50b487] ./clusternode() [0x50b6d8] ./clusternode(mono_array_new_specific+0x36) [0x4e4256] [0x41e25187] Debug info from gdb: = 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. = Aborted -- Le doute n'est pas une condition agréable, mais la certitude est absurde. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] DllImport(__Internal) and libMonoPosixHelper static build
Robert Jordan wrote Your custom loader is supposed to support dlopen(NULL) and your linker must be able to export public symbols. See ld's --export-dynamic option. Thanks Robert In my case loader is not custom and supports dlopen(NULL) and I'm using mkbundle. -- View this message in context: http://mono.1490590.n4.nabble.com/DllImport-Internal-and-libMonoPosixHelper-static-build-tp4551182p4661661.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] WIF support for Mono
Hi all, Thank you for the mono support. There is a need for me use WIF for authentication in my project I am doing. I understand currently it's not supported. Is there any plan for it's support in near future? Anytime you are planning to bring it out? Cheers, Vijay ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Access Windows share as my C# application runs on Linux under mono
I am writing an application to transfer files over the network. I hit a roadblock when my application runs on Linux (under mono and normal user) I try to access a file on the network (present on a windows file share) I keep getting a FileNotFoundException coz the shared path \\hostname\dir\file get pre pended with the path from where the application is running. I tried using an alternative, libsmbclient functions which basically appends smb://hostname/dir/file. This works perfect when the remote machine is linux, but craps out when the remote machine is windows. Could someone please suggest an approach, where I could programatically copy a file on Windows share from a Linux box. Thanks in advance! -- View this message in context: http://mono.1490590.n4.nabble.com/Access-Windows-share-as-my-C-application-runs-on-Linux-under-mono-tp4661665.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
