Bug 1249261
Summary: | [QE](6.1.z) NullPointerException on LeftTupleIndexHashTable.remove() | ||
---|---|---|---|
Product: | [Retired] JBoss BRMS Platform 6 | Reporter: | Alessandro Lazarotti <alazarot> |
Component: | BRE | Assignee: | Mario Fusco <mfusco> |
Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Tibor Zimanyi <tzimanyi> |
Severity: | unspecified | Docs Contact: | |
Priority: | high | ||
Version: | 6.1.0 | CC: | kverlaen, mfusco, rrajasek, tzimanyi |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | 1248661 | Environment: | |
Last Closed: | 2015-09-28 17:56:43 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 1248661 | ||
Bug Blocks: |
Description
Alessandro Lazarotti
2015-08-01 01:02:57 UTC
The optaplanner-based reproducer is non-deterministic, very likely because the domain objects used in it lack of the hashCode() method and then objects are hashed and iterated in a way that depends on their memory location. In other terms 2 subsequent runs of that reproducer always have a different outcomes making impossible the investigation of this problem. Tibor is working to provide a deterministic reproducer. Adding appropriate hashCode() methods to POJOs that are used in the failing Optaplanner test didn't help with providing us a reproducer for this issue. Further investigation also didn't help (using TruthMaintenanceTest and other test cases that produce the same stack trace as the stacktrace from bug description). Because this issue occurred only in a test in Jenkins environment (aix7 with ibm jdk7) and we still wasn't able to reproduce it on local environments, I propose that we move this bug to another later patch. From my investigation it looks like a very rare occurring bug that is connected with some hashing problem. The main point of focus from my point of view can be LeftTupleIndexHashTable class or it's parent class AbstractHashTable. But this should be investigated further. We are still unable to reproduce the reported problem so I'm closing this issue for now. Feel free to reopen it if you can provide a reproducer. It looks like that this can be related to some IBM JDK 7 garbage collection issue. Because we experienced another strange NPE during testing on the same machine on which this fail occured (AIX 7 machine with IBM JDK 7.0). See here [1]. NPE occured on line [2] on which it shouldn't, because when you look into the code, the iterated map there is initialized only in constructor and there is never null assigned to it. Also it allows null keys, so get() method used on that line cannot produce NPE. Suspicious IBM JDK bug, that can cause this strange behaviour is this [3]. We will have a new IBM JDK 7 version installed on that machine in coming days, so we will see if these kind of fails still occur there after that. [1] http://pastebin.com/UkvH5J1T [2] https://github.com/droolsjbpm/optaplanner/blob/6.2.x/optaplanner-core/src/main/java/org/optaplanner/core/impl/domain/variable/listener/VariableListenerSupport.java#L144 [3] http://www-01.ibm.com/support/docview.wss?uid=swg1IV74133 |