qemu-system-sparc64: entering the debugger

Mark Cave-Ayland mark.cave-ayland at ilande.co.uk
Tue Apr 12 12:51:54 UTC 2016

On 12/04/16 10:06, Mark Cave-Ayland wrote:

>> So it looks like something has already gone wrong simply trying to dump
>> the process map. Fortunately the number of QEMU translation blocks
>> between the output of the "ps/m" header and the "KDB reentering" is
>> quite small so I've uploaded it to
>> https://www.ilande.co.uk/tmp/qemu/freebsd-tb.txt.
>> Can anyone have a quick look at the link above and give me an idea as to
>> roughly what the code is doing here?

It seems that if you boot directly into ddb and use ps/m then you end up
with a NULL pointer dereference:

FreeBSD/sparc64 bootstrap loader, Revision 1.0
(mca at freebsd, Thu Sep 24 00:27:19 BST 2015)
bootpath="/pci at 1fe,0/pci-ata at 5/ide1 at 8200/cdrom at 0:a"
Loading /boot/defaults/loader.conf
/boot/kernel/kernel data=0xd893c0+0x20ffd8 syms=[0x8+0xdc578+0x8+0xcb349]
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel] in 9 seconds...

Type '?' for a list of commands, 'help' for more detailed help.
OK boot -d
jumping to kernel entry at 0xc00b0000.
GDB: no debug ports present
KDB: debugger backends: ddb
KDB: current backend: ddb
KDB: enter: Boot flags requested debugger
[ thread pid 0 tid 0 ]
Stopped at      0xc0630b00
db> ps/m
  pid  ppid  pgrp   uid   state   wmesg         wchan        cmd
    0     0     0     0KDB: reentering
KDB: stack backtrace:
 (null)() at 0xc063105c
(null)() at 0xc09e193c
(null)() at 0xc00b1078
(null)() at 0xc011bb1c

The NULL pointer reference occurs here:

0x00000000c0122008:  ldx  [ %l2 + 0x3d8 ], %g1     ! %g1 = 0
0x00000000c012200c:  ldx  [ %g1 + 0x18 ], %g1      !
0x00000000c0122010:  brz,pn   %g1, 0xc0122050
0x00000000c0122014:  nop

AFAICT the corresponding part of db_ps.c is this:

if (p->p_session != NULL && SESS_LEADER(p))
    strlcat(state, "s", sizeof(state));

Here p->p_session expands to p->p_pgrp->pg_session which gives us the
exception because p->p_pgrp is set to NULL. So I guess this is a bug,
but not the bug I'm looking for...

(Note: I know this is an oldish checkout, so maybe someone else has
already found and fixed this)



More information about the freebsd-sparc64 mailing list