----- "Mike Snitzer" <snitzer(a)gmail.com&gt; wrote: No, that's the text address in memset(). If you "disass memset", I believe that you'll see that the address above is dereferencing the rcx register/pointer. So then, if you enter "info registers", you'll get a register dump, and rcx would be the failing address. (To reproduce this, I inserted a "0xdeadbeef" into si->cpuinfo[0] and saw the 0xdeadbeef in rcx with "info registers") Or you can always just put an "fprintf(fp, "...")" debug statement in that function to display the address its BZERO'ing. Could get a little verbose... OK, so that all looks normal... Not necessarily... Are those warnings happening on *every* slab type? When you run on a live system, the "shifting sands" of the kernel underneath the crash utility can cause errors like the above. But at least some/most of the other slabs' infrastructure should remain stable while the command runs. When you run it on the vmcore, do you get the segfault immediately? Or do some slabs display their stats OK, but then when it deals with one particular slab it generates the segfault? I mean that it's possible that the target slab was in transition at the time of the crash, in which case you might see some error messages like you see on the live system. But it is difficult to explain why it's dying specifically where it is, even if the slab was in transition. That all being said, even if the slab was in transition, obviously the crash utility should be able to handle it more gracefully... FYI, I did try our RHEL5 "debug" kernel (2.6.18 + hellofalotofpatches), which has both CONFIG_DEBUG_SLAB and CONFIG_DEBUG_SLAB_LEAK turned on, but I don't see the problem. So unless something obvious can be determined, that may be the only way I can help. Dave