1

I am working on a small module as part of a very large open-source project. The overall program records audio, and the user is able to select various modules which run analysis in real time. My module has a few text boxes that allows the user to keep track of operating parameters. Sometimes, when a lot of modules are loaded and operating on the data simultaneously, changing one of my text boxes causes the program to choke when it tries to alert my module that there is new data.

The line causing the error is

pamObservers.get(i);

pamObservers is an ArrayList of size 4, and my module is in index 3. i=3 when the error occurs. The error message is

IndexOutOfBoundsException: Index: 3, Size: 4

I'm using the Eclipse IDE, and I've added a breakpoint for that exception so it's stopping immediately. I look at pamObservers in the Variables view and I can see that my module is there - that index position isn't null or anything. I can type the line in the Expressions view and it returns the name of my module.

I don't know how to troubleshoot this, because it seems like it should work. The error is random - sometimes I have to change the text boxes 4 or 5 times before it occurs. Any suggestions would be appreciated, because I've been running around in circles for almost 2 hours and I just don't know what to do. Thanks so much.

Michael
  • 141
  • 2
  • 12
  • you need to check if pamObservers is empty. before use – Mayank Pandya May 26 '15 at 05:54
  • please show us rest of your code – Lrrr May 26 '15 at 05:57
  • 2
    Usually it is not possible to get an IOOBE with an index less than the size. The corresponding code in `ArrayList` is the `rangeCheck` method: `if (index >= size) throw new ...`. So I could only assume threading issues. That would also match your observations getting the error occasionally. Your questions lacks some code, so we cannot reproduce your issue. Please create and post an [MCVE](http://stackoverflow.com/help/mcve). – Seelenvirtuose May 26 '15 at 05:59
  • That is exceptionally peculiar. – ApproachingDarknessFish May 26 '15 at 06:08
  • I apologize for not including code. The line I gave is just part of a short for loop, from 0 to pamObservers.size(). As far as reproducing the error, I don't think you could reproduce it without running the entire program. Threading issues seems like a definite possibility - the Debug view shows this as Thread 13 out of 41 and I don't know what's happening in the other threads. I haven't worked with threads very much at all, so if that's the problem then I'm really in trouble... – Michael May 26 '15 at 06:15
  • As written above, probably threading problem. Try to use synchronized list instead of pamObservers or iterate over synchronized copy of original list. – agad May 26 '15 at 06:19
  • pamObservers is definitely changing behind the scenes. I saved the size() in a separate variable, and sometimes it came back as 5 instead of 4. I guess that by the time the breakpoint occurs and I check the Variables view, the threads have all caught up/synchronized and the ArrayList is correct again. – Michael May 26 '15 at 06:53
  • @Michael Debugging threading issues is always complicated. I can assume the following scenario: Your list (referred to by `pamObservers`) is also used in some other code which also changes it. So by the time the `rangeCheck` method is called, the given index is _not_ less than the size causing to throw the exception. But before the exception message is assembled (another method), another thread changes the list by adding elements and thus increasing the size. – Seelenvirtuose May 26 '15 at 06:55

1 Answers1

1

Something's very fishy here, but my gut tells me that the condition you have for your collection isn't always true.

Consider setting a conditional breakpoint such that i >= pamObservers.size(). This way, Eclipse will actually stop the debugger only when pamObservers.get(i) would cause the exception, and you can properly inspect the state of your code.

Some tips when debugging like this:

  • Come up with a hypothesis to the behavior. If you can hypothesize about the behavior, it will be far more productive than clutching at straws.
    • Current working hypothesis: pamObservers is mutating in some way unbeknownst to us.
  • Prove your hypothesis. Run tests like step debugging in certain conditions.
    • Test case: using a conditional breakpoint which will stop execution when i is equal to or larger than the size of the collection.
  • Verify your results. See if the hypothesis you had for the behavior in code led you to a good solution, and if it didn't, repeat these steps until you narrow the scope of the behavior.
Community
  • 1
  • 1
Makoto
  • 104,088
  • 27
  • 192
  • 230
  • Thanks - I didn't know about conditional breakpoints. And your tips are really good. I'll see if I can narrow down what's going in. Thanks for the suggestions. – Michael May 26 '15 at 06:51