[Mono-bugs] [Bug 675362] New: System.Net.WebConnectionStream.Read blocks indefinitely occasionally, possible race condition

[bugzilla_noreply at novell.com]

https://bugzilla.novell.com/show_bug.cgi?id=675362

https://bugzilla.novell.com/show_bug.cgi?id=675362#c0


           Summary: System.Net.WebConnectionStream.Read blocks
                    indefinitely occasionally, possible race condition
    Classification: Mono
           Product: Mono: Class Libraries
           Version: 2.10.x
          Platform: i686
        OS/Version: Linux
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: System
        AssignedTo: mono-bugs at lists.ximian.com
        ReportedBy: me at chrishowie.com
         QAContact: mono-bugs at lists.ximian.com
          Found By: ---
           Blocker: ---


User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13)
Gecko/20101203 Firefox/3.6.13

I have written an AMF/AMF3 parser/writer in C# that will deserialize byte
streams into objects and vice-versa.  This library works fine in conjunction
with a WebConnectionStream on Windows/.NET, but not Linux/Mono.  The Read()
call seems to block occasionally, but when it does it blocks forever with no
timeout.  Here is the stack trace (kill -QUIT ...):

"<unnamed thread>" tid=0x0xb7581950 this=0x0x53f20 thread handle 0x403 state :
waiting on 0x9bf : Event  owns ()
  at (wrapper managed-to-native) System.Threading.WaitHandle.WaitOne_internal
(System.Threading.WaitHandle,intptr,int,bool) <0xffffffff>
  at System.Threading.WaitHandle.WaitOne (int,bool) <0x0007d>
  at System.Net.WebAsyncResult.WaitUntilComplete (int,bool) <0x00041>
  at System.Net.WebConnectionStream.Read (byte[],int,int) <0x00075>
  at System.IO.Stream.ReadByte () <0x00032>
  at Amf.Amf3Parser.ReadInteger () <0x00023>
  at Amf.Amf3Parser.ReadString () <0x00015>
  at Amf.Amf3Parser.ReadAmf3Object () <0x0032f>
  at Amf.Amf3Parser.ReadNextObject () <0x000d1>
  at Amf.Amf3Parser.ReadAmf3Object () <0x00305>
  at Amf.Amf3Parser.ReadNextObject () <0x000d1>
  at Amf.Amf3Parser.ReadAmf3Object () <0x00305>
  at Amf.Amf3Parser.ReadNextObject () <0x000d1>
  at Amf.Amf3Parser.ReadAmf3Object () <0x00305>
  at Amf.Amf3Parser.ReadNextObject () <0x000d1>
  at Amf.Amf3Parser.ReadArray () <0x0011d>
  at Amf.Amf3Parser.ReadNextObject () <0x000bd>
  at Amf.Amf3Parser.ReadAmf3Object () <0x00305>
  at Amf.Amf3Parser.ReadNextObject () <0x000d1>
  at Amf.AmfParser.ReadNextObject () <0x00155>
  at Amf.AmfBody.Read (Amf.AmfParser) <0x00083>
  at Amf.AmfRequest/<ReadBodies>c__Iterator2.MoveNext () <0x00041>
  at System.Collections.Generic.List`1.AddEnumerable
(System.Collections.Generic.IEnumerable`1<T>) <0x0008f>
  at System.Collections.Generic.List`1.AddRange
(System.Collections.Generic.IEnumerable`1<T>) <0x0005b>
  at Amf.AmfRequest.Read (Amf.AmfParser) <0x0019b>
.. (snipped, the rest is proprietary)

At first I thought that the TCP connection itself was just experiencing a lost
packet or severe latency, but netstat reveals that this is not the case:

chris at zack:~$ netstat -tnp
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
PID/Program name
..
tcp    32252      0 192.168.3.12:56892      xx.xx.xx.xx:80          CLOSE_WAIT 
920/mono

The AMF reader performs a lot of very small reads on the stream, and I am
wondering if perhaps there is a race condition or other timing bug that is
causing the chances of a deadlock to go up dramatically with so many reads.

If there is any more information I can provide let me know and I will do my
best to supply it.

Reproducible: Sometimes

-- 
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.