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>