Debug info frame size changes are not being recorded and processed correctly #2624
Comments
|
@YaSuenag this is the problem that was causing the bad frame in the gdb crash backtrace for libpolygot.so. I have a patch which I am currently testing. |
|
Thanks a lot @adinn !! I wonder why frame # 4 did not point PolyglotNativeAPI.java . I guess the cause is it is called via |
|
Hi @YaSuenag
The compiled method which is being listed here is attached to class IsolateEnterStub. It doesn't strictly have a source file because it is a native (C) linkage stub method that is generated by Graal. Looking at the compiled code I can see that somewhere in the middle of the method it executes this call This corresponds to offset 0x79236a in the text section. The line number info for that offset identifies file PolyglotNativeAPI.java line 260. So, if you were to break that line or step into it the debugger should show the correct file and line. In other words the source code you want to point to has been inlined into this method and the debugger will find it when executing the inlined instructions. But for the entry instruction address there is not really any sensible source code to point the debugger at. |
|
Thanks for clarification! |
|
Fixed by #2625 |
The compiler adds frame-event marks to a compilation result at 6 distinct points: prologue entry, prologue stack grow, prologue exit, epilogue entry, epilogue stack shrink and epilogue exit. These events are passed on to debug info generation code as frame change events. There is an error in the generation of events and an error in the way they are converted to frame change events.
The compiler currently marks epilogue end events at the point where the frame has been torn down i.e. the same point as the epilogue stack shrink. This is incorrect because the epilogue should included all code up to and including any ensuing return (or, in special cases, up to a block end via a branch out of the method). The range of code up to that final transfer of control at epilogue exit needs to be marked as having an empty stack. Furthermore, the epilogue exit mark is needed in order to identify that subsequent code generated in the method -- code which can only be reached via a jump past the epilogue -- should be understood as having a non-empty stack i.e. the epilogue exit mark serves to re-establish the presence of a stack frame for that next segment of generated method code.
The debug info frame size change notifications notify the initial frame growth during the prologue and notfiy a frame shrink during each epilogue. However, they do not re-notify stack growth for generated method code that follows an epilogue exit. Clearly, doing so wihtout a remedy for the previous error is not possible since the point at which the epilogue exit is generated cannot currently be used to decide if the epilogue is actually at the end of a method.
How to reproduce:
Build libpolgloty.so with debug info enabled as per instructions in issue #2587
build and run a.out as per instructions in issue #2587
Debug the core in gdb as per instructions in issue #2587
Observe the following stack trace
(gdb) bt
#0 com.oracle.svm.core.jdk.VMErrorSubstitutions::doShutdown(java.lang.String, java.lang.Throwable)(void) () at com/oracle/svm/core/log/RealLog.java:385
#1 0x00007f78baf03879 in com.oracle.svm.core.util.VMError::shouldNotReachHere(java.lang.String, java.lang.Throwable)(void) () at com/oracle/svm/core/threadlocal/FastThreadLocalInt.java:51
#2 0x00007f78baf0380c in com.oracle.svm.core.util.VMError::guarantee(boolean, java.lang.String)(void) () at com/oracle/svm/core/util/VMError.java:88
#3 0x0000000000000000 in ?? ()
(gdb) p/x $rsp
Use objdump to dump info and frame sections so that code addresses and frame sizes can be identified
The problem is that the frame for VMError::guarantee is size 16 but is treated as size 8 at address 0x00007f78baf0380c:
The code address 0x7ffe698a9c70 in VMError::guarantee is in code generated after a retq arrived at by jumping around the block containing the retq
n.b. Problem 1 manifests here with the epilogue stack shrink and epilogue exit both currently generated at 0x7f78baf03800. The epilogue exit should be generated at 0x7f78baf03801.
n.b. Problem 2 manifests here with class DebugCodeInfo posting only a CONTRACT FrameSizeChange at 0x7f78baf03800 shrinking the stack sizeto 8. It should post an EXPAND FrameSizeChange event at 0x7f78baf03801 restoring the stack size to 16.
Describe GraalVM and your environment:
The text was updated successfully, but these errors were encountered: