Date: Tue, 1 Dec 2009 22:41:54 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: "Sean C. Farley" <scf@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: core dump in cvsup caused by _once()? Message-ID: <20091201204154.GC2368@deviant.kiev.zoral.com.ua> In-Reply-To: <alpine.BSF.2.00.0912011253540.14916@thor.farley.org> References: <20091128111501.34a7a2a4@ernst.jennejohn.org> <200912011009.59961.jhb@freebsd.org> <alpine.BSF.2.00.0912011253540.14916@thor.farley.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--UvwuEPigQXXfOf7G Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 01, 2009 at 12:59:25PM -0600, Sean C. Farley wrote: > On Tue, 1 Dec 2009, John Baldwin wrote: >=20 > >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)...do= ne. > >>Loaded symbols for /lib/libz.so.5 > >>Reading symbols from /lib/libm.so.5...(no debugging symbols found)...do= ne. > >>Loaded symbols for /lib/libm.so.5 > >>Reading symbols from /lib/libc.so.7...(no debugging symbols found)...do= ne. > >>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 symbo= ls > >that could be helpful (just cd /usr/src/lib/libc; make clean; make > >DEBUG_FLAGS=3D-g install). >=20 > Here is what I get from cvsupd: > 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=20 > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for detail= s. > This GDB was configured as "amd64-marcel-freebsd"... > Core was generated by `cvsupd'. > Program terminated with signal 4, Illegal instruction. > Reading symbols from /lib/libz.so.5...done. > Loaded symbols for /lib/libz.so.5 > Reading symbols from /lib/libm.so.5...done. > Loaded symbols for /lib/libm.so.5 > Reading symbols from=20 > /usr/FreeBSD/branches/stable/8/src/lib/libc/libc.so.7...done. > Loaded symbols for /usr/FreeBSD/branches/stable/8/src/lib/libc/libc.so.7 > Reading symbols from /libexec/ld-elf.so.1...done. > Loaded symbols for /libexec/ld-elf.so.1 > #0 0x00000008005c0d20 in _rtld_error () from /libexec/ld-elf.so.1 > (gdb) where > #0 0x00000008005c0d20 in _rtld_error () from /libexec/ld-elf.so.1 > #1 0x00000008005c156b in dladdr () from /libexec/ld-elf.so.1 > #2 0x00000008005c1643 in dladdr () from /libexec/ld-elf.so.1 > #3 0x00000008005be7bd in ?? () from /libexec/ld-elf.so.1 > #4 0x0000000000816ed8 in ?? () > #5 0x0000000000000000 in ?? () > #6 0x0000000000000006 in ?? () > #7 0x0000000000000043 in ?? () > #8 0x000000000072aba8 in ?? () > #9 0x0000000800a368e1 in _nsyycheck () from=20 > /usr/FreeBSD/branches/stable/8/src/lib/libc/libc.so.7 > #10 0x000000000072abbb in ?? () > #11 0x0000000000008000 in ?? () > #12 0x000000000072abbe in ?? () > #13 0x0000000000000216 in ?? () > #14 0x0000000000000000 in ?? () > #15 0x00000008005ed600 in ?? () > #16 0x0000000000000161 in ?? () > #17 0x0000000800a09049 in tzload (name=3D0x800a368e1 "posixrules",=20 > sp=3D0x7353b8, doextend=3D0) at=20 > /usr/FreeBSD/branches/stable/8/src/lib/libc/stdtime/localtime.c:422 > #18 0x0000000800a08a1e in tzparse (name=3D0x72b1cd "CDT,M3.2.0,M11.1.0",= =20 > sp=3D0x7353b8, lastditch=3DVariable "lastditch" is not available. > ) at /usr/FreeBSD/branches/stable/8/src/lib/libc/stdtime/localtime.c:1003 > #19 0x0000000800a096f6 in tzload (name=3DVariable "name" is not available= .)=20 > at /usr/FreeBSD/branches/stable/8/src/lib/libc/stdtime/localtime.c:580 > #20 0x0000000800a09a86 in tzsetwall_basic (rdlocked=3D1) at=20 > /usr/FreeBSD/branches/stable/8/src/lib/libc/stdtime/localtime.c:1229 > #21 0x0000000800a09deb in mktime (tmp=3D0x739ff8) at=20 > /usr/FreeBSD/branches/stable/8/src/lib/libc/stdtime/localtime.c:2119 > #22 0x00000000004ae085 in Date__ToTime (M3_D5xROs_d=3D0x5eed80) at=20 > DateBsd.m3:77 > #23 0x00000000004709dc in TimeStamp__Init () at TimeStamp.m3:46 > #24 0x0000000000470aa2 in TimeStamp__New (M3_CD9pHn__result=3D0x73a1c8) a= t=20 > TimeStamp.m3:60 > #25 0x000000000046fc1e in Random__RandomSeed () at Random.m3:67 > #26 0x000000000046fab2 in Random__Init (M3_B04YLH_t=3D0x825b38,=20 > M3_AicXUJ_fixed=3D0 '\0') at Random.m3:42 > #27 0x000000000044b9d5 in SortedRCSDeltaTbl__Init (M3_EKdMGR_tbl=3D0x825a= f8)=20 > at SortedTable.mg:106 > #28 0x0000000000450d99 in RCSFile__Init (M3_BcmbT8_rf=3D0x825990,=20 > M3_Bjvku1_desc=3D0x825a40) at RCSFile.m3:483 > #29 0x00000000004510c2 in RCSFile__OpenReadonly (M3_Bd56fi_p=3D0x825838) = at=20 > RCSFile.m3:574 > #30 0x000000000046305f in Attic__RCSFileOpenReadonly=20 > (M3_DMtSqf_path=3D0x73b3f8) at Attic.m3:120 > #31 0x00000000004166bc in RCSComp__CheckoutSend (M3_BQOzaz_self=3D0x65a61= 0,=20 > M3_CzVV2w_sfr=3D0x65e300, M3_Bd56fi_name=3D0x825778, M3_Bd56fi_tag=3D0x65= 1a00,=20 > M3_Bd56fi_date=3D0x651a00, > M3_AicXUJ_deleteIfDead=3D0 '\0', M3_AicXUJ_isFixup=3D0 '\0') at=20 > RCSComp.m3:1715 > #32 0x000000000040d08a in RCSComp__CompCollection (M3_BQOzaz_self=3D0x65a= 610,=20 > M3_CzVV2w_sfr=3D0x65e300) at RCSComp.m3:238 > #33 0x000000000040c4d8 in RCSComp__CompBatch (M3_BQOzaz_self=3D0x65a610) = at=20 > RCSComp.m3:155 > #34 0x000000000040bc90 in RCSComp__Apply (M3_BQOzaz_self=3D0x65a610) at= =20 > RCSComp.m3:78 > #35 0x00000000004a7240 in ThreadPosix__DetermineContext=20 > (M3_AJWxb1_oldSP=3D0x35) at ThreadPosix.m3:1127 > #36 0x0000000000689058 in ?? () > #37 0x00007fffffffe0a0 in ?? () > #38 0x000000000049c68c in RTMisc__Align (M3_AJWxb1_a=3DCannot access memo= ry=20 > at address 0x64c) at RTMisc.m3:31 > Previous frame inner to this frame (corrupt stack?) > (gdb) x/i $rip > 0x8005c0d20 <_rtld_error+3296>: mov %rdi,0xffffffffffffffa0(%rbp) > (gdb) info threads=20 > * 1 process 100176 0x00000008005c0d20 in _rtld_error () from=20 > /libexec/ld-elf.so.1 >=20 > BTW, I noticed the m3 call ThreadPosix__DetermineContext(), yet cvsupd=20 > is not linked against a thread library. The amd64 binary is linked to=20 > libz, libm and libc. The i386 binary links against those as well as=20 > libutil and libmd. Could you, please, also recompile rtld with debugging symbols ? SIGILL might be generated by kernel when signal frame cannot be copied out to usermode stack. Check out the registers content and size of stack too. --UvwuEPigQXXfOf7G Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAksVf5IACgkQC3+MBN1Mb4hTMwCgrLfCJgv018WpaphqpemOTj51 5R4AoN4Qth8e7XKp9l1+++NB0l9Yt733 =9fRC -----END PGP SIGNATURE----- --UvwuEPigQXXfOf7G--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091201204154.GC2368>