On Thu, 2007-03-29 at 08:13 -0500, Dave Anderson wrote: > Ken'ichi Ohmichi wrote: > > I checked whether this change is correct by the following: > > (The following patches are attached with this mail) > > - makedumpfile-1.1.2 with "point_same_zero_page2.patch" creates a dumpfile. > > - crash-4.0-3.21 with "not-access-excluded-page.patch" analyzes the dumpfile. > > - The analysis result of the dumpfile is compared with /proc/vmcore's. > > > > And on i386 linux-2.6.19, I found the difference between the result > > of the dumpfile (excluding free pages) and /proc/vmcore's by subcommand > > "foreach bt". > > But by using crash-4.0-3.21 without "not-access-excluded-page.patch", > > there is not any difference. In a word, this difference happens due to > > considering the excluded pages as unaccess pages. Just to clarify for those who probably aren't as confused as I was at first: This isn't a test of the zero page trick, because with the changes to makedumpfile, zero pages are no longer actually excluded. (I read "excluding free pages" but immediately thought "excluding zero pages" and spent more than a few minutes checking how that could possibly have happened.) So this is apparently a case where a page excluded because it was supposedly free is then maybe accessed by the back tracer while it might be trying to read kernel text, right? But kernel text should never look free, so I'm still puzzled. Did makedumpfile mis-identify a real page as free, or is crash asking for pages it shouldn't be looking at during backtrace? Anyway, with my test dump on my x86_64 box, I don't get a case where dumpfiles with excluded free pages produce different "foreach bt" output than I get from the vmcore file. I tried -d16 and -d31 options. I do get the expected excluded page message when I x/xg an excluded address, just no problems with bt. So I can't help Dave with an example. Bob Montgomery -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
