Date: Tue, 08 Dec 2015 09:54:53 -0800 From: John Baldwin <jhb@freebsd.org> To: Don Lewis <truckman@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: panic: sbuf_vprintf called with a NULL sbuf pointer Message-ID: <2133429.08nAJynLee@ralph.baldwin.cx> In-Reply-To: <201512080610.tB86Apx0000899@gw.catspoiler.org> References: <201512080610.tB86Apx0000899@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, December 07, 2015 10:10:51 PM Don Lewis wrote: > On 2 Dec, John Baldwin wrote: > > On Wednesday, December 02, 2015 01:25:56 PM Don Lewis wrote: > >> > If you want to look at this further, try going to frame 16 and dissassembling the > >> > instructions before the call to see if you can spot which register the first > >> > parameter (saved in %rdi IIRC) comes from. > >> > >> Dump of assembler code for function sbuf_printf: > >> 0xffffffff80a673e0 <+0>: push %rbp > >> 0xffffffff80a673e1 <+1>: mov %rsp,%rbp > >> 0xffffffff80a673e4 <+4>: push %r14 > >> 0xffffffff80a673e6 <+6>: push %rbx > >> 0xffffffff80a673e7 <+7>: sub $0x50,%rsp > >> 0xffffffff80a673eb <+11>: mov %rsi,%r14 > >> 0xffffffff80a673ee <+14>: mov %rdi,%rbx > >> 0xffffffff80a673f1 <+17>: mov %r9,-0x38(%rbp) > >> 0xffffffff80a673f5 <+21>: mov %r8,-0x40(%rbp) > >> 0xffffffff80a673f9 <+25>: mov %rcx,-0x48(%rbp) > >> 0xffffffff80a673fd <+29>: mov %rdx,-0x50(%rbp) > >> 0xffffffff80a67401 <+33>: lea -0x60(%rbp),%rax > >> 0xffffffff80a67405 <+37>: mov %rax,-0x20(%rbp) > >> 0xffffffff80a67409 <+41>: lea 0x10(%rbp),%rax > >> 0xffffffff80a6740d <+45>: mov %rax,-0x28(%rbp) > >> 0xffffffff80a67411 <+49>: movl $0x30,-0x2c(%rbp) > >> 0xffffffff80a67418 <+56>: movl $0x10,-0x30(%rbp) > >> 0xffffffff80a6741f <+63>: mov $0xffffffff8137bdf8,%rdi > >> 0xffffffff80a67426 <+70>: mov %rbx,%rsi > >> 0xffffffff80a67429 <+73>: callq 0xffffffff80a66c00 <_assert_sbuf_integrity> > >> > >> > >> 0xffffffff80a237b9 <+825>: jmpq 0xffffffff80a236fd <sigexit+637> > >> 0xffffffff80a237be <+830>: mov $0xffffffff80fd8ad3,%rsi > >> 0xffffffff80a237c5 <+837>: xor %eax,%eax > >> 0xffffffff80a237c7 <+839>: mov %r12,%rdi > >> 0xffffffff80a237ca <+842>: mov -0x228(%rbp),%rdx > >> 0xffffffff80a237d1 <+849>: callq 0xffffffff80a673e0 <sbuf_printf> > >> => 0xffffffff80a237d6 <+854>: inc %r14d > >> 0xffffffff80a237d9 <+857>: jmpq 0xffffffff80a236fd <sigexit+637> > > > > So maybe try 'p $r12' in the corefile_open() frame. > > #17 0xffffffff80a237d6 in corefile_open (compress=0, comm=<optimized out>, > uid=<optimized out>, pid=<optimized out>, td=<optimized out>, > vpp=<optimized out>, namep=<optimized out>) > at /usr/src/sys/kern/kern_sig.c:3188 > 3188 sbuf_printf(&sb, "%s", comm); > (kgdb) p $r12 > $1 = 0 So it's definitely zero. :( The next step is probably to disassemble the corefile_open function (ugh) and walk backwards to find where %r12 is read from. It might be from a local variable on the stack, so then you would want to examine that memory in the stack and the surrounding memory to see if there is memory corruption and perhaps if there is anything recognizable about it (e.g. if the corruption contains some sort of data you recognize, or if the corruption is bounded by a certain length, etc.). It's a bit of a shot in the dark though. Is this reproducible? -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2133429.08nAJynLee>