Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 7 Dec 2009 15:34:20 +0100
From:      Gary Jennejohn <gary.jennejohn@freenet.de>
To:        current@FreeBSD.org
Subject:   Re: core dump in cvsup caused by _once()?
Message-ID:  <20091207153420.26772260@ernst.jennejohn.org>
In-Reply-To: <20091128182351.3e245ad6@ernst.jennejohn.org>
References:  <20091128111501.34a7a2a4@ernst.jennejohn.org> <alpine.BSF.2.00.0911280910400.54979@thor.farley.org> <20091128182351.3e245ad6@ernst.jennejohn.org>

next in thread | previous in thread | raw e-mail | index | archive | help
"Sean C. Farley" <scf@FreeBSD.org> wrote:

> Also, cvsupd will core dump (SIGILL) when built on stable/8 amd64 
> r199641 when a connection to it is made from csup.  An i386-built 
> cvsupd will run correctly on the same system.  For cvsupd, it is dying 
> at dladdr(), but I have not had time to debug it further.
>

I'm seeing this now also on 9-CURRENT AMD64 using a world installed today (but
compiled yesterday).  I'd decided to recompile cvsup/cvsupd with debugging
in an effort to figure out why a newly installed zoneinfo/UTC causes cvsup to
dump core.

Some gdb output:
Core was generated by `cvsupd'.
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  0x00000008005c0ae0 in symlook_default () from /libexec/ld-elf.so.1
(gdb) bt
#0  0x00000008005c0ae0 in symlook_default () from /libexec/ld-elf.so.1
#1  0x00000008005c132b in find_symdef () from /libexec/ld-elf.so.1
#2  0x00000008005c1403 in _rtld_bind () from /libexec/ld-elf.so.1
#3  0x00000008005be57d in _rtld_bind_start () from /libexec/ld-elf.so.1

If I run cvsupd under ktrace it does not fail.  It also does not fail
if I don't specify the -C flag.  In both these case cvsupd basically runs
in the foreground.  It almost looks like the normal case, with -C and a fork
of cvsupd, results in the death of the child because the parent cvsupd keeps
running.  Very weird.

Last week it still worked.

---
Gary Jennejohn



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091207153420.26772260>