On Tue, 09 Jan 2007 11:02:35 PST, Amit Choudhary said: > Correct. And doing kfree(x); x=NULL; is not hiding that. These issues can still be debugged by > using the slab debugging options. One other benefit of doing this is that if someone tries to > access the same memory again using the variable 'x', then he will get an immediate crash. And the > problem can be solved immediately, without using the slab debugging options. I do not yet > understand how doing this hides the bugs, obfuscates the code, etc. because I haven't seen an > example yet, but only blanket statements. char *broken() { char *x, *y; x = kmalloc(100); y = x; kfree(x); x = NULL; return y; } Setting x to NULL doesn't do anything to fix the *real* bug here, because the problematic reference is held in y, not x. So you never get a crash because somebody dereferences x.
Attachment:
pgpzVEc7wnwDh.pgp
Description: PGP signature
- Follow-Ups:
- Re: [PATCH] include/linux/slab.h: new KFREE() macro.
- From: Amit Choudhary <[email protected]>
- Re: [PATCH] include/linux/slab.h: new KFREE() macro.
- References:
- Re: [PATCH] include/linux/slab.h: new KFREE() macro.
- From: Amit Choudhary <[email protected]>
- Re: [PATCH] include/linux/slab.h: new KFREE() macro.
- Prev by Date: Re: [2.6 patch] x86_64: re-add a newline to RESTORE_CONTEXT
- Next by Date: Re: [Patch 0/2] driver core: device_move() fallout.
- Previous by thread: Re: [PATCH] include/linux/slab.h: new KFREE() macro.
- Next by thread: Re: [PATCH] include/linux/slab.h: new KFREE() macro.
- Index(es):