* Christoph Lameter <[EMAIL PROTECTED]> wrote:
> +SLUB Debug output
> +-----------------
> +
> +Here is a sample of slub debug output:
> +
> +*** SLUB kmalloc-8: Redzone [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
