Bug 53277 - HashTree can theoretically drop elements
Summary: HashTree can theoretically drop elements
Status: NEW
Alias: None
Product: JMeter - Now in Github
Classification: Unclassified
Component: Main (show other bugs)
Version: 2.6
Hardware: All All
: P2 enhancement (vote)
Target Milestone: ---
Assignee: JMeter issues mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-05-22 22:32 UTC by Sebb
Modified: 2017-01-25 07:33 UTC (History)
1 user (show)


Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Sebb 2012-05-22 22:32:09 UTC 
The HashTree class currently uses a HashMap to store test elements.

Now a HashMap cannot store two Objects which compare equal and have the same hash code. Test elements currently use the system hash code, so collisions are unlikely; however they are not impossible. It's quite easy to create multiple test elements which compare equal.

So there is a risk that a new element which is added to the HashTree could displace an existing entry.

One solution to this is to use IdentityHashMap instead of HashMap; this uses == rather than equals when comparing elements.
Comment 1 Sebb 2012-05-22 22:40:12 UTC 
Unfortunately, this causes unit test failures in

PackageTest.testEqualsAndHashCode1()
PackageTest.testEqualsAndHashCode2()

It looks like supporting HashTree equality will need additional work.
So for now at least we probably have to accept the theoretical risk of a hash code and equals collision.
Comment 2 Geert-Jan 2012-06-19 13:32:36 UTC 
Hi,

I think I just ran into this bug, proving it is not only theoretical. Th exception I got looks like:

2012/06/19 14:56:30 ERROR - jmeter.JMeter: Error in NonGUIDriver java.lang.NullPointerException
        at org.apache.jorphan.collections.HashTree.traverseInto(HashTree.java:975)
        at org.apache.jorphan.collections.HashTree.traverseInto(HashTree.java:975)
        at org.apache.jorphan.collections.HashTree.traverse(HashTree.java:959)
        at org.apache.jmeter.engine.StandardJMeterEngine.configure(StandardJMeterEngine.java:176)
        at org.apache.jmeter.JMeter.runNonGui(JMeter.java:778)
        at org.apache.jmeter.JMeter.startNonGui(JMeter.java:716)
        at org.apache.jmeter.JMeter.start(JMeter.java:377)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.apache.jmeter.NewDriver.main(NewDriver.java:216)

This was caused by two identical Include-Controllers on the main (and same) level of a thread group. After I moved the second Include-Controller one level up, as a child of a Simple Controller, the problem was solved. Not sure but it can be related to the usage of HashMap. Just one funny remark, I only got this NullPointerException when running jmeter with the -n option.
Comment 3 Sebb 2012-06-19 14:43:08 UTC 
Which version of JMeter were you using?

I think you have hit Bug 50898 which is fixed in 2.7.

[It's unlikely that this bug will cause an NPE]

The behaviour in non-GUI mode is likely different because in GUI mode there are  additional variables that affect the hash code.
Comment 4 The ASF infrastructure team 2022-09-24 20:37:50 UTC 
This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/2831