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

[Mike Snitzer]

On Thu, Oct 16, 2008 at 12:25 PM, Dave Anderson <anderson at redhat.com> wrote:
>
> ----- "Mike Snitzer" <snitzer at 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.

> 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.

thanks,
Mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2.6.22_config.diff
Type: text/x-patch
Size: 1794 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20081016/5c6dc1c7/attachment.bin>