Re: core dump in cvsup caused by _once()?

On Saturday 28 November 2009 5:15:01 am Gary Jennejohn wrote:
> Since I installed a new world and kernel on November 26 I'm seeing
> core dumps with cvsup, even though I reinstalled cvsup yesterday.
> 
> Here the output from a gdb session without any debugging symbols:
> 
> Core was generated by `cvsup'.
> Program terminated with signal 4, Illegal instruction.
> Reading symbols from /lib/libz.so.5...(no debugging symbols found)...done.
> Loaded symbols for /lib/libz.so.5
> Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done.
> Loaded symbols for /lib/libm.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  0x00000008009edcf7 in gmtime_r () from /lib/libc.so.7
> (gdb) bt
> #0  0x00000008009edcf7 in gmtime_r () from /lib/libc.so.7
> #1  0x00000008009ed79e in gmtime_r () from /lib/libc.so.7
> #2  0x00000008009ee420 in gmtime_r () from /lib/libc.so.7
> #3  0x00000008009ee638 in gmtime_r () from /lib/libc.so.7
> #4  0x00000008009f1988 in _once () from /lib/libc.so.7
> #5  0x00000008009ed41f in timeoff () from /lib/libc.so.7
> #6  0x00000008009eeca7 in gmtime () from /lib/libc.so.7
> #7  0x00000000004a643a in calloc ()
> #8  0x000000000043aec7 in ?? ()
> #9  0x0000000000448eaa in ?? ()
> #10 0x0000000000409ece in ?? ()
> #11 0x00000000004191a4 in ?? ()
> #12 0x0000000000417cbe in ?? ()
> #13 0x000000000041529f in ?? ()
> #14 0x0000000000414d7a in ?? ()
> #15 0x000000000049f980 in calloc ()
> #16 0x000000000048fa3d in fnmatch ()
> #17 0x00007fffffffd3e8 in ?? ()
> #18 0x00007fffffffe950 in ?? ()
> #19 0x00007fffffffea40 in ?? ()
> #20 0x00007fffffffea28 in ?? ()
> #21 0x0000000000000000 in ?? ()
> #22 0x0000000000000000 in ?? ()
> #23 0x00001fa00000037f in ?? ()
> #24 0x0000000000000000 in ?? ()
> #25 0x00000000006476c0 in ?? ()
> #26 0x00000000006476c0 in ?? ()
> #27 0x0000000000494d89 in fnmatch ()
> Previous frame inner to this frame (corrupt stack?)
> 
> Seems to me that _once() was a very recent addition.  Can't say for
> certain whether this is the culprit, but it looks suspicious to me.

Can you do 'x/i $rip'?  Also, if you could rebuild libc with debug symbols 
that could be helpful (just cd /usr/src/lib/libc; make clean; make 
DEBUG_FLAGS=-g install).

-- 
John Baldwin