[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BANLkTikLBv1bzohbG7e+M47xJ_fDuES=9Q@mail.gmail.com>
Date: Sun, 10 Apr 2011 17:28:45 -0400
From: Bob Copeland <me@...copeland.com>
To: Rafał Miłecki <zajec5@...il.com>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Andy Botting <andy@...ybotting.com>
Subject: Re: Crash with kfree(null) on MacBook? kobject_set_name_vargs
2011/4/10 Rafał Miłecki <zajec5@...il.com>:
> I'm writing new axi bus driver and one of the early testers reported
> it crashing for him. Andy is using MacBook and backtrace+debugging
> pretty clearly point to kfree being called on null string.
> bcopeland on #linux-wireless suggested turning on SLAB or SLUB. Is
> this going to provide some interesting info?
To be precise, I said slab or slub _debugging_. The reason I said
this is that often a crash on kfree() is due to memory corruption.
Many places in the kernel rely on kfree(NULL) being a safe operation,
so it's likely something more than that. SL?B debugging adds
poisoning and corresponding checks that detect several kinds of
corruption like buffer overruns, use-after-free, etc.
The other thing you can do is get the disassembly of the Code portion
for your oops and match it up with specific C code, look at the
register file in the oops and match that up with variable names, and
work backwards to figure out which pointers are broken. Sometimes
this can be enlightening, like if a pointer has ascii values, or is a
small number (0 + some struct offset).
--
Bob Copeland %% www.bobcopeland.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists