- edited description
ArrayIndexOutOfBoundsException in TLongObjectHashMap.rehash(..)
Hi,
At the very first words I would like to thank you for this great library :) It really helps me save a lot of Java heap space.
Now to the core of the problem. Today I noticed this exception in the logs:
Exception in thread "leaderboard-1" java.lang.ArrayIndexOutOfBoundsException: -26855 at gnu.trove.map.hash.TLongObjectHashMap.rehash(TLongObjectHashMap.java:165) at gnu.trove.impl.hash.THash.compact(THash.java:201) at gnu.trove.impl.hash.THash.removeAt(THash.java:272) at gnu.trove.impl.hash.TPrimitiveHash.removeAt(TPrimitiveHash.java:119) at gnu.trove.impl.hash.TLongHash.removeAt(TLongHash.java:193) at gnu.trove.map.hash.TLongObjectHashMap.removeAt(TLongObjectHashMap.java:270) at gnu.trove.map.hash.TLongObjectHashMap.remove(TLongObjectHashMap.java:261) at com.github.sarxos.elm.Leaderboard$ScoreProcessor.run(Leaderboard.java:511) at java.lang.Thread.run(Thread.java:744)
Please note that I experienced it only once, not really sure why, but regardless its rare occurence, I think it would be good to implement some check to verify if index of array is in bounds.
The code I invoke in Leaderboard.java:511 is really simple, so I doubt it may be a cause of this problem:
private final TLongObjectHashMap<byte[]> bckref = new TLongObjectHashMap<>();
And:
long id = score.getId().longValue(); if ((key = bckref.remove(id)) != null) { scores.remove(key); }
The Trove version I'm using is:
<dependency> <groupId>net.sf.trove4j</groupId> <artifactId>trove4j</artifactId> <version>3.0.3</version> </dependency>
Comments (9)
-
reporter -
I've never heard of this happening without being a threading issue. If you think otherwise, we'll need some more debugging info and possibly a test case.
-
- changed milestone to Suspected Not-Bug (Discussing)
-
reporter Hi. Well, it may be, at least in theory, since this reference should be accessed from by the single thread only (according to what I see in the code). I experienced this exception only once and the same code is working well for the very long time now.
-
How large is your map? Is it possible you're bumping up on size limitations?
-
reporter Usually it's less than 200k elements, mostly 90-120k.
-
Nope, that shouldn't be the issue then. Dunno, sounds like threading to me. Could you try wrapping with TCollections.synchronizedMap(...) and see if that helps?
-
Any update on this?
-
- changed status to closed
Without a test case demonstrating the issue, or some indication of under what circumstances it happens, I cannot proceed with a fix. I will re-open this when additional evidence is provided.
- Log in to comment