Messages in this thread | | | Subject | Re: 2.6.0-test8-mm1 | From | Valdis.Kletnieks@vt ... | Date | Tue, 21 Oct 2003 22:46:50 -0400 |
| |
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.. :) [unhandled content-type:application/pgp-signature] | |