Comment 4 for bug 1856837

At the point of the segfault, QEMU is correctly delivering a segfault to the guest because it has attempted to dereference a NULL pointer. You can see this if you run QEMU with the '-g 1234' option and connect an arm-aware gdb to it:

(gdb) disas $pc-32,$pc+32
Dump of assembler code from 0x2bf24c to 0x2bf28c:
   0x002bf24c: ldr r4, [r0, #296] ; 0x128
   0x002bf250: mov r6, r1
   0x002bf254: add r8, r0, #40 ; 0x28
   0x002bf258: mov r5, #0
   0x002bf25c: b 0x2bf268
   0x002bf260: cmp r5, r6
   0x002bf264: bge 0x2bf2d4
   0x002bf268: mov r12, r4
=> 0x002bf26c: ldr r4, [r4]
   0x002bf270: ldr r3, [r12, #12]
   0x002bf274: tst r3, #512 ; 0x200
   0x002bf278: bne 0x2bf2c0
   0x002bf27c: tst r3, #1024 ; 0x400
   0x002bf280: ubfx r1, r3, #11, #1
   0x002bf284: bne 0x2bf2c0
   0x002bf288: tst r3, #2048 ; 0x800
End of assembler dump.
(gdb) print /x $r4
$3 = 0x0

It looks like this is in the middle of somebody's garbage collector (the elf symbol is _ZN2v88internal10PagedSpace14AdvanceSweeperEi).

The next step would be to find out what was going on in the run-up to that that resulted in the NULL pointer. That's a bit of guest-level debugging work that would be much easier with the source code. If you can debug where something unexpected happens to the guest that would probably help -- this is likely to be a much longer piece of debugging than I'm afraid I have time to do.