Date: Tue, 12 Apr 2016 13:51:14 +0100 From: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> To: "freebsd-sparc64@freebsd.org" <freebsd-sparc64@freebsd.org> Subject: Re: qemu-system-sparc64: entering the debugger Message-ID: <570CEF42.9050400@ilande.co.uk> In-Reply-To: <570CBA7E.2080509@ilande.co.uk> References: <570CAFD6.2010004@ilande.co.uk> <570CBA7E.2080509@ilande.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd, Thu Sep 24 00:27:19 BST 2015) bootpath="/pci@1fe,0/pci-ata@5/ide1@8200/cdrom@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 Booting... 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) ATB, Mark.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?570CEF42.9050400>