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

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

Regards,
Thomas