Date: Sat, 29 Aug 2020 11:04:53 -0600 From: Ian Lepore <ian@freebsd.org> To: Warner Losh <imp@bsdimp.com>, meloun.michal@gmail.com Cc: Mateusz Guzik <mjguzik@gmail.com>, Warner Losh <imp@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all <svn-src-all@freebsd.org>, svn-src-head <svn-src-head@freebsd.org> Subject: Re: svn commit: r364946 - head/sys/kern Message-ID: <0799731356a4ccffedf3ac10048611bec72f7eba.camel@freebsd.org> In-Reply-To: <CANCZdfp9m7knXfguYh79fdALBiL3ktEH6e=NU4S2qdOv6ory%2Bg@mail.gmail.com> References: <202008290430.07T4UCM4007928@repo.freebsd.org> <CAGudoHFAkrAykin6ngH=04254J4AmhHk2NmDyGfrUE=wJcxH2A@mail.gmail.com> <CANCZdfqXtKhKhh33ovFQ4_a3tiesRi8-6ZuMTp0yW%2BMzkxWLzA@mail.gmail.com> <f1a67850-e9e5-d785-6562-972aeb9f1206@gmail.com> <CANCZdfp9m7knXfguYh79fdALBiL3ktEH6e=NU4S2qdOv6ory%2Bg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 2020-08-29 at 05:02 -0600, Warner Losh wrote: > > > > sbuf_cpy() at _gone_in_dev+0x560 > > pc = 0xffff0000003c1ff0 lr = 0xffff0000003a9078 > > sp = 0xffff00006f21a510 fp = 0xffff00006f21a570 > > > > _gone_in_dev() at sbuf_new_for_sysctl+0x170 > > pc = 0xffff0000003a9078 lr = 0xffff00000037c1a8 > > sp = 0xffff00006f21a580 fp = 0xffff00006f21a5a0 > > > > sbuf_new_for_sysctl() at kernel_sysctl+0x36c > > pc = 0xffff00000037c1a8 lr = 0xffff00000037b63c > > sp = 0xffff00006f21a5b0 fp = 0xffff00006f21a630 > > > > This traceback is all kinds of crazy. sbuf_new_for_sysctl doesn't call > _gone_in_dev(), which doesn't do sbuf stuff at all. And neither does it > call sbuf_cpy(). Though I get a crash that looks like: > Tracing pid 66442 tid 101464 td 0xfffffe02f47b7c00 > kdb_enter() at kdb_enter+0x37/frame 0xfffffe02f4ae3740 > vpanic() at vpanic+0x19e/frame 0xfffffe02f4ae3790 > panic() at panic+0x43/frame 0xfffffe02f4ae37f0 > sbuf_clear() at sbuf_clear+0xac/frame 0xfffffe02f4ae3800 > sbuf_cpy() at sbuf_cpy+0x5a/frame 0xfffffe02f4ae3820 > device_sysctl_handler() at device_sysctl_handler+0x133/frame > 0xfffffe02f4ae38a0 > sysctl_root_handler_locked() at sysctl_root_handler_locked+0x9c/frame > 0xfffffe02f4ae38f0 > sysctl_root() at sysctl_root+0x20a/frame 0xfffffe02f4ae3970 > userland_sysctl() at userland_sysctl+0x17d/frame 0xfffffe02f4ae3a20 > sys___sysctl() at sys___sysctl+0x5f/frame 0xfffffe02f4ae3ad0 > amd64_syscall() at amd64_syscall+0x140/frame 0xfffffe02f4ae3bf0 > fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe02f4ae3bf0 > --- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x80042d50a, rsp = > 0x7fffffffd458, rbp = 0x7fffffffd490 --- > > on a sysctl -a which I think makes more sense... I'll see if I can track > it down... I think it's because sbuf_cpy does an unconditional clear, which > triggers this assert, which is likely bogus for this case. sbuf_cat doesn't > seem to have this issue... I'll confirm and commit. > > Warner This kind of crazy happens when the traceback just reports the name of the nearest global symbol it can find because static or other local symbols aren't available to it. The clue that that's what's going on tends to be in things like: sbuf_cpy() at _gone_in_dev+0x560 It's almost certain that _gone_in_dev() isn't a big enough function that an offset of 0x560 is still in that function, so it's really in some static function that got linked nearby but the symbols for statics got stripped. Usually you can use addr2line on kernel.full to get the real names for the pc and lr values. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0799731356a4ccffedf3ac10048611bec72f7eba.camel>