ArrayIndexOutOfBoundsException in TLongObjectHashMap.rehash(..)

Issue #50 closed
Bartosz Firyn created an issue

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)

  1. Rob Eden

    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.

  2. Bartosz Firyn 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.

  3. Rob Eden

    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?

  4. jimdavies

    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.

  5. Log in to comment