Re: 2.6.0-test8-mm1

[Valdis.Kletnieks@vt.edu]

[-- Attachment #1: Type: text/plain, Size: 1225 bytes --]

On Tue, 21 Oct 2003 19:27:25 EDT, Robert Love said:
> On Tue, 2003-10-21 at 18:53, Thomas Schlichter wrote:
> 
> > For me the big question stays why enabling the DEBUG_* options results in a
 
> > corrupt cursor and the false dots on the top of each row... (with both 
> > kernels)
> 
> Almost certainly due to CONFIG_DEBUG_SLAB or CONFIG_DEBUG_PAGEALLOC,
> which debug memory allocations and frees.
> 
> Code that commits the usual memory bugs (use-after-free, etc.) will
> quickly die with these set, whereas without them the bug might never
> manifest.

Right.  DEBUG_SLAB and DEBUG_PAGEALLOC will change where things end up in
memory.  The part that *I* was surprised at was that turning them on did *NOT*
make the code quickly die as expected - but it *did* corrupt the on-screen
image.  That's telling me that the DEBUG stuff is setting canaries that end up
in memory locations that the fbdev code thinks are destined for the display
pixels.  (And conversely, that when you build without those two debug options,
that the fbdev code is parking those now not visibly corrupted pixels on top of
somebody's pointer chains and that's where the memory corruption is coming
from.

Or I could just be full of it as usual.. :)

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]