Re: ps -axl during textdumps occasionally segfaults with a HUGE ps.core

On Aug 14, 2009, at 10:39, Bruce Cran wrote:

> On Thu, 30 Jul 2009 09:00:50 +0200
> Thomas Backman <serenity_at_exscape.org> wrote:
>
>> On Jul 29, 2009, at 22:19, Thomas Backman wrote:
>>
>>> All the info I happen to have:
>>>
>>> (from core.txt.X)
>>> "ps -axl
>>>
>>> Segmentation fault (core dumped)"
>>>
>>> The last core I got (/ps.core) was 1076211712 bytes (1026 MiB).
>>>
>>> Anyone else with this problem?
>>> Unfortunately, I deleted the most recent core and so can't gdb it,
>>> at least not right now. I did try it on the first one, but got a
>>> very broken backtrace.
>>>
>>> Regards,
>>> Thomas
>> More detail:
>>
>> Core was generated by `ps'.
>> Program terminated with signal 11, Segmentation fault.
>> Reading symbols from /lib/libm.so.5...(no debugging symbols
>> found)...done.
>> Loaded symbols for /lib/libm.so.5
>> Reading symbols from /lib/libkvm.so.5...(no debugging symbols
>> found)...done.
>> Loaded symbols for /lib/libkvm.so.5
>> Reading symbols from /lib/libc.so.7...(no debugging symbols
>> found)...done.
>> Loaded symbols for /lib/libc.so.7
>> Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols
>> found)...done.
>> Loaded symbols for /libexec/ld-elf.so.1
>> #0  0x00000008009603a6 in bcopy () from /lib/libc.so.7
>> (gdb) bt
>> #0  0x00000008009603a6 in bcopy () from /lib/libc.so.7
>> #1  0x0000000800770141 in _kvm_freeprocs () from /lib/libkvm.so.5
>> #2  0x0000000800770870 in kvm_getprocs () from /lib/libkvm.so.5
>> #3  0x0000000000405322 in uname ()
>> #4  0x0000000000401f0e in ?? ()
>> #5  0x0000000800539000 in ?? ()
>> #6  0x0000000000000000 in ?? ()
>> #7  0x0000000000000006 in ?? ()
>> #8  0x00007fffffffef40 in ?? ()
>> #9  0x00007fffffffef43 in ?? ()
>> #10 0x00007fffffffef46 in ?? ()
>> #11 0x00007fffffffef5b in ?? ()
>> #12 0x00007fffffffef5e in ?? ()
>> #13 0x00007fffffffef72 in ?? ()
>> #14 0x0000000000000000 in ?? ()
>> ...
>> #586 0x0000000000000000 in ?? ()
>> #587 0x0073702f6e69622f in ?? ()
>> #588 0x247c8d48002454ff in ?? ()
>> #589 0x01a1c0c748006a10 in ?? ()
>> #590 0x66fdebf4050f0000 in ?? ()
>> #591 0x9066669066669066 in ?? ()
>> #592 0x00007fffffffeda0 in ?? ()
>> #593 0x0000000000000006 in ?? ()
>> #594 0x00007fffffffedd8 in ?? ()
>> #595 0x0000000000000004 in ?? ()
>> Cannot access memory at address 0x800000000000
>> (gdb)
>>
>> Not exactly a lot of useful info. Still, anyone else noticed this?
>> Oh, and this core was *exactly* as big as the previous one
>> (1076211712 bytes)...
>>
>
> I'm seeing 'ps -axl' segfault too - it seems operating on core files  
> is
> broken, because unsurprisingly I can get it to segfault just by  
> running
> 'ps -axl -M /var/crash/vmcore.2'.  During boot I only get a partial
> core file (350MB) because it fills my root partition, but the full  
> core
> is 1GB.
>
> -- 
> Bruce Cran
Looks like you're right!
I tried the same deal:
[root_at_chaos ~]# time ps -axl -M /var/crash/vmcore.45.NMAP_SCAN
Segmentation fault: 11 (core dumped)

real    0m46.005s
user    0m0.000s
sys     0m7.753s

(All the time taken, according to the hard drive noise, was to save  
the core dump, which existed long before it returned to the shell.

[root_at_chaos ~]# gdb /bin/ps ps.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and  
you are
welcome to change it and/or distribute copies of it under certain  
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for  
details.
This GDB was configured as "amd64-marcel-freebsd"...(no debugging  
symbols found)...
Core was generated by `ps'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libm.so.5...(no debugging symbols  
found)...done.
Loaded symbols for /lib/libm.so.5
Reading symbols from /lib/libkvm.so.5...(no debugging symbols  
found)...done.
Loaded symbols for /lib/libkvm.so.5
Reading symbols from /lib/libc.so.7...(no debugging symbols  
found)...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols  
found)...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  0x0000000800960b9b in strlen () from /lib/libc.so.7
(gdb) bt
#0  0x0000000800960b9b in strlen () from /lib/libc.so.7
#1  0x0000000800959812 in open () from /lib/libc.so.7
#2  0x00000008008f0546 in vsnprintf () from /lib/libc.so.7
#3  0x0000000800772d79 in _kvm_err () from /lib/libkvm.so.5
#4  0x00000008007707f7 in kvm_getprocs () from /lib/libkvm.so.5
#5  0x0000000000405322 in uname ()
#6  0x0000000000401f0e in ?? ()
#7  0x0000000800539000 in ?? ()
#8  0x0000000000000000 in ?? ()
#9  0x0000000000000000 in ?? ()
...
#639 0x9066669066669066 in ?? ()
#640 0x00007fffffffec38 in ?? ()
#641 0x0000000000000004 in ?? ()
#642 0x00007fffffffec60 in ?? ()
#643 0x0000000000000012 in ?? ()
Cannot access memory at address 0x800000000000

Crash in strlen() this time, rather than bcopy(), but uname() in still  
the root cause, I guess...?

Regards,
Thomas