----- "Mike Snitzer" <snitzer@xxxxxxxxx> wrote: > On Thu, Oct 16, 2008 at 1:16 PM, Dave Anderson <anderson@xxxxxxxxxx> > wrote: > > > > ----- "Dave Anderson" <anderson@xxxxxxxxxx> 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 -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility