Skip site navigation (1)Skip section navigation (2)
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>