You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Thomas Mueller (Jira)" <ji...@apache.org> on 2022/06/09 15:28:00 UTC

[jira] [Created] (OAK-9796) oak-segment-remote tests fail with ARM processor (Apple M1)

Thomas Mueller created OAK-9796:
-----------------------------------

             Summary: oak-segment-remote tests fail with ARM processor (Apple M1)
                 Key: OAK-9796
                 URL: https://issues.apache.org/jira/browse/OAK-9796
             Project: Jackrabbit Oak
          Issue Type: Improvement
            Reporter: Thomas Mueller
            Assignee: Thomas Mueller
             Fix For: 1.42.0, 1.22.11


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.7#820007)