[ https://issues.apache.org/jira/browse/OAK-9634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thomas Mueller resolved OAK-9634. --------------------------------- Fix Version/s: 1.42.0 Resolution: Fixed > CacheLIRS: test failure with ARM processor > ------------------------------------------ > > Key: OAK-9634 > URL: https://issues.apache.org/jira/browse/OAK-9634 > Project: Jackrabbit Oak > Issue Type: Improvement > Reporter: Thomas Mueller > Assignee: Thomas Mueller > Priority: Major > Fix For: 1.42.0 > > > In a ARM machine (MacBook with M1 chip) I get a "somewhat" reproducible > failure as follows: > {noformat} > [ERROR] Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 2.304 > s <<< FAILURE! - in org.apache.jackrabbit.oak.cache.ConcurrentTest > [ERROR] testRandomOperations(org.apache.jackrabbit.oak.cache.ConcurrentTest) > Time elapsed: 1.068 s <<< ERROR! > java.lang.NullPointerException > at > org.apache.jackrabbit.oak.cache.CacheLIRS$Segment.find(CacheLIRS.java:1323) > at org.apache.jackrabbit.oak.cache.CacheLIRS.peek(CacheLIRS.java:263) > at > org.apache.jackrabbit.oak.cache.CacheLIRS.entrySet(CacheLIRS.java:545) > at > org.apache.jackrabbit.oak.cache.CacheLIRS$1.entrySet(CacheLIRS.java:1731) > at > org.apache.jackrabbit.oak.cache.ConcurrentTest$3.run(ConcurrentTest.java:210) > {noformat} > If I slightly change the code (e.g. add try-catch in the find method), then > it no longer fails. I think the problem is the different memory model of ARM > chips, and so e.key is assigned a bit after the entry is added to the array. > Making the key final resolved the issue for me. -- This message was sent by Atlassian Jira (v8.20.1#820001)