This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: debugging threads vs processes
- To: "Cedric Berger" <cedric at wireless-networks dot com>
- Subject: Re: debugging threads vs processes
- From: Jonathan Olson <jpolsonaz at mac dot com>
- Date: Fri, 13 Jul 2001 10:09:05 -0700
- Cc: <tromey at redhat dot com>, "Jeff Sturm" <jsturm at one-point dot com>, "Per Bothner" <per at bothner dot com>, <java-discuss at sources dot redhat dot com>
My experience with JDK/JNI code at least is that the Java virtual machine
either crashes or all Java threads are hopelessly hung on Linux when you attach
GDB. This Linux bug doesn't only affect Posix semaphores. Ultimately, the
Java monitors invoke Posix monitors and conditions which also wakeup when
you attach the debugger. Having all threads wakeup from blocked monitors
when you attach GDB violates the basic invariant that only one thread can
be within a synchronized section at any given time.
On Friday, July 13, 2001, at 08:51 AM, Cedric Berger wrote:
jpolsonaz@mac.com wrote:
> Has anybody tried using IBM's new Linux threading library with GCJ?
>
> My personal experience with the currently released LinuxThreads is that
> multi-threaded applications are almost undebuggable. LinuxThreads
> currently has a bug that causes all threads to wakeup from semaphores
> the first time you connect a debugger to the process. This, of course, immediately
> crashes most multi-threaded applications since they don't expect to wake
> up until the semaphore actually gets signaled.
The "wakeup from semaphore" should not be too much of a problem in Java,
because properly written Java never blindly trust "semaphores", but use code
be written this way:
synchronized myFunction() {
while(condition not met)
object.wait(); // this "semaphore" can get glitches, it doesn't matter.
}
Now, of course, if the "mutex" which is used to implements the "synchronized"
keyword itself suffers the same problem, this would be a disaster....
Anyay, I unfortunately agree with your comments.
Cedric