Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Java (http://www.velocityreviews.com/forums/f30-java.html)
-   -   Impossible Exception (http://www.velocityreviews.com/forums/t621496-impossible-exception.html)

Christian 06-21-2008 10:16 AM

Impossible Exception
 
Hello Folks,

I just encountered one of those impossible Exceptions.. now I would like
to ask if someone has an explanetion how this could happen.
First the stacktrace (Only Top line Semaphore.acqire seems important to me):

java.lang.IllegalMonitorStateException
at java.lang.Object.wait(Native Method)
at org.eclipse.core.internal.jobs.Semaphore.acquire(S emaphore.java:38)
at org.eclipse.core.internal.jobs.JobManager.join(Job Manager.java:699)
at org.eclipse.core.internal.jobs.InternalJob.join(In ternalJob.java:321)
at org.eclipse.core.runtime.jobs.Job.join(Job.java:38 4)
at
de.du_hub.uc.gui.transferview.TransfersView.update (TransfersView.java:288)
at java.util.Observable.notifyObservers(Unknown Source)
at uc.ConnectionHandler.notifyObservers(ConnectionHan dler.java:350)
....

so and the code of that Semaphore implementation:

public synchronized boolean acquire(long delay) throws
InterruptedException {
if (Thread.interrupted())
throw new InterruptedException();
long start = System.currentTimeMillis();
long timeLeft = delay;
while (true) {
if (notifications > 0) {
notifications--;
return true;
}
if (timeLeft <= 0)
return false;
wait(timeLeft); //here is Line 38
timeLeft = start + delay - System.currentTimeMillis();
}
}


Someone got an Idea what can create such an Exception. Not that I would
know a way to reproduce it. Though I am curious.

Christian 06-21-2008 06:57 PM

Re: Impossible Exception
 
Zig schrieb:
> On Sat, 21 Jun 2008 06:16:36 -0400, Christian <fakemail@xyz.de> wrote:
>
>> Hello Folks,
>>
>> I just encountered one of those impossible Exceptions.. now I would
>> like to ask if someone has an explanetion how this could happen.
>> First the stacktrace (Only Top line Semaphore.acqire seems important
>> to me):
>>
>> java.lang.IllegalMonitorStateException
>> at java.lang.Object.wait(Native Method)
>> at
>> org.eclipse.core.internal.jobs.Semaphore.acquire(S emaphore.java:38)
>> at
>> org.eclipse.core.internal.jobs.JobManager.join(Job Manager.java:699)
>> at
>> org.eclipse.core.internal.jobs.InternalJob.join(In ternalJob.java:321)
>> at org.eclipse.core.runtime.jobs.Job.join(Job.java:38 4)
>> at
>> de.du_hub.uc.gui.transferview.TransfersView.update (TransfersView.java:288)
>>
>> at java.util.Observable.notifyObservers(Unknown Source)
>> at uc.ConnectionHandler.notifyObservers(ConnectionHan dler.java:350)
>> ...
>>
>> so and the code of that Semaphore implementation:

>
> Yeah, that one is a bit wierd. Questions first:
>
> * What OS & version?
> * What version of org.eclipse.core.jobs, and associated fragments?

I am afaik using normal eclipse 3.3 to build my rcp-app against.
> * Can you reproduce this?

No
>
> A few thoughts:
>
> * Avoid starting threads & jobs during OSGi bundle startup. The bundle
> classloader isn't fully initialized, and wierdness may ensue.

this occured in the middle of the program
> * If you are using PDE, you might ensure that you are not running in the
> debugger? While the debugger works most of the time, it does redefine
> classes on the fly in the target JVM, thus wierdness occassionally happens.

Thats probably the best explanation till now.
Weirdness introduced by the debugger. I can think of that as much more
possible than random Ram failure.

Thank you!

Christian

>
> Assuming your source for JobManager.java:694-708
>
> try {
> while (true) {
> //notify hook to service pending syncExecs before falling asleep
> lockManager.aboutToWait(job.getThread());
> try {
> if (barrier.acquire(Long.MAX_VALUE))
> break;
> } catch (InterruptedException e) {
> //loop and keep trying
> }
> }
> } finally {
> lockManager.aboutToRelease();
> job.removeJobChangeListener(listener);
> }
>
> Since another poster has pointed out Sun's bug 4142926, it's probably
> worth posting to bugs.eclipse.org to use Integer.MAX_VALUE instead of
> Long.MAX_VALUE since that would be equally effective, while working
> around the chance of running on a JVM that has issues when big values
> passed into Object.wait.
>
> HTH,
>
> -Zig


Christian 06-21-2008 06:59 PM

Re: Impossible Exception
 
Lew schrieb:
> Lew wrote:
>> Christian wrote:
>>> I just encountered one of those impossible Exceptions..

>>
>> Obviously it is not "impossible", and calling it that will tend to
>> make it harder to understand.
>>
>>> now I would like to ask if someone has an explanetion how this could
>>> happen.

>>
>> You failed to acquire the monitor for the object on which you wait().
>> In other words, you have to be synchronized on the object, which you
>> weren't.
>>
>>> ...
>>> public synchronized boolean acquire(long delay) throws

>>
>> Here you synchronize on 'this'.
>>
>>> InterruptedException {
>>> if (Thread.interrupted())
>>> throw new InterruptedException();
>>> long start = System.currentTimeMillis();
>>> long timeLeft = delay;

>>
>> How is anyone else ever going to 'notify()' on this 'timeLeft' if it's
>> local?

>
> Crap, I completely screwed up on this one. Sorry. I should have
> studied the Javadocs first.
>
> Note to self: Always read the Javadocs. Always read the Javadocs.
> Always read the Javadocs.
>
> I was wrong. Your call to 'wait()' does attempt to use the monitor for
> 'this', so it shouldn't have failed, based on what we see in your post.
>
> Perhaps an SSCCE will help clear things up.
>

Sry no SSCCE possible.
I doubt I would be able to reproduce this.

Christian

Stefan Ram 06-22-2008 02:36 AM

Re: Impossible Exception
 
"Larry A Barowski" <ThisisLarrybarAtEngDotAuburnDotLearninginstitutio n> writes:
>> I can think of that as much more possible than random Ram failure.


I am Ram, and I do not fail. However, »RAM«, which is
»Random Access Memory«, might fail.
¯ ¯ ¯
>I wasn't really offering that as a likely cause.


»Cosmic ray induced computer crashes have occurred and are
expected to increase with frequency as devices (for
example, transistors) decrease in size in chips. This
problem is projected to become a major limiter of computer
reliability in the next decade.«

http://www.newscientist.com/blog/tec...lerts-for.html



All times are GMT. The time now is 08:40 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.