Lide / jabber-net

Automatically exported from code.google.com/p/jabber-net
Other
0 stars 0 forks source link

.Net Client Library not thread safe #77

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
1.  Start the Receiver.
2.  Start the sender with 1 thread and 100 loops
    a)  Result : there is no exception 
3.  Start the sender with 10 threads and 100 loops
    a)  Result : the Exception is thrown occasionally
System.IndexOutOfRangeException: Probable I/O race condition detected while
copying memory. The I/O package is not thread safe by default. In
multithreaded applications, a stream must be accessed in a thread-safe way,
such as a thread-safe wrapper returned by TextReader's or TextWriter's
Synchronized methods. This also applies to classes like StreamWriter and
StreamReader.
   at System.Buffer.InternalBlockCopy(Array src, Int32 srcOffset, Array
dst, Int32 dstOffset, Int32 count)
   at System.IO.MemoryStream.ToArray()
   at bedrock.net.AsyncSocket.WroteData(IAsyncResult ar)
   at System.Net.LazyAsyncResult.Complete(IntPtr userToken)
   at System.Threading.ExecutionContext.Run(ExecutionContext
executionContext, ContextCallback callback, Object state)
   at System.Net.ContextAwareResult.Complete(IntPtr userToken)
   at System.Net.LazyAsyncResult.ProtectedInvokeCallback(Object result,
IntPtr userToken)
   at
System.Net.Sockets.BaseOverlappedAsyncResult.CompletionPortCallback(UInt32
errorCode, UInt32 numBytes, NativeOverlapped* nativeOverlapped)
   at
System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32
errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP)

4.  Start the sender with 50 threads and 100 loops
   a)   Result : The exception is thrown frequently

System.IndexOutOfRangeException: Probable I/O race condition detected while
copying memory. The I/O package is not thread safe by default. In
multithreaded applications, a stream must be accessed in a thread-safe way,
such as a thread-safe wrapper returned by TextReader's or TextWriter's
Synchronized methods. This also applies to classes like StreamWriter and
StreamReader.
   at System.Buffer.InternalBlockCopy(Array src, Int32 srcOffset, Array
dst, Int32 dstOffset, Int32 count)
   at System.IO.MemoryStream.ToArray()
   at bedrock.net.AsyncSocket.WroteData(IAsyncResult ar)
   at System.Net.LazyAsyncResult.Complete(IntPtr userToken)
   at System.Threading.ExecutionContext.Run(ExecutionContext
executionContext, ContextCallback callback, Object state)
   at System.Net.ContextAwareResult.Complete(IntPtr userToken)
   at System.Net.LazyAsyncResult.ProtectedInvokeCallback(Object result,
IntPtr userToken)
   at
System.Net.Sockets.BaseOverlappedAsyncResult.CompletionPortCallback(UInt32
errorCode, UInt32 numBytes, NativeOverlapped* nativeOverlapped)
   at
System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32
errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP)

Original issue reported on code.google.com by victor.t...@gmail.com on 23 Jun 2009 at 4:32

Attachments:

GoogleCodeExporter commented 9 years ago
Did you get any answer to this? I am also facing the same issue.
Why does this happen? .NET should take care of releasing the memory internally 
if we 
are closing the stream object. Isn't it?

Original comment by Nyoti.Ru...@gmail.com on 22 Jul 2009 at 11:04

GoogleCodeExporter commented 9 years ago
I am also having this problem.

Original comment by PlanetSa...@gmail.com on 5 Aug 2009 at 8:14

GoogleCodeExporter commented 9 years ago
I have found several issues with the code in the WroteData function in 
AsynSocket.cs. 

1) There is a section of code outside of the try/catch block. This code will 
cause an unhanded exception. If/when an error occurs there.

2) The MemoryStream m_pending can be accessed in a "non-thread safe" way. This 
can cause the m_pending.ToArray() call to throw an IO exception. This will also 
trigger the above issue as well.

3) Uusing the test code provided in this thread, it is possible for the 
underlying socket to close before all the threads have finished there callback 
to WroteData(). Thus, causing a socket exception that is an inner exception for 
an IO exception to be thrown when calling the m_stream.EndWrite() function. 
This can be adjusted by looking for this wrapped exception and handling it 
well. I think this third issue is what the original poster of this thread was 
experiencing. 

I have uploaded my changes to the WroteData() function here. Hope it helps. 

Original comment by Hodge.Ga...@gmail.com on 11 Apr 2013 at 4:07

Attachments: