Open pshipton opened 7 months ago
@hzongaro fyi
@mpirvu : can you assign for investigation please?
@mpirvu I can take a look at this since I was the one to refactor all that code.
Registers:
gpr0=10200000 gpr1=3D0657AC gpr2=00000020 gpr3=00000000
gpr4=41F5D220 gpr5=1A2358B8 gpr6=000A0000 gpr7=9A68A9BA
gpr8=1BE1F760 gpr9=41F5DBC8 gpr10=00000000 gpr11=1BE98E5C
gpr12=41DBD708 gpr13=1A68B770 gpr14=41F5DE86 gpr15=3D9D3DB0
hgpr0=0000F71F hgpr1=00000000 hgpr2=00000000 hgpr3=00000000
hgpr4=000063F2 hgpr5=00000000 hgpr6=00000000 hgpr7=00000000
hgpr8=000063F2 hgpr9=0000FFFF hgpr10=00000005 hgpr11=00000000
hgpr12=00000000 hgpr13=00000000 hgpr14=00000000 hgpr15=00000000
fpc=0008fe00 psw0=078D3400 psw1=9A68A9CA sp=41F5D220
bea=1A824864
The crash happens at 0x1a68a9ca
0x1a68a9c2 {libj9jit29.so}{J9::CompilationStrategy::ProcessJittedSample::process()} +722 58609024 L GPR6,0x24(,GPR9)
0x1a68a9c6 {libj9jit29.so}{J9::CompilationStrategy::ProcessJittedSample::process()} +726 58606000 L GPR6,0x0(,GPR6)
0x1a68a9ca {libj9jit29.so}{J9::CompilationStrategy::ProcessJittedSample::process()} +730 5800600C L GPR0,0xC(,GPR6)
Essentially, gpr9
is the this
pointer of the J9::CompilationStrategy::ProcessJittedSample
class, and GPR6,0x24(,GPR9)
is doing this->_methodInfo
which is NULL:
> x/50x 0x41F5DBC8
0x41f5dbc8: 19adf520 // _jitConfig // +0x0
0x41f5dbcc: 418ea100 // _vmThread // +0x4
0x41f5dbd0: 19ae0720 // _compInfo // +0x8
0x41f5dbd4: 40e63e20 // _fe // +0xC
0x41f5dbd8: 3d2064b8 // _cmdLineOptions // +0x10
0x41f5dbdc: 3d9d3db0 // _j9method // +0x14
0x41f5dbe0: 41f5dea8 // _event // +0x18
0x41f5dbe4: 3f0a5af8 // _startPC // +0x1C
0x41f5dbe8: 3eb77408 // _bodyInfo // +0x20
0x41f5dbec: 00000000 // _methodInfo // +0x24
0x41f5dbf0: 00000020
0x41f5dbf4: 418ea7bc
0x41f5dbf8: 1a2105a8
0x41f5dbfc: 1a4a4920
0x41f5dc00: 41dbd708
0x41f5dc04: 1a4a6f2c
0x41f5dc08: 00000000
0x41f5dc0c: 19fe949c
0x41f5dc10: 19b46d20
0x41f5dc14: 00000001
The method in question is
(kca) m 0x3f0a5af8
Method Signature: {java/lang/StringBuilder.append(I)Ljava/lang/StringBuilder;}
MetaData: 0x3d7fa188 (optLevel: warm)
Frame Size: 60 bytes
Access: Public
J9Class/J9Method: 0x3d9d4800 / 0x3d9d3db0
MethodInfo: 0x00000000
BodyInfo: 0x3eb77408
Compiled Method Start/End: 0x3f0a5a24 / 0x3f0a5cfc (728 bytes)
Cold Code Start/End: 0x00000000 / 0x00000000 (0 bytes)
Method {ClassPath/Name.MethodName}: {java/lang/StringBuilder.append}
Signature: (I)Ljava/lang/StringBuilder;
Access: Public
J9Class/J9Method: 0x3d9d4800 / 0x3d9d3db0
Compiled Method Start: 0x3f0a5af8 (728 bytes)
ByteCode Start: 0x3d9e0abc (139 bytes)
ROM Constant Pool: 0x3d9dfc50 (144 entries)
Constant Pool: 0x3d9d4180 (1 entries)
The first few fields of the TR_PersistentJittedBodyInfo
is
private:
int32_t _counter; // must be at offset 0
TR_PersistentMethodInfo *_methodInfo; // must be at offset 4 (8 for 64bit)
void *_startPCAfterPreviousCompile;
void *_mapTable; // must be at offset 12 (24 for 64bit)
which maps to
(kca) x/4x 0x3eb77408
0x3eb77408: 1cb3a398 00000000 00000000 1cd73028
The body info pointer is the same in the exception table:
(kca) struct J9JITExceptionTable.bodyInfo 0x3d7fa188
J9JITExceptionTable (116 bytes)
void * bodyInfo = 0x3eb77408 (offset: 72)
as well as in the code
(kca) x/x 0x3f0a5af8-8
0x3f0a5af0: 3eb77408
However, from all indication, the bodyInfo looks corrupted. I also can't find the methodInfo anywhere in the Internal Memory segments, so it leads me to believe that this memory got overwritten somehow.
The JVM wasn't using AOT so there wasn't any relocation issue, and as far as I can tell, there's no redefinition happening. Also class unloading couldn't be a factor as java/lang/StringBuilder.append
is on the stack.
I don't really have any theories as to what is going on except for may be memory corruption or an erroneous free.
Internal build [zOS S390] 80 Load_Level_2.abbs.5mins.Mode121
-Xgcpolicy:optavgpause -Xjit:count=0 -Xnocompressedrefs
- fyrec607130x grinder - passed