How to get better debugging for the kernel.

[Zaphod Beeblebrox]

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 at freebsd.org> wrote:

> On Wed, Aug 3, 2016 at 12:53 PM, Andriy Gapon <avg at 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 at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>