Thursday, February 19, 2009

Is it Me?

After struggling against nonsensical errors all day, I finally realized that either Eclipse was going mad, or I was. In frustration I finally updated a method to look like this:
  public void setContextOwner(ContextOwner owner) {
contextOwner = owner;
if (owner != contextOwner) throw new AssertionError("VM causing problems");
}
This code throws an AssertionError, and yes, there is only 1 thread. If it were multithreaded at least I'd have a starting point. The problem only appears while debugging in Eclipse.

I'm not sure whether I'm happy to have isolated my problem down to a single point, or to be unhappy at something that is breaking everything I am trying to work on. I guess I'm unhappy, because it's kept me up much later than I'd hoped.

2 comments:

David A. said...

Have you tried stepping through it in the debugger?

Quoll said...

I should have explained that this is exactly what CAUSES the problem. If I'm not stepping through it, then the code runs correctly. My lack of explanation was most likely due to it being about 1am, and I was getting frustrated.

I had a bug that I was trying to track down (it ended up being a silly mis-reading of an API), and in the process I decided to step through the relevant code. However, some really weird things started to happen, and I finally realized it was because the state of certain objects wasn't set correctly. When I paid more careful attention, I discovered that it was being caused by an assignment statement not working. In desperation, I followed the assignment with if()/throw that described above, and voilá!

Once I made the post, I decided to set my breakpoints more carefully, which is how I found the problem in the end.

I didn't blog about it, but a couple of months ago I encountered a similar problem with ByteBuffers. A member variable (the "position" in the buffer) did not change, despite a relative get(). In this case, it happened regardless of being stepped through or running normally. In that case I fixed it by using absolute addressing instead of relative (the get(int) method instead of get()), but there wasn't such a simple fix here.