bin/124353: cvsup(1): CVSup coredumps with Bus Error since installworld of 6.3-STABLE on 28/5/08 [regression]

Tue Jun 10 09:30:04 UTC 2008

The following reply was made to PR bin/124353; it has been noted by GNATS.

From: "Garrett Cooper" <yanefbsd at gmail.com>
To: "Simon Phillips" <srp at zzap.org>
Cc: bug-followup at 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 at gmail.com> wrote:
 > On Tue, Jun 10, 2008 at 1:50 AM, Simon Phillips <srp at zzap.org> wrote:
 >> The following reply was made to PR bin/124353; it has been noted by GNATS.
 >>
 >> From: srp at zzap.org (Simon Phillips)
 >> To: Garrett Cooper <yanefbsd at gmail.com>
 >> Cc: bug-followup at 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 at zzap.org> wrote:
 >>  > >
 >>  > > Garrett,
 >>  > >
 >>  > > Is this what you mean?
 >>  > >
 >>  > > 14:40:15 root at 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 at 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 at 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 at 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 at 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/.