Re: [Crash-utility] kmem -[sS] segfault on 2.6.25.17
----- "Mike Snitzer" <snitzer(a)gmail.com> wrote:
On Thu, Oct 16, 2008 at 12:25 PM, Dave Anderson
<anderson(a)redhat.com>
wrote:
>
> ----- "Mike Snitzer" <snitzer(a)gmail.com> wrote:
>
>> I'm getting a core when I try to show slab data (kmem -[sS]) on
>> 2.6.25.17 with both a live crash or saved vmcore.
>>
>> The core shows that the segv is coming from memset() via
>> gather_cpudata_list_v2_nodes (memory.c:10119). This is with crash
>> 4.0-7.4, but the same crash occurs with crash 4.0-6.3
>> (memory.c:10108)
>> and older.
>>
>> I've also seen kmem -[sS] segfaults with older kernels too (e.g.
>> 2.6.22.x).
>>
>> Have others experienced this? Would it be useful for me to
provide
>> my
>> kernel config?
>
> No that won't help.
Actually I think it may considering kmem -[sS] works perfectly fine
on
the same identical 2.6.22.19 kernel if various debug features are
_not_ enabled, see the attached .config diff. Of note:
-# CONFIG_DEBUG_SLAB is not set
+CONFIG_DEBUG_SLAB=y
+CONFIG_DEBUG_SLAB_LEAK=y
Comparable debug features are enabled in my 2.6.25 kernel that causes
crash to segfault.
Good point...
> It's failing in the BZERO() here:
>
> 10117 for (i = 0; (i < ARRAY_LENGTH(kmem_cache_s_array))
&&
> 10118 (cpudata[i]) && !(index); i++) {
> 10119 BZERO(si->cpudata[i], sizeof(ulong) *
vt->kmem_max_limit);
>
> What is "i" equal to when it segfaults? If you have a crash core
file,
> print out the contents of the global "vm_table". In that structure
> there is a "kmem_max_cpus" field. If "i" is greater or equal
to
that,
> then that's one explanation.
i=0 and kmem_max_cpus=4.
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?
Dave