[CONTROLLER-587] Heisenbug in DataNormalizerTest Created: 29/Jun/14 Updated: 25/Jul/23 Resolved: 03/Jul/14 |
|
| Status: | Resolved |
| Project: | controller |
| Component/s: | mdsal |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | ||
| Reporter: | Colin Dixon | Assignee: | Colin Dixon |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: Mac OS |
||
| External issue ID: | 1256 |
| Description |
|
On MacOS 10.9.3 (verified on 3 machines) with Java 1.7, the DataNormalizerTest fails because the comparator provided in verifyLegacyNode() does not actually provide a total ordering of the childData and childNodes. It appears as though Windows and Linux are immune. This results in a build failure for sal-common-impl that looks like this: ------------------------------------------------------- |
| Comments |
| Comment by Tony Tkacik [ 30/Jun/14 ] |
|
This boils down that test expects ordering from HashMap (hashMap ordering |
| Comment by Tony Tkacik [ 30/Jun/14 ] |
|
Implementation of verify for composite nodes, assumes ordering even for elements Easy way to replicate this bug is just to modify QName#hashCode() to return 0 for hashCode. |
| Comment by Colin Dixon [ 30/Jun/14 ] |
|
I created a partial (complete for the current unit tests) patch for this last night: |
| Comment by Colin Dixon [ 03/Jul/14 ] |
|
Since the code was in a Unit test and the submitted fix will generate exceptions if the assumptions it makes are violated, I've marked this as fixed since I don't think it could regress without failing in the verify stage. |