On Tuesday 24 July 2001 22:23, Edwin Goei wrote:
> I believe the -Xint option does it for JDK 1.3. Is it always
> reproducible or intermittent?
It is intermittent. You have to play around until you get it. Moreover,
as I said earlier, if you add code that should not effect execution
(like if's that are always false) the problem goes away...
> I don't know if this would make any
> difference, but what happens if you run the code on a uniprocessor
> machine?
We haven't tried disabling the other processors.
> I haven't tried to understand the code at all, but I did see some code
> with synchronized around it.
It's not a thread problem. Even if that piece of code is not thread-safe, it
should not be affected because the variable that gets corrupted is a local
variable, and thus thread-local.
> Multi-threaded code can be difficult to debug.
They sure are. Even if its a threading problem, I'm sure its one that is in
the VM or JIT.
> The next step I would take would be to add debug statements in
> the code.
Unfortunately, doing this tends to get rid of it, but we can try...
> If it is a bug in the JDK, I'm sure the JVM developers would
> be very interested in fixing it, but I would suspect they would want a
> convincing argument that the bug is indeed in the JVM code.
Inspecting the code should be a pretty good argument. It is mathematically
provable that it should not happen. It happens, and thus it's a bug.
--
Dimi.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
