Impossible Exception

Discussion in 'Java' started by Christian, Jun 21, 2008.

  1. Christian

    Christian Guest

    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(Semaphore.java:38)
    at org.eclipse.core.internal.jobs.JobManager.join(JobManager.java:699)
    at org.eclipse.core.internal.jobs.InternalJob.join(InternalJob.java:321)
    at org.eclipse.core.runtime.jobs.Job.join(Job.java:384)
    at
    de.du_hub.uc.gui.transferview.TransfersView.update(TransfersView.java:288)
    at java.util.Observable.notifyObservers(Unknown Source)
    at uc.ConnectionHandler.notifyObservers(ConnectionHandler.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, Jun 21, 2008
    #1
    1. Advertising

  2. Christian

    Christian Guest

    Zig schrieb:
    > On Sat, 21 Jun 2008 06:16:36 -0400, Christian <> 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(Semaphore.java:38)
    >> at
    >> org.eclipse.core.internal.jobs.JobManager.join(JobManager.java:699)
    >> at
    >> org.eclipse.core.internal.jobs.InternalJob.join(InternalJob.java:321)
    >> at org.eclipse.core.runtime.jobs.Job.join(Job.java:384)
    >> at
    >> de.du_hub.uc.gui.transferview.TransfersView.update(TransfersView.java:288)
    >>
    >> at java.util.Observable.notifyObservers(Unknown Source)
    >> at uc.ConnectionHandler.notifyObservers(ConnectionHandler.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, Jun 21, 2008
    #2
    1. Advertising

  3. Christian

    Christian Guest

    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
    Christian, Jun 21, 2008
    #3
  4. Christian

    Stefan Ram Guest

    "Larry A Barowski" <ThisisLarrybarAtEngDotAuburnDotLearninginstitution> 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/technology/2008/03/do-we-need-cosmic-ray-alerts-for.html
    Stefan Ram, Jun 22, 2008
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Rick Spiewak
    Replies:
    1
    Views:
    415
    Rick Spiewak
    Jul 22, 2003
  2. Brian Birtle
    Replies:
    3
    Views:
    2,410
  3. =?Utf-8?B?VVJHRU5ULi5QbGVhc2U=?=

    IMPOSSIBLE QUESTION

    =?Utf-8?B?VVJHRU5ULi5QbGVhc2U=?=, Sep 4, 2004, in forum: ASP .Net
    Replies:
    4
    Views:
    587
    Greg Burns
    Sep 4, 2004
  4. Replies:
    0
    Views:
    734
  5. Replies:
    5
    Views:
    248
    Michele Dondi
    Jun 30, 2006
Loading...

Share This Page