Crash in compiled code on Linux PPC when running with disableTOC option #10939
Comments
|
@aviansie-ben @zl-wang - fyi |
dsouzai
added
arch:power
comp:jit
segfault
|
Just tested this myself and can confirm the problem. It looks to me like the second-highest-order 16 bits of the target address of a call are somehow ending up in the highest-order 16 bits instead. When placing those bits in the correct location in my testing, it seems to be attempting to call |
During a previous rework of how trampolines are generated, support was added for helper trampolines to be generated when the pTOC is explicitly disabled. However, this implementation accidentally used an oris instruction where it should have used an ori instruction, which results in the branch going to the wrong address. This bug has been fixed. Fixes: eclipse-openj9#10939 Signed-off-by: Ben Thomas <ben@benthomas.ca>
|
Tracked the problem down to an incorrect instruction when generating helper trampolines with |
|
@aviansie-ben the changes for #10942 resolve the crash when shared class cache is disabled, but I still see the crash when shared classes is enabled when using To reproduce, unzip the file gdb shows this info: At crash point r16 happens to be 0x0 (from the javacore). Dumping the instructions for the call just after the crash point: This sequence results in call to Another observation is if I use Dumping instructions for the jitted method in frame 15: Note that the instruction sequence in this case is different than in the previous case when Dumping the instructions at the target address of the last branch instruction: The instruction sequence at Call at At the start of this sequence This seem to indicate r2 is not loaded correctly, which happens to be set in first two instructions of So |
|
Running with AOT on and with The other issue looks completely different and seems to be related to the linkage not correctly loading the address of the target method into @zl-wang Any ideas? |
|
When disabling pTOC, gr16 is still used: that means you have out of dated code base (before p10 work items were completed). On the other hand, @AlenBadel and @gita-omr are handling AOT helper addresses not properly relocated (when pTOC disabled). This looks like a dup to that. |
|
@zl-wang I tried with the latest level, and it still fails the same as before. |
|
did you destroy your SCC AOT cache, before re-running the test case? |
|
yes, I am using |
|
still crash on: ld r12, 720(r16) from AOT code? |
|
No, AOT does not imply that the pTOC is disabled even though AOT does not use the pTOC much. The only reason AOT doesn't use the pTOC is because the relocation infrastructure doesn't currently support updating the pTOC and relocating pTOC load sequences. IIRC AOT code will still use the pTOC for the helper addresses since they're at known offsets within the pTOC and thus do not require emitting any relocations. All of the problems when not specifying |
|
maybe I was not clear: |
|
I cannot find any code that's supposed to set that option in AOT for the case where [1] https://github.com/eclipse/omr/blob/8f0354071ad30192d665808207b353214b8b2b3a/compiler/control/OMROptions.cpp#L1966-L1969 |
|
then, you are right: globally disableTOC is not expected to work with AOT without disableTOC. |
|
I understand the configuration |
|
as mentioned previously, i expected it to be the dup @AlenBadel is trying to fix. |
|
Yes, @AlenBadel and myself are looking into it. |
During a previous rework of how trampolines are generated, support was added for helper trampolines to be generated when the pTOC is explicitly disabled. However, this implementation accidentally used an oris instruction where it should have used an ori instruction, which results in the branch going to the wrong address. This bug has been fixed. Fixes: #10939 Signed-off-by: Ben Thomas <ben@benthomas.ca>
I came across this issue while working on some other item. If I use
-Xjit:disableTOCI see a crash in the compiled code.The issue is reproducible easily using latest nightly builds from Adopt.
I used the following version:
Command to reproduce:
$ ~/builds/jdk-11.0.9+10-jre/bin/java -Xshareclasses:none "-Xjit:disableTOC,verbose={compilePerformance},vlog=jit.log" -versionIn my case I got a crash in compiled code of
java/lang/ClassLoader.loadClass(Ljava/lang/String;)Ljava/lang/Class.gdb shows following backtrace:
From jit verbose log:
So frame 15 belongs to jitted code for
ClassLoader.loadClass.The last passing build with
-Xjit:disableTOCoption is:First failing build with
-Xjit:disableTOCoption is:Following commits have gone in OMR between the two builds:
and in OpenJ9:
The text was updated successfully, but these errors were encountered: