![]() | |||||||||||
Messages in this thread |
* Christoph Lameter <clameter@sgi.com> wrote: > +SLUB Debug output> +-----------------> +> +Here is a sample of slub debug output:> +> +*** SLUB kmalloc-8: Redzone Active@0xc90f6d20 slab 0xc528c530 offset=3360 flags=0x400000c3 inuse=61 freelist=0xc90f6d58 > + Bytes b4 0xc90f6d10: 00 00 00 00 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a ........ZZZZZZZZ > + Object 0xc90f6d20: 31 30 31 39 2e 30 30 35 1019.005 > + Redzone 0xc90f6d28: 00 cc cc cc . > +FreePointer 0xc90f6d2c -> 0xc90f6d58 > +Last alloc: get_modalias+0x61/0xf5 jiffies_ago=53 cpu=1 pid=554 > +Filler 0xc90f6d50: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ when constructing debug output it's a good idea to make it as 'context-free' as possible. I.e. instead of saying 'Filler' and explaining it somewhere in Documentation/*, just say: Expected memory values at 0xc90f6d50: 5a 5a 5a 5a 5a 5a 5a 5a ... but found the following values: 12 34 56 78 90 12 34 56 (or whatever it means) please also put in one of the keywords as the first word of whatever SLUB prints: BUG: ... WARNING: ... INFO: ... the output should be compact, but never at the price of understandability. For example i tried to make lockdep output as self-explanatory as possible - and a good portion of lockdep.c is about having around the kind of information to make the error more understandable (tracking lock-acquire stacktraces, tracking initialization points, tracking initialization-time symbol names, etc.), and there's even quite some algorithmic complexity from that. I probably spent more time on making lockdep output easier to decode than on any other sub-feature of lockdep. The output format literally went over hundreds of revisions. Output to humans is _the_ most important thing that a debug facility can do, sometimes more important than the debugging it offers ;-) And even the existing lockdep output sometimes confuses people. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||
| Last update: 2007-05-24 09:35 [from the cache] ©2003-2008 | |||||||||||