. I will try and find that
tech note and re-read it, its been a while. Thanks for the
reminder that it exists.
Yeah, I think there might be something specific to deadlocks that
might tell you more than the hex address of the locking object.
As I remember there were also commands though to display objects by
hex address if you do need to resort to that I think. That might
just point you to the heap the object uses though. With the info
pointed to there you might be able to use nicer display commands
that you might be able to then correspond. I'm remembering display
object, find instance, maybe find class commands?
I did sort of like MacsBug as I remember, it gave you a bit more
than just the stack crawls.
I'm not having any real trouble sorting out the deadlock, other than
why SwingUtilities.invokeLater is causing the Runnables to be executed
on the AWT-Dispatch-Proxy thread, rather than AWT-EventQueue-0. I can
tell exactly which objects monitors are being held, and by whom. The
"mrj syncCheck" and "mrj syncDump" commands are very useful for this.
I've done some more experimentation, and it looks that all invokeLater
requests get serviced by AWT-Dispatch-Proxy while a nested event loop
is running a modal dialog. This suggests it is deliberate, and I have
the theory that this is so that logically distinct Runnables do not
inherit any environmental features from the code originally executing
on AWT-EventQueue-0, such as locked monitors. This would shift the
observed behaviour from being a "bug" to being a "feature", and thus
no longer alarming.
We are reworking the offending code to not post the dialog (which is
part of our login sequence) from a context holding locked monitors.
Performing such a time-consuming operation while holding a monitor is
a poor choice, and is the ultimate cause of the deadlock. The monitor
is not even needed for this operation, but the login sequence got
shoehorned in there as it defined the earliest time we could start
the login operation.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
