You can't always trust the line numbers in Java source code. Are you
sure it isn't just stalled in a socket write?

<snip down to question>

Probably not--a key advantage of the synchronize operation is the assurance
of pairing lock with unlock.  Unfortunately, that's not enough to prevent
deadlock.

PrintWriter has an internal lock that it synchronizes on before writing to
the inner Writer, so it really only blocks when the underlying writer
blocks.  I would say first that you have another threading writing to the
PrintWriter which owns the outer lock but which is blocked on the writer.
What would make that inner writer block? Is it a socket?  A file on a
networked file system or otherwise exotic communications or messaging
system?

It seems unlikely, but if your code that calls the PrintWriter is within
another synchronized block that is based on this inner writer and the other
thread is writing to the Print Writer and has the PW lock (but is waiting on
the inner writer) you will have deadlock.  This seems highly contrived,
however.  It all depends on what that inner writer is and how you're using
it.

Writer innerWriter is a some kind of unusual writer that internally
synchronizes on itself...

PrintWriter pw = new PrintWriter (innerWriter);

In thread 1
   synchronized (innerWriter) {
      ....
      pw.println ("Foo");
   }

In thread 2
   pw.println ("Bar");

Cheers,
Matt Humphrey   matth@ivizNOSPAM.com   http://www.iviz.com/ 

I can't see anything in the above information to indicate which /pair/ of
threads are deadlocked (and it always will be a pair -- at least -- unless you
are playing bad games with JNI or bytecode modification).  Unless you have that
information, your only hope of diagnosing the deadlock is by wracking your
brains over the source code.

You should be able to find out more using the new management concole, JConsole.
See
   http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html
and scroll down to the bit about deadlock detection.

Also you are supposed to be able to press <Ctrl>\ to ask the running JVM to
print out a dump of the currently deadlocked threads.  I have never made this
work myself, for some reason, so I don't know whether it kills the JVM as a
side effect, so don't try it on a live server until you know for sure ;-)

It would also be possible for some other thread to have taken out a lock on the
PrintWriter's lock object, but then stalled (but not deadlocked) for some
reason.  That would look similar, but the tools wouldn't detect it directly.
For instance the other thread might be using a mis-written wait()/notify[All]()
sleep (using a different object as the focus of that pattern).  But whether
real deadlock is involved or not, you have to find out which other threads are
holding the lock object at the time when your first thread stops.

   -- chris

No web interface onto CVS/SVN?

You get better deadlock information with ctrl-\ (of ctrl-break for
Windows) or jstack.

Very difficult to do that.

Looking back at the 1.5 source of PrintWriter println(Object) calls
toString on the object under the writer lock. That's generally a very
bad idea. 1.6 (b86) fixes that. However, the formatting methods are
still dangerous.

Tom Hawtin

May I suggest Java Thread Validator

http://www.softwareverify.com/javaThreadValidator/index.html

Stephen

Thank you all for your suggestions.  It is on a Socket-write, and my
thread-watcher thread is set up to scan all other threads in one swoop
and report all deadlocked threads at the same time (based on a simple
timeout), and yet these problems always come up alone. Wierd...

I'll look around for bad wait/notifies or sleeps -- no chance on the
former, unlikely on the later, but worth a shot.  Other threads wanting
to write on the same socket is rather necessary, so I need that to be
perfect.  Different threads intermingle their access to the each others
sockets in a rather chaotic manner, I'm afraid.  I suppose I could also
simplify my problem by trying to ditch PrintWriter and leave myself
with one less sync to worry about.

As for SVN, I've never felt a need for the web features, but I suppose
it couldn't hurt if it pleases those who might help me solve this
bewildering delima. :)

- Bo

I've got another stack dump of my deadlocked Socket-write threads, if
its helpful.  To me, it's all just perplexing.  This one occurs during
a flush of the output stream, which I do after every PrintStream.write
(can't use autoflush, since there are non-eoln prompts and such).

- Bo

6/12/2006 12:23 PM  Debug UtiliDump       java.net.SocketOutputStream:
socketWrite0(SocketOutputStream.java: -2)
6/12/2006 12:23 PM  Debug UtiliDump       java.net.SocketOutputStream:
socketWrite(SocketOutputStream.java: 92)
6/12/2006 12:23 PM  Debug UtiliDump       java.net.SocketOutputStream:
write(SocketOutputStream.java: 136)
6/12/2006 12:23 PM  Debug UtiliDump
sun.nio.cs.StreamEncoder$CharsetSE: writeBytes(StreamEncoder.java: 336)
6/12/2006 12:23 PM  Debug UtiliDump
sun.nio.cs.StreamEncoder$CharsetSE: implFlushBuffer(StreamEncoder.java:
404)
6/12/2006 12:23 PM  Debug UtiliDump
sun.nio.cs.StreamEncoder$CharsetSE: implFlush(StreamEncoder.java: 408)
6/12/2006 12:23 PM  Debug UtiliDump       sun.nio.cs.StreamEncoder:
flush(StreamEncoder.java: 152)
6/12/2006 12:23 PM  Debug UtiliDump       java.io.OutputStreamWriter:
flush(OutputStreamWriter.java: 213)
6/12/2006 12:23 PM  Debug UtiliDump       java.io.PrintWriter:
flush(PrintWriter.java: 270)
6/12/2006 12:23 PM  Debug UtiliDump
com.planet_ink.coffee_mud.Common.DefaultSession:
out(DefaultSession.java: 353)
6/12/2006 12:23 PM  Debug UtiliDump
com.planet_ink.coffee_mud.Common.DefaultSession:
onlyPrint(DefaultSession.java: 444)
6/12/2006 12:23 PM  Debug UtiliDump
com.planet_ink.coffee_mud.Common.DefaultSession:
rawPrint(DefaultSession.java: 452)
6/12/2006 12:23 PM  Debug UtiliDump
com.planet_ink.coffee_mud.Common.DefaultSession:
rawPrint(DefaultSession.java: 449)
6/12/2006 12:23 PM  Debug UtiliDump
com.planet_ink.coffee_mud.Common.DefaultSession:
stdPrintln(DefaultSession.java: 513)
6/12/2006 12:23 PM  Debug UtiliDump
com.planet_ink.coffee_mud.MOBS.StdMOB: tell(StdMOB.java: 2077)
6/12/2006 12:23 PM  Debug UtiliDump
com.planet_ink.coffee_mud.MOBS.StdMOB: tell(StdMOB.java: 2083)
6/12/2006 12:23 PM  Debug UtiliDump
com.planet_ink.coffee_mud.Libraries.CommonMsgs:
lookAtExits(CommonMsgs.java: 1380)
6/12/2006 12:23 PM  Debug UtiliDump
com.planet_ink.coffee_mud.Commands.Look: execute(Look.java: 140)
6/12/2006 12:23 PM  Debug UtiliDump
com.planet_ink.coffee_mud.Libraries.CommonMsgs:
doStandardCommand(CommonMsgs.java: 52)
6/12/2006 12:23 PM  Debug UtiliDump
com.planet_ink.coffee_mud.Libraries.CommonMsgs:
postLook(CommonMsgs.java: 133)
6/12/2006 12:23 PM  Debug UtiliDump
com.planet_ink.coffee_mud.Behaviors.Patroller: tick(Patroller.java:
416)
6/12/2006 12:23 PM  Debug UtiliDump
com.planet_ink.coffee_mud.Items.Basic.StdItem: tick(StdItem.java: 446)
6/12/2006 12:23 PM  Debug UtiliDump
com.planet_ink.coffee_mud.core.threads.Tick: tickTicker(Tick.java: 273)
6/12/2006 12:23 PM  Debug UtiliDump
com.planet_ink.coffee_mud.core.threads.Tick: run(Tick.java: 313)