On Thu, 11 Aug 2005, Peter Hagervall wrote:
>
> I think I have it narrowed down a bit now, it seems that
> ac8ce3636d83e25d8a316fdce221e36c04c02dc1 is OK, whereas its child,
> 972609f0d10e3bcb10a9132802b2edb8b01d305f is not.
Well, that's just the commit that enables the "anal debugging allocation
code". The bug was there before, it was just hidden.
The debugging mode changes the blob_free() function from doing an
"munmap()" to just doing a "mprotect(PROT_NONE)". The reason that is good
for debugging is that if you do an unmap, the next allocation will likely
be taken from the hole that we just unmapped, so any subsequent accesses
through a wild pointer will be "successful" - they'll just access the
wrong thing.
In contrast, a "mprotect(PROT_NONE)" means that new allocations will be
taken from somewhere else in the VM area and yet if you use "gdb" when a
fault happens, you can see what the data structure it _tried_ to access
contained, which is wonderfully powerful (ie let's say that it's a "struct
token" that got free'd too early and accessed after it was freed - you can
see exactly _which_ token it was.
So that DEBUG addition just means that some old bugs that used to be
impossible to find are now much more likely to cause SIGSEGV's and be
debuggable.
> valgrind still complains about invalid reads in clean_up_insns, but at
> least it doesn't segfault.
Well, as mentioned, that commit isn't the buggy one..
It might be interesting to try to "port" that commit downwards, and see
when it starts triggering, but that's potentially a lot of work. It's
probably best to look at what free'd that memory area in the first place,
and valgrind can probably help.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
