[jcifs] Thread deadlock

[Jason Scherer]

Here is a full thread dump:

Full thread dump:

"JCIFS-WriterThread" daemon prio=5 tid=0x896ca50 nid=0x9d8 waiting on
monitor [0x924f000..0x924fdbc]
        at java.lang.Object.wait(Native Method)
        at java.lang.Object.wait(Unknown Source)
        at jcifs.smb.SmbFile$WriterThread.run(SmbFile.java:1531)

"JCIFS-SmbTransport" daemon prio=5 tid=0x78b020 nid=0x8fc runnable
[0x920f000..0x920fdbc]
        at java.net.SocketInputStream.socketRead(Native Method)
        at java.net.SocketInputStream.read(Unknown Source)
        at
        jcifs.netbios.SessionServicePacket.readPacketType(SessionServicePacket.java:68)
        at jcifs.netbios.SocketInputStream.read(SocketInputStream.java:73)
        at jcifs.netbios.SocketInputStream.read(SocketInputStream.java:39)
        at java.io.FilterInputStream.read(Unknown Source)
        at java.io.PushbackInputStream.read(Unknown Source)
        at jcifs.smb.SmbTransport.run(SmbTransport.java:304)
        at java.lang.Thread.run(Unknown Source)

"JCIFS-SmbTransport" daemon prio=5 tid=0x896cb78 nid=0x9e4 runnable
[0x91cf000..0x91cfdbc]
        at java.net.SocketInputStream.socketRead(Native Method)
        at java.net.SocketInputStream.read(Unknown Source)
        at
        jcifs.netbios.SessionServicePacket.readPacketType(SessionServicePacket.java:68)
        at jcifs.netbios.SocketInputStream.read(SocketInputStream.java:73)
        at jcifs.netbios.SocketInputStream.read(SocketInputStream.java:39)
        at java.io.FilterInputStream.read(Unknown Source)
        at java.io.PushbackInputStream.read(Unknown Source)
        at jcifs.smb.SmbTransport.run(SmbTransport.java:304)
        at java.lang.Thread.run(Unknown Source)

"Signal Dispatcher" daemon prio=10 tid=0x781e00 nid=0xa3c waiting on
monitor [0..0]

"Finalizer" daemon prio=9 tid=0x77de30 nid=0x9b8 waiting on monitor
[0x8bcf000..0x8bcfdbc]
        at java.lang.Object.wait(Native Method)
        at java.lang.ref.ReferenceQueue.remove(Unknown Source)
        at java.lang.ref.ReferenceQueue.remove(Unknown Source)
        at java.lang.ref.Finalizer$FinalizerThread.run(Unknown Source)

"Reference Handler" daemon prio=10 tid=0x77c990 nid=0x920 waiting on
monitor [0x8b8f000..0x8b8fdbc]
        at java.lang.Object.wait(Native Method)
        at java.lang.Object.wait(Unknown Source)
        at java.lang.ref.Reference$ReferenceHandler.run(Unknown Source)

"main" prio=5 tid=0x234a10 nid=0x3f4 waiting on monitor [0x6f000..0x6fc34]
        at java.lang.Object.wait(Native Method)
        at java.lang.Object.wait(Unknown Source)
        at jcifs.smb.SmbFile.copyTo0(SmbFile.java:1637)
        at jcifs.smb.SmbFile.copyTo(SmbFile.java:1708)
        at
        com.hp.ipg.lwcm.filecontrol.TransferFile.processFile(TransferFile.java:292)
        at
        com.hp.ipg.lwcm.ftp.FtpUserRecursive.recurse(FtpUserRecursive.java:395)
        at
        com.hp.ipg.lwcm.ftp.FtpUserRecursive.recurse(FtpUserRecursive.java:412)
        at
        com.hp.ipg.lwcm.ftp.FtpUserRecursive.recurse(FtpUserRecursive.java:412)
        at
        com.hp.ipg.lwcm.ftp.FtpUserRecursive.<init>(FtpUserRecursive.java:182)
        at PatternMatchExecute.<init>(PatternMatchExecute.java:20)
        at PatternMatchExecute.main(PatternMatchExecute.java:29)

"VM Thread" prio=5 tid=0x8910048 nid=0xa34 runnable

"VM Periodic Task Thread" prio=10 tid=0x780b00 nid=0x9d4 waiting on monitor
"Suspend Checker Thread" prio=10 tid=0x781450 nid=0x8e8 runnable


>
>
>> -----Original Message-----
>> From:	Jason Scherer [SMTP:jscherer at blackfintech.com]
>> Sent:	Monday, March 17, 2003 8:58 PM
>> To:	jcifs at lists.samba.org
>> Subject:	[jcifs] Thread deadlock
>>
>> I have written a program that recurses a directory structure and
>> copies the files to a network drive using the jcifs api.  The code
>> would "sometimes" stop when trying to copy the files.  I downloaded
>> and compiled the code to try and debug this problem, and what I have
>> found is that the SmbFile.copyTo0 method has a deadlock issue in the
>> w.wait() call below. synchronized( w ) {
>> while( !w.ready ) {
>> try {
>> w.wait();
>>
> 	How do you know it's a deadlock? Can you post a thread monitor dump
> 	please? On Unix you can do SIGQUIT by pressing Ctrl-\ on the
> 	commandline. On windwos this is Ctrl-Break.
>
> 	Also let it hang for 120 seconds. It may be a socket error that may
> 	take 1min 15 sec to timeout (doesn't sound like it though).
>
> 	Also it would be great if you could isolate some minimal code that
> 	reproduces the problem. I have several threaded examples used to test
> 	that code.
>
> 	Otherwise please explain how you think a deadlock could occur in that
> 	code. It's just not that complicated.
>
> 	Mike