[jcifs] Deadlock in Java code.

[Allen, Michael B (RSCH)]

Around 0.7.0b7 I think I lost/overwrote some code. I have "rediscovered" what I think was
the name service deadlock I thought I fixed in 0.7.0b7. I have fixed it again.

Matt,

I think I have also fixed the deadlock you found. Can you try this jar with your test for
that?

  http://users.erols.com/mballen/jcifs/jcifs-0.7.0b9dl.jar

What I have done is to simply have SmbTree.treeConnect lock the underlying session
*before* it locks itself. Because we know that a session trying to disconnect all trees will
first lock itself, both threads will try to lock the session object first thereby elimitating the
deadlock. The only concern is what will happen after that. It depends on who tries to lock
the session first. It will probably just hang waiting for the SYN timeout period
(~1min15sec) or cough up a No route to host. The later would be more appropriate for the
condition you're using to provoke the problem.

     94     void treeConnect( ServerMessageBlock andx,
     95                             ServerMessageBlock andxResponse ) throws SmbException {
     96         String unc;
     97 /*
     98  * We must lock the session and *then* this tree because there is a small
     99  * possibilty that the session could be trying to disconnect the tree at
    100  * the same time. In this case it will have the session locked and wait
    101  * indefinately trying to acquire the tree which would be locked trying to
    102  * aquire the session resulting in deadlock.
    103  */
    104 synchronized( session ) { 
    105     synchronized( this ) {

> -----Original Message-----
> From:	Allen, Michael B (RSCH) [SMTP:Michael_B_Allen at ml.com]
> Sent:	Wednesday, December 04, 2002 1:05 AM
> To:	'Matthew Tippett'; jcifs at lists.samba.org
> Subject:	RE: [jcifs] Deadlock in Java code.
> 
> What's happening is that while the JCIFS-SmbTransport thread is trying to
> disconnect, another thread is trying to setup a new session but logoff,
> treeDisconnect, treeConnect, and sessionSetup are all syncronized so you have:
> 
> Thread-9
>   |
>  locked:SmbTree x
>   |      |      |
>   x SmbSession:locked
>                 |
> JCIFS-SmbTransport Thread
> 
> Originally you establish a transport, then a session over that transport, and a
> tree on that session. Then your files can use send/sendTransaction on that tree.
> That's the arrangement. So in this deadlock the JCIFS-SmbTransport Thread from
> SmbTransport has called SmbSession.logoff (which is synchronized which
> means that session object is locked) and is trying to call
> SmbTree.treeDisconnect. But meanwhile the calling thread (Thread-9 in this
> case) has called SmbTree.treeConnect (which is syncronized which means that
> tree object is locked) and is trying to call SmbSession.sessionSetup. I'm surprised
> this is reproducable.
> 
> This is the Dining Philosophers problem where the tree and session are
> chopsticks :-<
> 
> > -----Original Message-----
> > From:	Matthew Tippett [SMTP:matthew at casero.com]
> > Sent:	Monday, December 02, 2002 11:01 AM
> > To:	jcifs at lists.samba.org
> > Subject:	[jcifs] Deadlock in Java code.
> > 
> > If a remote system goes down while a connection is active, the following
> > deadlock seems to occur.  Derived by <CTRL-\> under Linux.
> > 
> > Regards,
> > 
> > Matthew
> > 
> > Found one Java-level deadlock:
> > =============================
> > "JCIFS-SmbTransport":
> >    waiting to lock monitor 0x808749c (object 0x447c21a0, a 
> > jcifs.smb.SmbTree),
> >    which is held by "Thread-9"
> > "Thread-9":
> >    waiting to lock monitor 0x808814c (object 0x447ab990, a 
> > jcifs.smb.SmbSession),
> >    which is held by "JCIFS-SmbTransport"
> > 
> > Java stack information for the threads listed above:
> > ===================================================
> > "JCIFS-SmbTransport":
> > 	at jcifs.smb.SmbTree.treeDisconnect(SmbTree.java:130)
> > 	- waiting to lock <0x447c21a0> (a jcifs.smb.SmbTree)
> > 	at jcifs.smb.SmbSession.logoff(SmbSession.java:121)
> > 	- locked <0x447ab990> (a jcifs.smb.SmbSession)
> > 	at jcifs.smb.SmbTransport.tryClose(SmbTransport.java:280)
> > 	at jcifs.smb.SmbTransport.run(SmbTransport.java:403)
> > 	at java.lang.Thread.run(Thread.java:536)
> > "Thread-9":
> > 	at jcifs.smb.SmbSession.sessionSetup(SmbSession.java:94)
> > 	- waiting to lock <0x447ab990> (a jcifs.smb.SmbSession)
> > 	at jcifs.smb.SmbSession.send(SmbSession.java:85)
> > 	at jcifs.smb.SmbTree.treeConnect(SmbTree.java:123)
> > 	- locked <0x447c21a0> (a jcifs.smb.SmbTree)
> > 	at jcifs.smb.SmbFile.connect(SmbFile.java:496)
> > 	at jcifs.smb.SmbFile.connect0(SmbFile.java:466)
> > 	at jcifs.smb.SmbFile.queryPath(SmbFile.java:839)
> > 	at jcifs.smb.SmbFile.exists(SmbFile.java:914)
> > 	at
> > com.casero.eden.service.cifs.CIFSProvider.exists(CIFSProvider.java:262)
> > 	at 
> > com.casero.abode.file.ZoneManagerThread.pollOpzone(ZoneManagerThread.jav
> > a:145)
> > 	at
> > com.casero.abode.file.ZoneManagerThread.run(ZoneManagerThread.java:104)
> > 	at java.lang.Thread.run(Thread.java:536)
> > 
> > Found 1 deadlock.
> > 
> > 
> > -----
> > 
> > The information contained in this message is proprietary of Casero Inc.,
> > protected from disclosure, and may be privileged. The information is
> > intended to be conveyed only to the designated recipient(s) of the
> > message. If the reader of this message is not the intended recipient,
> > you are hereby notified that any dissemination, use, distribution or
> > copying of this communication is strictly prohibited and may be
> > unlawful. If you have received this communication in error, please
> > notify us immediately by replying to the message and deleting it from
> > your computer. Thank you.
> > 
>