On Mon, Oct 22, 2012 at 12:09:08AM +0200, Mateusz Guzik wrote: > ... > This looks a lot like issue you reported a couple of months earlier, > even affected buffer address matches.
It's a tad scary that someone else notices that sort of thing before I do. :-} > At least part of REDZONE metadata placed directly before the buffer is > corrupted. So the idea is to set a watchpoint at a place that is known > to contain wrong data (in this case allocation size) and wait for some > code to try to modify it. > > I hacked up the following (really ugly, but should do the job): > http://people.freebsd.org/~mjg/patches/watchpoint-hack.diff > > Note: this assumes that address of affected buffer is always the same. > > Assuming I didn't mess anything up, instructions are simple: > Just try to reproduce the issue, at some point you should be dropped to > the debugger. If that happens when dumpdevice is configured, please get a > core. Otherwise just a backtrace ("bt" command). Well, the problem was occurring (only, and reproducibly) during the transition from single-user mode to multi-user mode. Perhaps more frustrating: after building & installing the kernel with that patch, apparently locations of things were adjusted in such a way that the panic did not recur. > Note 2: this code does no clear the watchpoint, so if it fails to catch > the offending case, it may catch completely legitimate code later. Fun! :-) Thanks! Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key.
pgpLWdcQNyFpa.pgp
Description: PGP signature
