[Crash-utility] kmem -[sS] segfault on 2.6.25.17

[Dave Anderson]

----- "Mike Snitzer" <snitzer at gmail.com> wrote:

> On Thu, Oct 16, 2008 at 1:16 PM, Dave Anderson <anderson at redhat.com>
> wrote:
> >
> > ----- "Dave Anderson" <anderson at redhat.com> wrote:
> >> Ok, then I can't see off-hand why it would segfault.  Prior to
> this
> >> routine running, si->cpudata[0...i] all get allocated buffers
> equal
> >> to the size that's being BZERO'd.
> >>
> >> Is si->cpudata[i] NULL or something?
> 
> (gdb) p si->cpudata
> $1 = {0xa56400, 0xa56800, 0xa56c00, 0xa57000, 0x0 <repeats 252
> times>}
> (gdb) p si->cpudata[0]
> $4 = (ulong *) 0xa56400

OK, so if "i" is 0 at the time, then I don't understand how the
BZERO/memset can segfault while zero'ing out memory starting at
address 0xa56400?  

    BZERO(si->cpudata[i], sizeof(ulong) * vt->kmem_max_limit);

Even if it over-ran the 0x400 bytes that's been allocated to
si->cpuinfo[0], it would still harmlessly run into the buffer
that was allocated for si->cpuinfo[1].  What's the bad address
it's faulting on?  

And for sanity's sake, what is the crash utility's vm_table.kmem_max_limit
equal to, and what architecture are you running on?

> 
> > Also, can you confirm that you are always using the exact vmlinux
> > that is associated with each vmcore/live-system?  I mean you're
> > not using a System.map command line argument, right?
> 
> Yes, I'm using the exact vmlinux.  Not using any arguments for live
> crash; I am for the vmcore runs but that seems needed given crash's
> [mapfile] [namelist] [dumpfile] argument parsing.
> 
> I use a redhat-style kernel rpm build process (with a more advanced
> kernel .spec file); so I have debuginfo packages to match all my
> kernels.

OK cool -- so you know what you're doing.  ;-)

BTW, if need be, would you be able to make the vmlinux/vmcore pair
available for download somewhere?  (You can contact me off-list with
the particulars...)

Dave