search

33mestre / ice4j

Automatically exported from code.google.com/p/ice4j
0 stars 0 forks source link

Deadlock in PsuedoTCP #18

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
We are occasionally getting stuck in deadlocks when using PsuedoTCP.

We haven't been able to create a an easily reproducible example but we have 
logged the thread-dump from one occasion when it occurs. 

MessageReadThread@6558 daemon, prio=5, in group 'main', status: 'MONITOR'
     blocks PseudoTcpReceiveThread@6559
     blocks pool-40-thread-5@5853
     waiting for PseudoTcpReceiveThread@6559 to release lock on <0x1f78> (a org.ice4j.pseudotcp.PseudoTCPBase)
      at org.ice4j.pseudotcp.PseudoTCPBase.recv(PseudoTCPBase.java:591)
      at org.ice4j.pseudotcp.PseudoTcpSocketImpl$PseudoTcpInputStream.read(PseudoTcpSocketImpl.java:761)
      at sun.security.ssl.InputRecord.readFully(InputRecord.java:442)
      at sun.security.ssl.InputRecord.readV3Record(InputRecord.java:554)
      at sun.security.ssl.InputRecord.read(InputRecord.java:509)
      at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:927)
      at sun.security.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:884)
      at sun.security.ssl.AppInputStream.read(AppInputStream.java:102)
      at java.io.FilterInputStream.read(FilterInputStream.java:133)
      at com.google.protobuf.AbstractMessageLite$Builder$LimitedInputStream.read(AbstractMessageLite.java:263)
      at com.google.protobuf.CodedInputStream.readRawBytes(CodedInputStream.java:851)
      at com.google.protobuf.CodedInputStream.readBytes(CodedInputStream.java:329)
      at com.degoo.protocol.ClientProtos$NetworkMessage.<init>(ClientProtos.java:8927)
      at com.degoo.protocol.ClientProtos$NetworkMessage.<init>(ClientProtos.java:8866)
      at com.degoo.protocol.ClientProtos$NetworkMessage$1.parsePartialFrom(ClientProtos.java:8960)
      at com.degoo.protocol.ClientProtos$NetworkMessage$1.parsePartialFrom(ClientProtos.java:8955)
      at com.google.protobuf.AbstractParser.parsePartialFrom(AbstractParser.java:200)
      at com.google.protobuf.AbstractParser.parsePartialDelimitedFrom(AbstractParser.java:241)
      at com.google.protobuf.AbstractParser.parseDelimitedFrom(AbstractParser.java:253)
      at com.google.protobuf.AbstractParser.parseDelimitedFrom(AbstractParser.java:259)
      at com.google.protobuf.AbstractParser.parseDelimitedFrom(AbstractParser.java:49)
      at com.degoo.protocol.ClientProtos$NetworkMessage.parseDelimitedFrom(ClientProtos.java:9133)
      at com.degoo.backend.ice4j.NATConnection$MessageReadThread.run(NATConnection.java:365)

PseudoTcpReceiveThread@6559 daemon, prio=5, in group 'main', status: 'MONITOR'
     blocks PseudoTcpClockThread@6560
     blocks MessageReadThread@6558
     waiting for MessageReadThread@6558 to release lock on <0x1f84> (a java.lang.Object)
      at org.ice4j.pseudotcp.PseudoTcpSocketImpl.releaseAllLocks(PseudoTcpSocketImpl.java:493)
      at org.ice4j.pseudotcp.PseudoTcpSocketImpl.onTcpClosed(PseudoTcpSocketImpl.java:484)
      at org.ice4j.pseudotcp.PseudoTCPBase.closedown(PseudoTCPBase.java:1574)
      at org.ice4j.pseudotcp.PseudoTCPBase.process(PseudoTCPBase.java:927)
      at org.ice4j.pseudotcp.PseudoTCPBase.parse(PseudoTCPBase.java:852)
      at org.ice4j.pseudotcp.PseudoTCPBase.notifyPacket(PseudoTCPBase.java:486)
      at org.ice4j.pseudotcp.PseudoTcpSocketImpl.receivePackets(PseudoTcpSocketImpl.java:572)
      at org.ice4j.pseudotcp.PseudoTcpSocketImpl.access$000(PseudoTcpSocketImpl.java:18)
      at org.ice4j.pseudotcp.PseudoTcpSocketImpl$1.run(PseudoTcpSocketImpl.java:401)
      at java.lang.Thread.run(Thread.java:722)

We are using revision #r351 and are running it on Java 7 and Windows 7. I'm 
guessing that there's some place in the code where the synchronization doesn't 
occur in the correct order, thus causing a circular lock dependency that 
creates this deadlock.

Original issue reported on code.google.com by c...@degoo.com on 4 Sep 2013 at 10:00

GoogleCodeExporter commented 9 years ago 
I have now analyzed this a bit further. The deadlock looks like this:

One thread holds read_notify (in 
PseudoTcpSocketImpl$PseudoTcpInputStream.read(PseudoTcpSocketImpl.java:761)) 
and waits on PsuedoTCPBase (in PseudoTCPBase.recv(PseudoTCPBase.java:591))

The other thread holds PsuedoTCPBase (in 
PseudoTCPBase.notifyPacket(PseudoTCPBase.java:486)) and waits on read_notify in 
(PseudoTcpSocketImpl.releaseAllLocks(PseudoTcpSocketImpl.java:493))

Original comment by c...@degoo.com on 4 Sep 2013 at 10:11