Date: Tue, 10 Jun 2008 09:30:04 GMT From: "Garrett Cooper" <yanefbsd@gmail.com> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/124353: cvsup(1): CVSup coredumps with Bus Error since installworld of 6.3-STABLE on 28/5/08 [regression] Message-ID: <200806100930.m5A9U4xA027510@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/124353; it has been noted by GNATS. From: "Garrett Cooper" <yanefbsd@gmail.com> To: "Simon Phillips" <srp@zzap.org> Cc: bug-followup@freebsd.org Subject: Re: bin/124353: cvsup(1): CVSup coredumps with Bus Error since installworld of 6.3-STABLE on 28/5/08 [regression] Date: Tue, 10 Jun 2008 02:20:57 -0700 On Tue, Jun 10, 2008 at 2:20 AM, Garrett Cooper <yanefbsd@gmail.com> wrote: > On Tue, Jun 10, 2008 at 1:50 AM, Simon Phillips <srp@zzap.org> wrote: >> The following reply was made to PR bin/124353; it has been noted by GNATS. >> >> From: srp@zzap.org (Simon Phillips) >> To: Garrett Cooper <yanefbsd@gmail.com> >> Cc: bug-followup@freebsd.org >> Subject: Re: bin/124353: cvsup(1): CVSup coredumps with Bus Error since installworld >> of 6.3-STABLE on 28/5/08 [regression] >> Date: Tue, 10 Jun 2008 08:17:51 +0000 (UTC) >> >> > On Mon, Jun 9, 2008 at 10:19 PM, Simon Phillips <srp@zzap.org> wrote: >> > > >> > > Garrett, >> > > >> > > Is this what you mean? >> > > >> > > 14:40:15 root@mnemosyne:/usr/ports/net/cvsup-without-gui# cat >> > > /etc/make.conf >> > > # added by use.perl 2006-09-03 13:43:51 >> > > PERL_VER=3D5.8.8 >> > > PERL_VERSION=3D5.8.8 >> > > 14:40:18 root@mnemosyne:/usr/ports/net/cvsup-without-gui# >> > > >> > > I recompiled and will try gdb now. >> >=20 >> > Thanks for the info. I was just curious whether or not any weird >> > optimizations or CFLAG options were being used, out of habit because >> > the Gentoo Linux crowd tended to rice up their installs without >> > understanding what things stood for. I was the same too for a while >> > but learned after making some mistakes to stop ricing things :). >> >> Fair enough :) I tend to steer clear of playing with compiler=20 >> optimisations unless there's some special reason for them, like things >> are running too slow, which has never been an issue here (the same thing >> ran on an 800MHz P3 until the hardware died.) >> >> Here we go: >> >> 16:46:19 root@mnemosyne:/usr/src# gdb `which cvsup` >> 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 >> conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. Type "show warranty" for >> details. >> This GDB was configured as "amd64-marcel-freebsd"... >> (gdb) set arg -L 2 stable-supfile >> (gdb) run >> Starting program: /usr/local/bin/cvsup -L 2 stable-supfile >> Parsing supfile "stable-supfile" >> Connecting to 192.168.25.1 >> Connected to 192.168.25.1 >> Server software version: SNAP_16_1h >> Negotiating file attribute support >> Exchanging collection information >> Establishing multiplexed-mode data connection >> Running >> >> Program received signal SIGBUS, Bus error. >> 0x0000000800966d0f in fcntl () from /lib/libc.so.6 >> (gdb)=20 >> (gdb) bt >> #0 0x0000000800966d0f in fcntl () from /lib/libc.so.6 >> #1 0x000000000046550b in FilePosix__IntermittentWrite (M3_DCqqTS_h=3D0x63d= >> 7b8, >> M3_B4Jvpp_b=3D0x7748e8) at FilePosix.m3:249 >> #2 0x0000000000474430 in FileWr__EmptyBuffer (M3_EJV0jI_wr=3D0x63dbe8) >> at FileWr.m3:127 >> #3 0x0000000000474215 in FileWr__Flush (M3_EJV0jI_wr=3D0x63dbe8) >> at FileWr.m3:116 >> #4 0x000000000046f5a7 in Wr__Flush (M3_BxxOH1_wr=3D0x63dbe8) at WrMove.m3:= >> 165 >> #5 0x000000000042e0d7 in WrLogger__Put (M3_CgMIri_self=3D0x648710, >> M3_Bp286E_priority=3D5 '\005', M3_Bd56fi_msg=3D0x8111e8) at WrLogger.m3= >> :59 >> #6 0x000000000042db5c in Logger__Put (M3_AeHwgK_logger=3D0x648710, >> M3_Bp286E_priority=3D5 '\005', M3_Bd56fi_msg=3D0x8111e8) at Logger.m3:62 >> #7 0x000000000041cc2e in Updater__Trace (M3_DBUV6k_self=3D0x65d520, >> M3_Bd56fi_msg=3D0x8111e8) at Updater.m3:1381 >> #8 0x0000000000415bcd in Updater__UpdateCollection (M3_DBUV6k_self=3D0x65d= >> 520, >> M3_CzVV2w_sfr=3D0x65c008, M3_AicXUJ_isFixups=3D0 '\0') at Updater.m3:240 >> #9 0x000000000041525f in Updater__UpdateBatch (M3_DBUV6k_self=3D0x65d520, >> M3_AicXUJ_isFixups=3D0 '\0') at Updater.m3:151 >> #10 0x0000000000414d3a in Updater__Apply (M3_DBUV6k_self=3D0x65d520) >> at Updater.m3:90 >> #11 0x000000000049f840 in ThreadPosix__DetermineContext ( >> M3_AJWxb1_oldSP=3D0x63dfd0) at ThreadPosix.m3:1127 >> #12 0x000000000048fb11 in RTCollector__LongAlloc (M3_Cwb5VA_dataSize=3D4347= >> 143, >> M3_Cwb5VA_dataAlignment=3D6807552, M3_AOtCKl_currentPtr=3D0x648, >> M3_AOtCKl_currentBoundary=3D0x5c1c98, M3_CCsHD8_currentPage=3D0x0, >> M3_CCsHD8_stack=3D0x0, M3_D8qd0n_allocMode=3D0 '\0', M3_AicXUJ_pure=3D2= >> 00 '=C8') >> at RTCollector.m3:1530 >> #13 0x00007fffffffd098 in ?? () >> #14 0x00007fffffffe600 in ?? () >> #15 0x00007fffffffe6c8 in ?? () >> #16 0x0000000000000000 in ?? () >> #17 0x0000000000000000 in ?? () >> #18 0x0000000000000000 in ?? () >> #19 0x000000000000037f in ?? () >> #20 0x0000000000000000 in ?? () >> #21 0x00000000006476c0 in ?? () >> #22 0x00000000006476c0 in ?? () >> #23 0x0000000000494e5d in RTMisc__Copy (M3_AJWxb1_src=3DError accessing mem= >> ory address 0xfffffffffffffffc: Bad address. >> ) at RTMisc.m3:19 >> Previous frame inner to this frame (corrupt stack?) >> (gdb)=20 >> >> 17:26:40 root@mnemosyne:/usr/src# gcc --version >> gcc (GCC) 3.4.6 [FreeBSD] 20060305 >> Copyright (C) 2006 Free Software Foundation, Inc. >> This is free software; see the source for copying conditions. There is NO >> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. >> >> 17:26:41 root@mnemosyne:/usr/src# >> >> >> Hope that helps... >> >> >> Regards, >> >> Simon. > > Simon, > Based on the fact that those sections of code are fairly ugly, > platform dependent / 32-bit assuming assembler statements, I would > just steer clear of CVSup unless you intend to go to a fully 32-bit > platform (my guess is that there's some kind of address alignment > between fcntl(2) and FilePosix__IntermittentWrite in FilePosix.ms:718. > The author no longer supports the foundation library either (ezm3), > due to time constraints, so I doubt that he's going to have time to > rewrite the code to be platform independent~ish... > I'll test out this assumption on my 7.0 amd64 VM in a bit and > see whether or not the issue still holds. > Are you starting off with a clean repository or a > semi-/fully-populated repository though? > Thanks, > -Garrett s/address alignment/address alignment issue/.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200806100930.m5A9U4xA027510>