gnu.trove classes throws java.lang.ArithmeticException: divide by zero

[Divya]

My application uses gnu.trove version 2.0.3 HashMap classes.

Recently divide by zero exceptions are being thrown by different areas of the gnu.trove library code

for example:

1.

java.lang.ArithmeticException: divide by zero at gnu.trove.TIntHash.index(TIntHash.java:201) at gnu.trove.TIntObjectHashMap.get(TIntObjectHashMap.java:204)

2.

java.lang.ArithmeticException: divide by zero at gnu.trove.TIntHash.insertionIndex(TIntHash. at gnu.trove.TIntObjectHashMap.put(TIntObjectHashMap.java:153)

3.

java.lang.ArithmeticException: divide by zero at gnu.trove.TPrimitiveHash.capacity(TPrimitiveHash.java:99) at gnu.trove.THash.postInsertHook(THash.java:358) at gnu.trove.TIntLongHashMap.put(TIntLongHashMap.java:165)

This is the snippet of the application code that throws divide by zero exceptions in one scenario:

TIntLongHashMap testMap = new TIntLongHashMap();
TIntLongHashMap test1Map = new TIntLongHashMap();
.
.
.
TIntLongIterator iter = test1Map.iterator();
for (int i = test1Map.size(); i-- > 0; )
{
        iter.advance();
        **testMap.put(iter.key(), iter.value());**
}     

From the stack trace, I looked at the lines of code that are throwing these exceptions inside these library classes:

1. at gnu.trove.TIntHash.index(TIntHash.java:201)

protected int index(int val)
/ / {
/ 185 / byte[] states = _states;
/ 186 / int[] set = _set;
/ 187 / int length = states.length;
/ 188 / int hash = _hashingStrategy.computeHashCode(val) & 0x7FFFFFFF;
/ 189 / int index = hash % length;
/ /
/ 191 / if ((states[index] != 0) && ((states[index] == 2) || (set[index] != val)))
/ / {
/ /
/ 194 / int probe = 1 + hash % (length - 2);
/ / do
/ / {
/ 197 / index -= probe;
/ 198 / if (index < 0) {
/ 199 / index += length;
/ / }
**/ 201 / } while ((states[index] != 0) && ((states[index] == 2) || (set[index] != val)))**;
/ / }
/ /
/ /
/ 205 / return states[index] == 0 ? -1 : index;
/ / }

2. at gnu.trove.TIntHash.insertionIndex(TIntHash. java:271)

protected int insertionIndex(int val)
/ / {
byte[] states = _states;
/ 220 / int[] set = _set;
/ 221 / int length = states.length;
/ 222 / int hash = _hashingStrategy.computeHashCode(val) & 0x7FFFFFFF;
/ 223 / int index = hash % length;
/ /
/ 225 / if (states[index] == 0)
/ 226 / return index;
/ 227 / if ((states[index] == 1) && (set[index] == val)) {
/ 228 / return -index - 1;
/ / }
/ /
/ 231 / int probe = 1 + hash % (length - 2);
/ 245 / if (states[index] != 2)
/ / {
/ / do
/ / {
/ 249 / index -= probe;
/ 250 / if (index < 0) {
/ 251 / index += length;
/ / }
/ 253 / } while ((states[index] == 1) && (set[index] != val));
/ / }
/ /
/ /
/ /
/ /
/ 259 / if (states[index] == 2) {
/ 260 / int firstRemoved = index;
/ 261 / while ((states[index] != 0) && ((states[index] == 2) || (set[index] != val)))
/ / {
/ 263 / index -= probe;
/ 264 / if (index < 0) {
/ 265 / index += length;
/ / }
/ / }
/ 268 / return states[index] == 1 ? -index - 1 : firstRemoved;
/ / }
/ /
/ **271 / return states[index] == 1 ? -index - 1 : index;
/ / }**

3. at gnu.trove.TPrimitiveHash.capacity(TPrimitiveHash.java:99)

/ / protected int capacity()
/ / {
**/ 99 / return _states.length;**
/ / }

As you see, these lines do not contain any division operation

Then why are these divide by zero exceptions being thrown? What are the scenarios in which the java.lang.ArithmeticException: divide by zero exceptions are thrown by the gnu.trove HashMap classes?

[Jim Davies]

Hi Divya,

First of all, let me thank you for using Trove, and also in reporting a bug. Many people don't report bugs, but this makes it hard for open source projects to improve.

You are correct, there doesn't appear to be any division operation at the line numbers shown. There are several reasons that this could be, the most likely being that the code that you are looking at is not an exact presentation of the code that is running. There are so many reasons that could be, that I'll rely on Google to lead your way.

There is a divide by zero error there. However, the 2.0.3 version of the code has been superseded, so we are not looking to fix bugs on older versions of the code.

Would it be possible for you to upgrade to latest version of the code 3.0.3?

[Rob Eden]

@user0691 - You're asking these questions in too many places and then not answering questions that are asked. Could you please look at the questions in the comments of your question at Stack Overflow?

https://stackoverflow.com/questions/48170039/gnu-trove-classes-throws-java-lang-arithmeticexception-divide-by-zero

This is highly unlikely to be a Trove-centric problem. Most likely it is a concurrency issue (trove classes are not inherently thread safe) or that you have multiple versions in the classpath and have dueling class versions.

[Divya]

@jimdavies Our application has been using trove classes for a long time now. Upgrading to 3.0.3 means rewriting a lot of code. But I will surely update your suggestion to the architects.

@Rob Eden I have seen the questions at Stack Overflow and provided answers too. Is there a particular question that you think I have not answered correctly?

Also can you elaborate on how concurrency or multiple versions in the classpath and dueling class versions can cause divide by zero exception? I am just trying to get more information for better understanding.

[Jim Davies]

@divya Well, thanks again for your patience, it's certainly appreciated. In the mean time, there isn't a lot that we can do to help you without a better idea of when it's happening. I'll close this issue for now as I don't think that there is enough here for us to be certain that it's an issue with Trove. However, it would be really helpful for us if you could continue to isolate this on your side. When you've narrowed it to a small piece of code that reliably demonstrates a bug, please create an issue and cut and paste the code in. Then we can set to work fixing Trove for you!

[Jim Davies]

Closing for now. Awaiting test evidence of the issue.

[Rob Eden]

I asked another question on SO:

Have you used Proguard (or something similar)? In general I'd say there's probably a concurrency issue, but the line number mismatches indicate a classpath problem (multiple versions of the code). I haven't been able to find a release which would match the error you're seeing.