From nobody@FreeBSD.org  Tue Nov 15 15:40:03 2011
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 88420106564A
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 15 Nov 2011 15:40:03 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22])
	by mx1.freebsd.org (Postfix) with ESMTP id 749548FC19
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 15 Nov 2011 15:40:03 +0000 (UTC)
Received: from red.freebsd.org (localhost [127.0.0.1])
	by red.freebsd.org (8.14.4/8.14.4) with ESMTP id pAFFe2AQ063586
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 15 Nov 2011 15:40:02 GMT
	(envelope-from nobody@red.freebsd.org)
Received: (from nobody@localhost)
	by red.freebsd.org (8.14.4/8.14.4/Submit) id pAFFe2J1063585;
	Tue, 15 Nov 2011 15:40:02 GMT
	(envelope-from nobody)
Message-Id: <201111151540.pAFFe2J1063585@red.freebsd.org>
Date: Tue, 15 Nov 2011 15:40:02 GMT
From: Henri Hennebert <hlh@restart.be>
To: freebsd-gnats-submit@FreeBSD.org
Subject: cvsup and cvsupd get signal 10 under 9.0-RC2 amd64
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         162588
>Category:       bin
>Synopsis:       libz partially broken when compiled with clang [was: net/cvsup: cvsup and cvsupd get signal 10 under 9.0-RC2 amd64]
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    dim
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Nov 15 15:50:02 UTC 2011
>Closed-Date:    Mon Feb 24 22:27:33 UTC 2014
>Last-Modified:  Mon Feb 24 22:27:33 UTC 2014
>Originator:     Henri Hennebert
>Release:        9.0-RC2 r227497M
>Organization:
>Environment:
FreeBSD avoriaz.restart.bel 9.0-RC2 FreeBSD 9.0-RC2 #0 r227497M: Mon Nov 14 18:16:59 CET 2011     root@avoriaz.restart.bel:/usr/obj/usr/src/sys/AVORIAZ  amd64
>Description:
Since my upgrade from 9.0.RC1 to 9.0-RC2 cvsup and cvsupd stop with:

avoriaz kernel: pid 20161 (cvsup), uid 3006: exited on signal 10

avoriaz cvsupd[24016]: +0 hlh@morzine.restart.bel [CSUP_1_0/17.0]
avoriaz kernel: pid 24016 (cvsupd), uid 3005: exited on signal 10


I reinstall ezm3-1.1_2 and cvsup-without-gui-16.1h_4 to no avail

Henri
>How-To-Repeat:

>Fix:


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-ports-bugs->bz 
Responsible-Changed-By: bz 
Responsible-Changed-When: Sat Jan 21 12:26:07 UTC 2012 
Responsible-Changed-Why:  
Temporary claim to track. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=162588 

From: "Bjoern A. Zeeb" <bz@FreeBSD.org>
To: bug-followup@FreeBSD.org, hlh@restart.be
Cc:  
Subject: Re: ports/162588: net/cvsup: cvsup and cvsupd get signal 10 under
 9.0-RC2 amd64
Date: Sat, 21 Jan 2012 12:28:15 +0000 (UTC)

 Wasn't this solved with the help of people on current@ - or is it
 still an issue?
State-Changed-From-To: open->feedback 
State-Changed-By: bz 
State-Changed-When: Sat Jan 21 12:35:09 UTC 2012 
State-Changed-Why:  
Feedback was requested from submitter. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=162588 

From: Henri Hennebert <hlh@restart.be>
To: "Bjoern A. Zeeb" <bz@FreeBSD.org>
Cc: bug-followup@FreeBSD.org
Subject: Re: ports/162588: net/cvsup: cvsup and cvsupd get signal 10 under
 9.0-RC2 amd64
Date: Sat, 21 Jan 2012 18:51:01 +0100

 On 01/21/2012 13:28, Bjoern A. Zeeb wrote:
 > Wasn't this solved with the help of people on current@ - or is it
 > still an issue?
 > 
 It is still an issue under 9.0 RELEASE on amd64
 
 Henri

From: Kostik Belousov <kostikbel@gmail.com>
To: bug-followup@FreeBSD.org, hlh@restart.be
Cc:  
Subject: Re: ports/162588: net/cvsup: cvsup and cvsupd get signal 10 under
 9.0-RC2 amd64
Date: Sat, 21 Jan 2012 21:33:23 +0200

 Please get the backtrace from the gdb to start investigating the issue.
 You may need to rebuild the port and at least libc with debugging symbols
 for the backtrace to be useful.

From: Henri Hennebert <hlh@restart.be>
To: Kostik Belousov <kostikbel@gmail.com>
Cc: bug-followup@FreeBSD.org, bz@FreeBSD.org
Subject: Re: ports/162588: net/cvsup: cvsup and cvsupd get signal 10 under
 9.0-RC2 amd64
Date: Sun, 22 Jan 2012 18:05:29 +0100

 On 01/21/2012 20:33, Kostik Belousov wrote:
 > Please get the backtrace from the gdb to start investigating the issue.
 > You may need to rebuild the port and at least libc with debugging symbols
 > for the backtrace to be useful.
 > 
 
 Really a strange problem:
 
 - when I compile cvsup with debugging symbol I get a bt from libz.
   So I compile libz with debugging symbols and then ... the problem
   vanish.
   So, I recompile libz without debugging symbol and the problem don't
   come back.
   cvsup stripped + libz stripped  -> no more problem.
 
 I think that the problem is due to the state of my /usr/ports directory.
 BTW, this directory is updated from time to time with csup after
 encountering the problem with cvsup.
 
 So I try to run the script  `/usr/local/etc/cvsup/update.sh -P m' to
 update my local cvs mirror and ... the problem is back.
 
 I run again under gdb:
 
 [root@avoriaz cvsup]# gdb /tmp/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) run -1gL 1 -b /usr/local/etc/cvsup -c sup.client -P m -h
 cvsup2.fr.freebsd.org /usr/local/etc/cvsup/supfile
 Starting program: /tmp/cvsup -1gL 1 -b /usr/local/etc/cvsup -c
 sup.client -P m -h cvsup2.fr.freebsd.org /usr/local/etc/cvsup/supfile
 Connected to cvsup2.fr.freebsd.org
 
 Program received signal SIGBUS, Bus error.
 0x0000000800df0d40 in getgrnam_r () from /lib/libc.so.7
 (gdb) bt
 #0  0x0000000800df0d40 in getgrnam_r () from /lib/libc.so.7
 #1  0x0000000800e00271 in nsdispatch () from /lib/libc.so.7
 #2  0x0000000800df1a5c in getgrnam () from /lib/libc.so.7
 #3  0x0000000800df198e in getgrnam () from /lib/libc.so.7
 #4  0x0000000000435b3d in FileAttr__DecodeGroup
 (M3_Bd56fi_name=0x760108, M3_Cn4iCO_gid=0x842c54)
     at FileAttr.m3:969
 #5  0x0000000000432984 in FileAttr__Decode (M3_Bd56fi_t=0x75ffc8) at
 FileAttr.m3:135
 #6  0x00000000004516dc in FileStatus__GetAttr (M3_BAtSIQ_ts=0x75fee8,
 M3_Cwb5VA_version=5,
     M3_Bd56fi_what=0x6f0b70) at FileStatus.m3:134
 #7  0x0000000000450f8b in FileStatusRaw__MakeCooked
 (M3_CeLxp4_fs=0x75fe80, M3_Cwb5VA_version=5)
     at FileStatus.m3:88
 #8  0x0000000000451e7c in FileStatus__RdGet (M3_BApvCL_rr=0x75f828) at
 FileStatus.m3:226
 #9  0x000000000040e4de in TreeList__PutCollectionList
 (M3_AgsQ60_self=0x756f88,
     M3_CzVV2w_sfr=0x761008) at TreeList.m3:194
 #10 0x000000000040df3a in TreeList__ListCollection
 (M3_AgsQ60_self=0x756f88,
     M3_CzVV2w_sfr=0x761008) at TreeList.m3:136
 #11 0x000000000040d7dc in TreeList__Apply (M3_AgsQ60_self=0x756f88) at
 TreeList.m3:65
 #12 0x000000000049f8e0 in ThreadPosix__DetermineContext
 (M3_AJWxb1_oldSP=0x741fd0)
     at ThreadPosix.m3:1127
 #13 0x000000000048f99d in RTCollector__LongAlloc
 (M3_Cwb5VA_dataSize=4347039,
     M3_Cwb5VA_dataAlignment=7872512, M3_AOtCKl_currentPtr=0x74c,
     M3_AOtCKl_currentBoundary=0x6d9cf8, M3_CCsHD8_currentPage=0x0,
 M3_CCsHD8_stack=0x0,
     M3_D8qd0n_allocMode=32 ' ', M3_AicXUJ_pure=232 '') at
 RTCollector.m3:1530
 #14 0x00007fffffffc3b8 in ?? ()
 #15 0x00007fffffffd920 in ?? ()
 #16 0x00007fffffffd9e8 in ?? ()
 #17 0x0000000000000000 in ?? ()
 #18 0x00007fffffffda58 in ?? ()
 #19 0x000000000000000c in ?? ()
 #20 0x00001fa00000037f in ?? ()
 #21 0x0000000000000000 in ?? ()
 #22 0x000000000074b6c0 in ?? ()
 ---Type <return> to continue, or q <return> to quit---
 #23 0x000000000074b6c0 in ?? ()
 #24 0x0000000000494ce9 in RTMisc__Copy (M3_AJWxb1_src=0xc,
 M3_AJWxb1_dest=0x0,
     M3_AcxOUs_len=34367025152) at RTMisc.m3:19
 #25 0x00007fffffffdcb3 in ?? ()
 #26 0x00007fffffffdcb8 in ?? ()
 #27 0x00007fffffffdcba in ?? ()
 #28 0x00007fffffffdcbd in ?? ()
 #29 0x00007fffffffdcd2 in ?? ()
 #30 0x00007fffffffdcd5 in ?? ()
 #31 0x00007fffffffdce0 in ?? ()
 #32 0x00007fffffffdce3 in ?? ()
 #33 0x00007fffffffdce5 in ?? ()
 #34 0x00007fffffffdce8 in ?? ()
 #35 0x00007fffffffdcfe in ?? ()
 #36 0x0000000000000000 in ?? ()
 #37 0x00007fffffffdd1b in ?? ()
 #38 0x00007fffffffdd31 in ?? ()
 #39 0x00007fffffffdd3c in ?? ()
 #40 0x00007fffffffdd56 in ?? ()
 #41 0x00007fffffffdd81 in ?? ()
 #42 0x00007fffffffdd90 in ?? ()
 #43 0x00007fffffffddad in ?? ()
 #44 0x00007fffffffddc0 in ?? ()
 #45 0x00007fffffffddca in ?? ()
 #46 0x00007fffffffddd5 in ?? ()
 #47 0x00007fffffffdde1 in ?? ()
 #48 0x00007fffffffddf6 in ?? ()
 #49 0x00007fffffffde0a in ?? ()
 #50 0x00007fffffffde64 in ?? ()
 #51 0x00007fffffffde73 in ?? ()
 #52 0x00007fffffffde7f in ?? ()
 #53 0x00007fffffffde98 in ?? ()
 ---Type <return> to continue, or q <return> to quit---
 #54 0x00007fffffffdea5 in ?? ()
 #55 0x00007fffffffdeba in ?? ()
 #56 0x00007fffffffdecc in ?? ()
 #57 0x00007fffffffded5 in ?? ()
 #58 0x00007fffffffdef1 in ?? ()
 #59 0x00007fffffffdef9 in ?? ()
 #60 0x00007fffffffdf22 in ?? ()
 #61 0x00007fffffffdf2f in ?? ()
 #62 0x0000000000000000 in ?? ()
 #63 0x0000000000000003 in ?? ()
 #64 0x0000000000400040 in ?? ()
 #65 0x0000000000000004 in ?? ()
 #66 0x0000000000000038 in ?? ()
 #67 0x0000000000000005 in ?? ()
 #68 0x0000000000000008 in ?? ()
 #69 0x0000000000000006 in ?? ()
 #70 0x0000000000001000 in ?? ()
 #71 0x0000000000000008 in ?? ()
 #72 0x0000000000000000 in ?? ()
 #73 0x0000000000000009 in ?? ()
 #74 0x00000000004027e0 in ?? ()
 #75 0x0000000000000007 in ?? ()
 #76 0x00000008006b9000 in ?? ()
 #77 0x000000000000000f in ?? ()
 #78 <signal handler called>
 #79 0x0000000000000000 in ?? ()
 Previous frame inner to this frame (corrupt stack?)
 (gdb)
 
 And Now with debugging symbols in libc; yes, the problem disappear!
 
 And of course... no more problem when I run it stripped
 
 I then try to access this mirror and cvsupd -- which was running for
 boot time (19 days) -- It crash with:
 
 Jan 22 17:44:08 avoriaz cvsupd[74590]: +0 hlh@meribel.restart.bel
 [CSUP_1_0/17.0]
 Jan 22 17:44:09 avoriaz kernel: pid 74590 (cvsupd), uid 3005: exited on
 signal 10
 
 Then I restart cvsupd and now all is running smoothly.
 
 Really strange. I understand why nobody encounter the same problem.
 
 Thanks for your time
 
 Henri
 
 
 
 
 

From: Kostik Belousov <kostikbel@gmail.com>
To: Henri Hennebert <hlh@restart.be>
Cc: bug-followup@freebsd.org, bz@freebsd.org
Subject: Re: ports/162588: net/cvsup: cvsup and cvsupd get signal 10 under 9.0-RC2 amd64
Date: Mon, 23 Jan 2012 03:56:32 +0200

 --nrJ+9zYafiRJCnyh
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Sun, Jan 22, 2012 at 06:05:29PM +0100, Henri Hennebert wrote:
 > On 01/21/2012 20:33, Kostik Belousov wrote:
 > > Please get the backtrace from the gdb to start investigating the issue.
 > > You may need to rebuild the port and at least libc with debugging symbo=
 ls
 > > for the backtrace to be useful.
 > >=20
 >=20
 > Really a strange problem:
 >=20
 > - when I compile cvsup with debugging symbol I get a bt from libz.
 >   So I compile libz with debugging symbols and then ... the problem
 >   vanish.
 >   So, I recompile libz without debugging symbol and the problem don't
 >   come back.
 >   cvsup stripped + libz stripped  -> no more problem.
 >=20
 > I think that the problem is due to the state of my /usr/ports directory.
 > BTW, this directory is updated from time to time with csup after
 > encountering the problem with cvsup.
 >=20
 > So I try to run the script  `/usr/local/etc/cvsup/update.sh -P m' to
 > update my local cvs mirror and ... the problem is back.
 >=20
 > I run again under gdb:
 >=20
 > [root@avoriaz cvsup]# gdb /tmp/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 detail=
 s.
 > This GDB was configured as "amd64-marcel-freebsd"...
 > (gdb) run -1gL 1 -b /usr/local/etc/cvsup -c sup.client -P m -h
 > cvsup2.fr.freebsd.org /usr/local/etc/cvsup/supfile
 > Starting program: /tmp/cvsup -1gL 1 -b /usr/local/etc/cvsup -c
 > sup.client -P m -h cvsup2.fr.freebsd.org /usr/local/etc/cvsup/supfile
 > Connected to cvsup2.fr.freebsd.org
 >=20
 > Program received signal SIGBUS, Bus error.
 > 0x0000000800df0d40 in getgrnam_r () from /lib/libc.so.7
 > (gdb) bt
 > #0  0x0000000800df0d40 in getgrnam_r () from /lib/libc.so.7
 > #1  0x0000000800e00271 in nsdispatch () from /lib/libc.so.7
 > #2  0x0000000800df1a5c in getgrnam () from /lib/libc.so.7
 > #3  0x0000000800df198e in getgrnam () from /lib/libc.so.7
 > #4  0x0000000000435b3d in FileAttr__DecodeGroup
 > (M3_Bd56fi_name=3D0x760108, M3_Cn4iCO_gid=3D0x842c54)
 >     at FileAttr.m3:969
 > #5  0x0000000000432984 in FileAttr__Decode (M3_Bd56fi_t=3D0x75ffc8) at
 > FileAttr.m3:135
 > #6  0x00000000004516dc in FileStatus__GetAttr (M3_BAtSIQ_ts=3D0x75fee8,
 > M3_Cwb5VA_version=3D5,
 >     M3_Bd56fi_what=3D0x6f0b70) at FileStatus.m3:134
 > #7  0x0000000000450f8b in FileStatusRaw__MakeCooked
 > (M3_CeLxp4_fs=3D0x75fe80, M3_Cwb5VA_version=3D5)
 >     at FileStatus.m3:88
 > #8  0x0000000000451e7c in FileStatus__RdGet (M3_BApvCL_rr=3D0x75f828) at
 > FileStatus.m3:226
 > #9  0x000000000040e4de in TreeList__PutCollectionList
 > (M3_AgsQ60_self=3D0x756f88,
 >     M3_CzVV2w_sfr=3D0x761008) at TreeList.m3:194
 > #10 0x000000000040df3a in TreeList__ListCollection
 > (M3_AgsQ60_self=3D0x756f88,
 >     M3_CzVV2w_sfr=3D0x761008) at TreeList.m3:136
 > #11 0x000000000040d7dc in TreeList__Apply (M3_AgsQ60_self=3D0x756f88) at
 > TreeList.m3:65
 > #12 0x000000000049f8e0 in ThreadPosix__DetermineContext
 > (M3_AJWxb1_oldSP=3D0x741fd0)
 >     at ThreadPosix.m3:1127
 > #13 0x000000000048f99d in RTCollector__LongAlloc
 > (M3_Cwb5VA_dataSize=3D4347039,
 >     M3_Cwb5VA_dataAlignment=3D7872512, M3_AOtCKl_currentPtr=3D0x74c,
 >     M3_AOtCKl_currentBoundary=3D0x6d9cf8, M3_CCsHD8_currentPage=3D0x0,
 > M3_CCsHD8_stack=3D0x0,
 >     M3_D8qd0n_allocMode=3D32 ' ', M3_AicXUJ_pure=3D232 '?') at
 > RTCollector.m3:1530
 > #14 0x00007fffffffc3b8 in ?? ()
 > #15 0x00007fffffffd920 in ?? ()
 > #16 0x00007fffffffd9e8 in ?? ()
 > #17 0x0000000000000000 in ?? ()
 > #18 0x00007fffffffda58 in ?? ()
 > #19 0x000000000000000c in ?? ()
 > #20 0x00001fa00000037f in ?? ()
 > #21 0x0000000000000000 in ?? ()
 > #22 0x000000000074b6c0 in ?? ()
 > ---Type <return> to continue, or q <return> to quit---
 > #23 0x000000000074b6c0 in ?? ()
 > #24 0x0000000000494ce9 in RTMisc__Copy (M3_AJWxb1_src=3D0xc,
 > M3_AJWxb1_dest=3D0x0,
 >     M3_AcxOUs_len=3D34367025152) at RTMisc.m3:19
 > #25 0x00007fffffffdcb3 in ?? ()
 > #26 0x00007fffffffdcb8 in ?? ()
 > #27 0x00007fffffffdcba in ?? ()
 > #28 0x00007fffffffdcbd in ?? ()
 > #29 0x00007fffffffdcd2 in ?? ()
 > #30 0x00007fffffffdcd5 in ?? ()
 > #31 0x00007fffffffdce0 in ?? ()
 > #32 0x00007fffffffdce3 in ?? ()
 > #33 0x00007fffffffdce5 in ?? ()
 > #34 0x00007fffffffdce8 in ?? ()
 > #35 0x00007fffffffdcfe in ?? ()
 > #36 0x0000000000000000 in ?? ()
 > #37 0x00007fffffffdd1b in ?? ()
 > #38 0x00007fffffffdd31 in ?? ()
 > #39 0x00007fffffffdd3c in ?? ()
 > #40 0x00007fffffffdd56 in ?? ()
 > #41 0x00007fffffffdd81 in ?? ()
 > #42 0x00007fffffffdd90 in ?? ()
 > #43 0x00007fffffffddad in ?? ()
 > #44 0x00007fffffffddc0 in ?? ()
 > #45 0x00007fffffffddca in ?? ()
 > #46 0x00007fffffffddd5 in ?? ()
 > #47 0x00007fffffffdde1 in ?? ()
 > #48 0x00007fffffffddf6 in ?? ()
 > #49 0x00007fffffffde0a in ?? ()
 > #50 0x00007fffffffde64 in ?? ()
 > #51 0x00007fffffffde73 in ?? ()
 > #52 0x00007fffffffde7f in ?? ()
 > #53 0x00007fffffffde98 in ?? ()
 > ---Type <return> to continue, or q <return> to quit---
 > #54 0x00007fffffffdea5 in ?? ()
 > #55 0x00007fffffffdeba in ?? ()
 > #56 0x00007fffffffdecc in ?? ()
 > #57 0x00007fffffffded5 in ?? ()
 > #58 0x00007fffffffdef1 in ?? ()
 > #59 0x00007fffffffdef9 in ?? ()
 > #60 0x00007fffffffdf22 in ?? ()
 > #61 0x00007fffffffdf2f in ?? ()
 > #62 0x0000000000000000 in ?? ()
 > #63 0x0000000000000003 in ?? ()
 > #64 0x0000000000400040 in ?? ()
 > #65 0x0000000000000004 in ?? ()
 > #66 0x0000000000000038 in ?? ()
 > #67 0x0000000000000005 in ?? ()
 > #68 0x0000000000000008 in ?? ()
 > #69 0x0000000000000006 in ?? ()
 > #70 0x0000000000001000 in ?? ()
 > #71 0x0000000000000008 in ?? ()
 > #72 0x0000000000000000 in ?? ()
 > #73 0x0000000000000009 in ?? ()
 > #74 0x00000000004027e0 in ?? ()
 > #75 0x0000000000000007 in ?? ()
 > #76 0x00000008006b9000 in ?? ()
 > #77 0x000000000000000f in ?? ()
 > #78 <signal handler called>
 > #79 0x0000000000000000 in ?? ()
 > Previous frame inner to this frame (corrupt stack?)
 > (gdb)
 >=20
 > And Now with debugging symbols in libc; yes, the problem disappear!
 >=20
 > And of course... no more problem when I run it stripped
 >=20
 > I then try to access this mirror and cvsupd -- which was running for
 > boot time (19 days) -- It crash with:
 >=20
 > Jan 22 17:44:08 avoriaz cvsupd[74590]: +0 hlh@meribel.restart.bel
 > [CSUP_1_0/17.0]
 > Jan 22 17:44:09 avoriaz kernel: pid 74590 (cvsupd), uid 3005: exited on
 > signal 10
 >=20
 > Then I restart cvsupd and now all is running smoothly.
 >=20
 > Really strange. I understand why nobody encounter the same problem.
 Can it be that something modified the /etc/group in parallel ?
 
 --nrJ+9zYafiRJCnyh
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.11 (FreeBSD)
 
 iEYEARECAAYFAk8cvk8ACgkQC3+MBN1Mb4iFaACeI7w8TwXUuYfVSUXIm68F0F55
 4wIAoLLyOpe5CpTXYwldEOyegJ9bJtBE
 =xJnu
 -----END PGP SIGNATURE-----
 
 --nrJ+9zYafiRJCnyh--

From: Henri Hennebert <hlh@restart.be>
To: Kostik Belousov <kostikbel@gmail.com>
Cc: bug-followup@freebsd.org, bz@freebsd.org
Subject: Re: ports/162588: net/cvsup: cvsup and cvsupd get signal 10 under
 9.0-RC2 amd64
Date: Mon, 23 Jan 2012 13:40:45 +0100

 On 01/23/2012 02:56, Kostik Belousov wrote:
 > On Sun, Jan 22, 2012 at 06:05:29PM +0100, Henri Hennebert wrote:
 >> On 01/21/2012 20:33, Kostik Belousov wrote:
 >>> Please get the backtrace from the gdb to start investigating the issue.
 >>> You may need to rebuild the port and at least libc with debugging symbols
 >>> for the backtrace to be useful.
 >>>
 >>
 
 <--- clip --->
 
 > Can it be that something modified the /etc/group in parallel ?
 
 More simple than this, SHAME ON ME!
 
 When I compile world I do it with clang. When I add debugging symbol,
 I forget to export my local variable: WITH_CLANG.
 
 So the reality is this: compiling libz and libc with gcc (from base)
 all seems OK.
 
 Now the backtrace with libz compiled with clang:
 
 [root@avoriaz cvsup]# gdb /tmp/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) run /usr/local/cvsup/ports-supfile
 Starting program: /tmp/cvsup /usr/local/cvsup/ports-supfile
 Connected to cvsup2.fr.freebsd.org
 Updating collection ports-base/cvs
 
 Program received signal SIGBUS, Bus error.
 inflate_table (type=Variable "type" is not available.
 ) at /usr/src/lib/libz/inftrees.c:108
 108	        count[len] = 0;
 Current language:  auto; currently minimal
 (gdb) bt
 #0  inflate_table (type=Variable "type" is not available.
 ) at /usr/src/lib/libz/inftrees.c:108
 #1  0x000000080090d75f in inflate (strm=dwarf2_read_address: Corrupted 
 DWARF expression.
 ) at /usr/src/lib/libz/inflate.c:910
 #2  0x0000000000455e07 in GzipRd__Inflate (M3_EZagPA_strmp=0x809880, 
 M3_Db2r4Z_next_in=0x76702c, M3_Cwb5VA_avail_in=7602,
      M3_Db2r4Z_next_out=0x7f7018, M3_Cwb5VA_avail_out=8192, 
 M3_AcxOUs_flush=1) at GzipRd.m3:93
 #3  0x00000000004562e9 in GzipRd__Seek (M3_BQEsa6_self=0x7f6ec0, 
 M3_Cwb5VA_n=0, M3_AicXUJ_dontBlock=0 '\0') at GzipRd.m3:158
 #4  0x000000000044f2ea in SupMisc__GetCmdLine (M3_EkTcCb_rd=0x7f6ec0) at 
 SupMisc.m3:209
 #5  0x0000000000436449 in CVProto__T1GetCmd (M3_Bkshdd_self=0x74b4a8, 
 M3_EkTcCb_rd=0x7f6ec0) at CVProto.m3:87
 #6  0x0000000000415c9a in Updater__UpdateCollection 
 (M3_DBUV6k_self=0x7664b8, M3_CzVV2w_sfr=0x8882a0, M3_AicXUJ_isFixups=0 
 '\0') at Updater.m3:250
 #7  0x00000000004151f7 in Updater__UpdateBatch (M3_DBUV6k_self=0x7664b8, 
 M3_AicXUJ_isFixups=0 '\0') at Updater.m3:151
 #8  0x0000000000414cd2 in Updater__Apply (M3_DBUV6k_self=0x7664b8) at 
 Updater.m3:90
 #9  0x000000000049f8e0 in ThreadPosix__DetermineContext 
 (M3_AJWxb1_oldSP=0x741fd0) at ThreadPosix.m3:1127
 #10 0x000000000048f99d in RTCollector__LongAlloc 
 (M3_Cwb5VA_dataSize=4347039, M3_Cwb5VA_dataAlignment=7872512, 
 M3_AOtCKl_currentPtr=0x74c,
      M3_AOtCKl_currentBoundary=0x6d9cf8, M3_CCsHD8_currentPage=0x0, 
 M3_CCsHD8_stack=0x0, M3_D8qd0n_allocMode=176 '', M3_AicXUJ_pure=120 'x')
      at RTCollector.m3:1530
 #11 0x00007fffffffc448 in ?? ()
 #12 0x00007fffffffd9b0 in ?? ()
 #13 0x00007fffffffda78 in ?? ()
 #14 0x0000000000000000 in ?? ()
 #15 0x00007fffffffda98 in ?? ()
 #16 0x0000000000000002 in ?? ()
 #17 0x00001fa00000037f in ?? ()
 #18 0x0000000000000000 in ?? ()
 #19 0x000000000074b6c0 in ?? ()
 #20 0x000000000074b6c0 in ?? ()
 #21 0x0000000000494ce9 in RTMisc__Copy (M3_AJWxb1_src=0x2, 
 M3_AJWxb1_dest=0x0, M3_AcxOUs_len=34367025152) at RTMisc.m3:19
 #22 0x00007fffffffdcfb in ?? ()
 #23 0x0000000000000000 in ?? ()
 #24 0x00007fffffffdd1a in ?? ()
 #25 0x00007fffffffdd30 in ?? ()
 #26 0x00007fffffffdd3b in ?? ()
 #27 0x00007fffffffdd55 in ?? ()
 #28 0x00007fffffffdd80 in ?? ()
 #29 0x00007fffffffdd9d in ?? ()
 #30 0x00007fffffffddb0 in ?? ()
 #31 0x00007fffffffddba in ?? ()
 #32 0x00007fffffffddc5 in ?? ()
 #33 0x00007fffffffddd4 in ?? ()
 #34 0x00007fffffffdde0 in ?? ()
 #35 0x00007fffffffddf5 in ?? ()
 #36 0x00007fffffffde09 in ?? ()
 #37 0x00007fffffffde63 in ?? ()
 #38 0x00007fffffffde72 in ?? ()
 #39 0x00007fffffffde7e in ?? ()
 #40 0x00007fffffffde93 in ?? ()
 #41 0x00007fffffffdea0 in ?? ()
 #42 0x00007fffffffdeb5 in ?? ()
 #43 0x00007fffffffdec7 in ?? ()
 #44 0x00007fffffffded0 in ?? ()
 #45 0x00007fffffffdee0 in ?? ()
 #46 0x00007fffffffdee8 in ?? ()
 #47 0x00007fffffffdf11 in ?? ()
 #48 0x00007fffffffdf1e in ?? ()
 #49 0x00007fffffffdf64 in ?? ()
 #50 0x0000000000000000 in ?? ()
 #51 0x0000000000000003 in ?? ()
 #52 0x0000000000400040 in ?? ()
 #53 0x0000000000000004 in ?? ()
 #54 0x0000000000000038 in ?? ()
 #55 0x0000000000000005 in ?? ()
 #56 0x0000000000000008 in ?? ()
 #57 0x0000000000000006 in ?? ()
 #58 0x0000000000001000 in ?? ()
 #59 0x0000000000000008 in ?? ()
 #60 0x0000000000000000 in ?? ()
 #61 0x0000000000000009 in ?? ()
 ---Type <return> to continue, or q <return> to quit---
 #62 0x00000000004027e0 in ?? ()
 #63 0x0000000000000007 in ?? ()
 #64 0x00000008006b9000 in ?? ()
 #65 0x000000000000000f in ?? ()
 #66 <signal handler called>
 #67 0x0000000000000000 in ?? ()
 Previous frame inner to this frame (corrupt stack?)
 (gdb)
 
 Sorry for wasting your time with my previous post
 
 Henri

From: "Bjoern A. Zeeb" <bz@FreeBSD.org>
To: Henri Hennebert <hlh@restart.be>
Cc: Kostik Belousov <kostikbel@gmail.com>,
 bug-followup@freebsd.org
Subject: Re: ports/162588: net/cvsup: cvsup and cvsupd get signal 10 under 9.0-RC2 amd64
Date: Mon, 23 Jan 2012 12:45:24 +0000

 On 23. Jan 2012, at 12:40 , Henri Hennebert wrote:
 
 > On 01/23/2012 02:56, Kostik Belousov wrote:
 >> On Sun, Jan 22, 2012 at 06:05:29PM +0100, Henri Hennebert wrote:
 >>> On 01/21/2012 20:33, Kostik Belousov wrote:
 >>>> Please get the backtrace from the gdb to start investigating the =
 issue.
 >>>> You may need to rebuild the port and at least libc with debugging =
 symbols
 >>>> for the backtrace to be useful.
 >>>>=20
 >>>=20
 >=20
 > <--- clip --->
 >=20
 >> Can it be that something modified the /etc/group in parallel ?
 >=20
 > More simple than this, SHAME ON ME!
 >=20
 > When I compile world I do it with clang. When I add debugging symbol,
 > I forget to export my local variable: WITH_CLANG.
 >=20
 > So the reality is this: compiling libz and libc with gcc (from base)
 > all seems OK.
 >=20
 > Now the backtrace with libz compiled with clang:
 >=20
 > [root@avoriaz cvsup]# gdb /tmp/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) run /usr/local/cvsup/ports-supfile
 
 
 Just for the cross-confirmation.  Can you add a -Z there to see if the
 problem goes away then?
 
 --=20
 Bjoern A. Zeeb                                 You have to have visions!
    It does not matter how good you are. It matters what good you do!
 

From: Henri Hennebert <hlh@restart.be>
To: "Bjoern A. Zeeb" <bz@FreeBSD.org>
Cc: Kostik Belousov <kostikbel@gmail.com>, bug-followup@FreeBSD.org
Subject: Re: ports/162588: net/cvsup: cvsup and cvsupd get signal 10 under
 9.0-RC2 amd64
Date: Mon, 23 Jan 2012 14:37:40 +0100

 On 01/23/2012 13:45, Bjoern A. Zeeb wrote:
 > On 23. Jan 2012, at 12:40 , Henri Hennebert wrote:
 >
 >> On 01/23/2012 02:56, Kostik Belousov wrote:
 >>> On Sun, Jan 22, 2012 at 06:05:29PM +0100, Henri Hennebert wrote:
 >>>> On 01/21/2012 20:33, Kostik Belousov wrote:
 >>>>> Please get the backtrace from the gdb to start investigating the issue.
 >>>>> You may need to rebuild the port and at least libc with debugging symbols
 >>>>> for the backtrace to be useful.
 >>>>>
 >>>>
 >>
 >> <--- clip --->
 >>
 >>> Can it be that something modified the /etc/group in parallel ?
 >>
 >> More simple than this, SHAME ON ME!
 >>
 >> When I compile world I do it with clang. When I add debugging symbol,
 >> I forget to export my local variable: WITH_CLANG.
 >>
 >> So the reality is this: compiling libz and libc with gcc (from base)
 >> all seems OK.
 >>
 >> Now the backtrace with libz compiled with clang:
 >>
 >> [root@avoriaz cvsup]# gdb /tmp/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) run /usr/local/cvsup/ports-supfile
 >
 >
 > Just for the cross-confirmation.  Can you add a -Z there to see if the
 > problem goes away then?
 >
 
 cvsup run fine with -Z option
 
 Henri
Responsible-Changed-From-To: bz->freebsd-toolchain 
Responsible-Changed-By: bz 
Responsible-Changed-When: Mon Jan 23 13:46:25 UTC 2012 
Responsible-Changed-Why:  
Does not seem to be a problem with the port but with whatever 
clang is doing. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=162588 

From: "Bjoern A. Zeeb" <bz@FreeBSD.org>
To: Henri Hennebert <hlh@restart.be>
Cc: Kostik Belousov <kostikbel@gmail.com>,
 bug-followup@FreeBSD.org
Subject: Re: bin/162588: net/cvsup: cvsup and cvsupd get signal 10 under 9.0-RC2 amd64
Date: Mon, 23 Jan 2012 13:51:56 +0000

 On 23. Jan 2012, at 13:37 , Henri Hennebert wrote:
 
 >>> When I compile world I do it with clang. When I add debugging symbol,
 >>> I forget to export my local variable: WITH_CLANG.
 >>> 
 >>> So the reality is this: compiling libz and libc with gcc (from base)
 >>> all seems OK.
 
 Ok, I re-assigned the PR to freebsd-toolchain in the hope that the
 FreeBSD clang people will help you to investigate what's going wrong
 with libz in this case and get it fixed.   They may have totally different
 questions or might ask you try to with a newer version of clang,  ...
 
 -- 
 Bjoern A. Zeeb                                 You have to have visions!
    It does not matter how good you are. It matters what good you do!
Responsible-Changed-From-To: freebsd-toolchain->dim 
Responsible-Changed-By: dim 
Responsible-Changed-When: Mon Jan 23 14:50:40 UTC 2012 
Responsible-Changed-Why:  
I'll take this one. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=162588 

From: Dimitry Andric <dim@FreeBSD.org>
To: bug-followup@FreeBSD.org, hlh@restart.be
Cc:  
Subject: Re: bin/162588: libz partially broken when compiled with clang [was:
 net/cvsup: cvsup and cvsupd get signal 10 under 9.0-RC2 amd64]
Date: Mon, 23 Jan 2012 15:54:32 +0100

 First thing of interest are your make.conf and src.conf files.  If you
 compile world with non-standard settings, it may be the cause for libz
 breakage.

From: Henri Hennebert <hlh@restart.be>
To: Dimitry Andric <dim@FreeBSD.org>
Cc: bug-followup@FreeBSD.org
Subject: Re: bin/162588: libz partially broken when compiled with clang [was:
 net/cvsup: cvsup and cvsupd get signal 10 under 9.0-RC2 amd64]
Date: Mon, 23 Jan 2012 16:01:14 +0100

 On 01/23/2012 15:54, Dimitry Andric wrote:
 > First thing of interest are your make.conf and src.conf files. If you
 > compile world with non-standard settings, it may be the cause for libz
 > breakage.
 >
 
 [root@avoriaz etc]# egrep -v '^#' /etc/make.conf
 PRINTERDEVICE=	ps
 DOC_LANG=	en_US.ISO8859-1
 SENDMAIL_CF_DIR=/usr/local/share/sendmail/cf
 KERNCONF?=AVORIAZ
 
 .if defined(WITH_CLANG)
 .if !defined(CC) || ${CC} == "cc"
 CC=clang
 .endif
 .if !defined(CXX) || ${CXX} == "c++"
 CXX=clang++
 .endif
 .if !defined(CPP) || ${CPP} == "cpp"
 CPP=clang -E
 .endif
 NO_WERROR=
 WERROR=
 .endif # WITH_CLANG
 
 FETCH_ARGS="-ApRr4"
 WITH_BDB_VER=46
 PERL_VERSION=5.14.2
 
 [root@avoriaz etc]# cat /etc/src.conf
 WITHOUT_PROFILE=yes
 WITHOUT_LPR=yes
 WITHOUT_SENDMAIL=yes
 WITH_BIND_SIGCHASE=yes
 WITH_BIND_XML=yes
 

From: Dimitry Andric <dim@FreeBSD.org>
To: Henri Hennebert <hlh@restart.be>
Cc: bug-followup@FreeBSD.org
Subject: Re: bin/162588: libz partially broken when compiled with clang [was:
 net/cvsup: cvsup and cvsupd get signal 10 under 9.0-RC2 amd64]
Date: Mon, 23 Jan 2012 17:21:08 +0100

 On 2012-01-23 16:01, Henri Hennebert wrote:
 > On 01/23/2012 15:54, Dimitry Andric wrote:
 >> First thing of interest are your make.conf and src.conf files. If you
 >> compile world with non-standard settings, it may be the cause for libz
 >> breakage.
 >>
 >
 > [root@avoriaz etc]# egrep -v '^#' /etc/make.conf
 ...
 
 Alright, those look just fine.  I managed to reproduce the problem with
 a prepackage version of cvsup (since the port does not compile).
 
 It looks like there is some problem with stack alignment, specific to
 cvsup (or most likely, the Modula3 compiler).  Zlib's inflate_table()
 function starts with:
 
      unsigned len;               /* a code's length in bits */
 [...]
      unsigned short count[MAXBITS+1];    /* number of codes of each length */
 [...]
      for (len = 0; len <= MAXBITS; len++)
          count[len] = 0;
 
 Note, MAXBITS is 15.  On amd64, clang optimizes this loop to SSE code:
 
          xorps   %xmm0, %xmm0
          movaps  %xmm0, -64(%rbp)
          movaps  %xmm0, -80(%rbp)
 
 However, the 'movaps' instructions only work on 16-byte aligned memory,
 and apparently the stack is not 16-byte aligned in this particular case.
 
 It looks like this only happens with ezm3 compiled applications, since
 running gzip, tar, and even csup all work fine.  So maybe there is
 something in ezm3 that mis-aligns the stack...
State-Changed-From-To: feedback->closed 
State-Changed-By: dim 
State-Changed-When: Mon Feb 24 22:25:36 UTC 2014 
State-Changed-Why:  
It is extremely unlikely ezm3 will ever be fixed to use the correct 
stack alignment for amd64.  Meanwhile, cvsup is obsolete, having been 
replaced by Subversion.  Therefore I am closing this bug. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=162588 
>Unformatted:
