Dmitri Pivkine

Interesting, `_omrVM` is set properly. If it would not be any Indexable object allocation crash. ``` > !mm_gcextensions 0x000000013780BA20 ...... 0xf8: class GC_ArrayletObjectModel indexableObjectModel = !gc_arrayletobjectmodel 0x000000013780BB18 ...... > !gc_arrayletobjectmodel...

Looks like pointer to GC Extensions `OMR_VM->_gcOmrVMExtensions` is broken. It is set to `0x37FDD0D98`: ``` > !omr_vm 0x0000000137016870 OMR_VM at 0x137016870 { Fields for OMR_VM: 0x0: struct OMR_Runtime* _runtime =...

`OMR_VM->_gcOmrVMExtensions` is set originally (and never modified after) in `gcInitializeDefaults()` and it is the same as `j9javavm->gcExtensions`: ``` extensions->setOmrVM(vm->omrVM); vm->omrVM->_gcOmrVMExtensions = (void *)extensions; vm->gcExtensions = vm->omrVM->_gcOmrVMExtensions; ``` Looks like we...

next slot to corrupted in OMR VM does not look correct also: ``` > !omr_vmconfiguration 0x00000001370168D8 OMR_VMConfiguration at 0x1370168d8 { Fields for OMR_VMConfiguration: 0x0: U64 _maximum_thread_count = 0x000000037FDD0D50 (15030095184) }...

Both bogus values written over OMR VM slots `0x37FDD0D50` and `0x37FDD0D98` are object pointers in the heap (Nursery): ``` > !j9object 0x37FDD0D50 J9VMJavaLangString at 0x000000037FDD0D50 { struct J9Class* clazz =...

This is speculation but considering String object `!j9object 0x000000037FDD0D98` array has not been initialized yet (is object it crashed at `!j9indexableobject 0x000000037FDD0D70` intended for it?) the code doing corruption in...

raw dump of memory at OMR VM location reveals pattern - there is something looks like linked list structure is written over: ``` 0x137016870 : 0000000137016838 0000000137011a20 [ 8h.7.... ..7.......

GC Environment address has been taken from `!j9vmthread 0x138013D00`: ``` > !j9vmthread 0x138013D00 | grep gcExtensions 0x628: void* gcExtensions = !j9x 0x0000000138019068 ``` Data structure for `!j9vmthread 0x138013D00` itself looks...

just in case you missed it: `!threads` has more functionality: ``` > !threads help !threads -- list all threads in the VM !threads stack -- list stacks for all threads...

There is no system core stored in results (javacore and snap traces only), so not much I can do. One observation this test runs with 16m heap. Is it intentional?...