Date: Thu, 4 Aug 2016 07:13:36 -0400 From: Zaphod Beeblebrox <zbeeble@gmail.com> To: "K. Macy" <kmacy@freebsd.org> Cc: Andriy Gapon <avg@freebsd.org>, Samy Bahra <sbahra@backtrace.io>, FreeBSD Hackers <freebsd-hackers@freebsd.org>, Ryan Stone <rysto32@gmail.com> Subject: Re: How to get better debugging for the kernel. Message-ID: <CACpH0MdNtuQu0V6rxwucx0C4D2Ew5aBasg2E%2BbD77BHq7HnP3A@mail.gmail.com> In-Reply-To: <CAHM0Q_OHE%2Bj1TfnYfJ7w1v7MpbRTcwE7mQnpnyY=GG%2BDHzwETg@mail.gmail.com> References: <CACpH0Mcw1oTatUX3d7gJ4ys=dAj_y9C9vF_g110MrHVEup4mjQ@mail.gmail.com> <CAFMmRNwLeEtEetQ-CZkyCC7rL-724GWEL6JF4pWAocTyC1Cu3w@mail.gmail.com> <5cc825d5-9ed7-efac-b711-60a8d4b18cc4@FreeBSD.org> <CAHM0Q_OHE%2Bj1TfnYfJ7w1v7MpbRTcwE7mQnpnyY=GG%2BDHzwETg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Thanks for the tips. So far, (and this is in diagnosing bug 211535), I've managed to compile the kernel with -O0. Someone on #FreeBSD told me to do it with "CFLAGS=-g -O0 make" ... which seems to have worked. At the very least, I have managed to find a frame on the stack that told me where in the filesystem was triggering the problem. Turns out that icinga2 (a monitoring package) manages to create a directory of 530k small files. It renames() two files each minute into the directory. At 530k files, this panic's the kernel every 12h or so. At lower levels of files, it panic's the kernel less. I have not setup a test system at home to try to induce this ... and if shutting off icinga2 fixes this (or shutting off the statistics module), then I'm loathe to keep the production server as a guinea pig, but I do have dumps for people to look at if they're interested. On Thu, Aug 4, 2016 at 4:07 AM, K. Macy <kmacy@freebsd.org> wrote: > On Wed, Aug 3, 2016 at 12:53 PM, Andriy Gapon <avg@freebsd.org> wrote: > > On 03/08/2016 20:14, Ryan Stone wrote: > >> Are you using the kgdb from the base system or from ports(it's a part of > >> devel/gdb)? The kgdb in ports is significantly better. If you haven't > >> tried the version from ports already, definitely do that first. > > > > kgdb 7.x from ports is certainly more powerful than the old base kgdb, > > but clang with O2 optimizations seems to be too much even for it. > > Samy did a good presentation about this issue. I'm hoping I can get > him to put his slides on line. Evidently clang is much more simplistic > about how it treats callee saved registers. In essence clang will > always err on the side of saying "optimized out" even when it has > sufficient state to know otherwise. Gcc, on the other hand will > sometimes incorrectly infer that a value is valid when it is in fact > not. > > I have been building some kernels with clang with dwarf4 enabled (and > thus needed to use kgdb 7.x from ports). Contrary to what I have heard > from some others I have found it to have virtually no added benefit. > > There is evidently some mechanism for appending an epilogue to > functions. This would allow us to conditionally force clang to treat > all function argument as being live to the end of the function. > > -M > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACpH0MdNtuQu0V6rxwucx0C4D2Ew5aBasg2E%2BbD77BHq7HnP3A>