NetBSD Problem Report #44902

From tron@zhadum.org.uk  Sat Apr 23 18:32:21 2011
Return-Path: <tron@zhadum.org.uk>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id 6E25363B842
	for <gnats-bugs@gnats.NetBSD.org>; Sat, 23 Apr 2011 18:32:21 +0000 (UTC)
Message-Id: <20110423183217.50943AF4B@sheridan.zhadum.org.uk>
Date: Sat, 23 Apr 2011 19:32:17 +0100 (BST)
From: tron@zhadum.org.uk
Reply-To: tron@zhadum.org.uk
To: gnats-bugs@gnats.NetBSD.org
Subject: "pkgsrc/lang/perl5" crashes during build
X-Send-Pr-Version: 3.95

>Number:         44902
>Category:       port-sparc64
>Synopsis:       "pkgsrc/lang/perl5" crashes during build
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-sparc64-maintainer
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Apr 23 18:35:00 +0000 2011
>Closed-Date:    Fri Apr 29 20:22:38 +0000 2011
>Last-Modified:  Fri Apr 29 22:20:02 +0000 2011
>Originator:     tron@zhadum.org.uk
>Release:        NetBSD 5.99.49 2011-04-23 sources
>Organization:
Matthias Scheler                                  http://zhadum.org.uk/
>Environment:
System: NetBSD sheridan.zhadum.org.uk 5.99.49 NetBSD 5.99.49 (SHERIDAN) #1: Sat Apr 23 15:55:58 BST 2011 tron@excalibur.zhadum.org.uk:/Volumes/Sources/obj/sys/arch/sparc64/compile/SHERIDAN sparc64
Architecture: sparc64
Machine: sparc64
>Description:
The "perl5" cannot be built because the "miniperl" binary crashes:

--- lib/Config_git.pl ---
LD_LIBRARY_PATH=/export/scratch/tron/obj/lang/perl5/work.sheridan/perl-5.12.2  ./miniperl -Ilib make_patchnum.pl
[1]   Bus error (core dumped) LD_LIBRARY_PATH=...
*** [lib/Config_git.pl] Error code 138

The stack trace indicated that it dies with "libpthread":

Core was generated by `miniperl'.
Program terminated with signal 10, Bus error.
#0  0x0000000040b067a4 in pthread_getspecific () from /usr/lib/libpthread.so.1
(gdb) where
#0  0x0000000040b067a4 in pthread_getspecific () from /usr/lib/libpthread.so.1
#1  0x00000000001a7d64 in Perl_safesysfree (where=0x410b9c28) at util.c:230
#2  0x0000000000217460 in Perl_sv_clear (my_perl=0x41005000, sv=0x41060618)
    at sv.c:5865
#3  0x0000000000218038 in Perl_sv_free2 (my_perl=0x41005000, sv=0x41060618)
    at sv.c:5985
#4  0x00000000002983c8 in Perl_free_tmps (my_perl=0x41005000) at scope.c:167
#5  0x00000000003b4fdc in perl_run (my_perl=0x41005000) at perl.c:2240
#6  0x0000000000388ea0 in main (argc=3, argv=0xffffffffffffa508, 
    env=0xffffffffffffa528) at miniperlmain.c:117

As the package builds fine under NetBSD/amd64 5.1_STABLE and
NetBSD/i386 5.99.49 I assume it is a problem with TLS under NetBSD/sparc64.

>How-To-Repeat:
cd pkgsrc/lang/perl5
make

>Fix:
Not known.

>Release-Note:

>Audit-Trail:
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-sparc64/44902: "pkgsrc/lang/perl5" crashes during build
Date: Sat, 23 Apr 2011 21:47:20 +0200

 On Sat, Apr 23, 2011 at 06:35:00PM +0000, tron@zhadum.org.uk wrote:
 > The "perl5" cannot be built because the "miniperl" binary crashes:

 This is what the /usr/src/tests/lib/libc/setjmp/t_threadjmp.c test program
 tests (which currently fails). I'm looking into it.

 Martin

From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/44902 CVS commit: src/lib/libc/arch/sparc64/gen
Date: Wed, 27 Apr 2011 21:08:48 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Wed Apr 27 21:08:48 UTC 2011

 Modified Files:
 	src/lib/libc/arch/sparc64/gen: longjmp.c setjmp.S sigsetjmp.S

 Log Message:
 Fix offsets used in the assembly code to save global registers into a
 jmp_buf, add a compile time assert to catch this kind of divergence
 in the C code.
 Move the fixed "%npc = %pc + 4" computation to longjmp, this frees
 the sigcontext sc_npc value. Use this space to save the savemask
 for siglongjmp (we have run out of space behind the globals).
 Fixes the tests/lib/libc/setjmp/t_threadjmp tests, and also hopefully
 fixes PR port-sparc64/44902.


 To generate a diff of this commit:
 cvs rdiff -u -r1.2 -r1.3 src/lib/libc/arch/sparc64/gen/longjmp.c
 cvs rdiff -u -r1.7 -r1.8 src/lib/libc/arch/sparc64/gen/setjmp.S
 cvs rdiff -u -r1.8 -r1.9 src/lib/libc/arch/sparc64/gen/sigsetjmp.S

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: Matthias Scheler <tron@zhadum.org.uk>
To: gnats-bugs@NetBSD.org
Cc: port-sparc64-maintainer@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: PR/44902 CVS commit: src/lib/libc/arch/sparc64/gen
Date: Fri, 29 Apr 2011 21:17:24 +0100

 On Wed, Apr 27, 2011 at 09:10:15PM +0000, Martin Husemann wrote:
 >  Module Name:	src
 >  Committed By:	martin
 >  Date:		Wed Apr 27 21:08:48 UTC 2011
 >  
 >  Modified Files:
 >  	src/lib/libc/arch/sparc64/gen: longjmp.c setjmp.S sigsetjmp.S
 >  
 >  Log Message:
 >  Fix offsets used in the assembly code to save global registers into a
 >  jmp_buf, add a compile time assert to catch this kind of divergence
 >  in the C code.
 >  Move the fixed "%npc = %pc + 4" computation to longjmp, this frees
 >  the sigcontext sc_npc value. Use this space to save the savemask
 >  for siglongjmp (we have run out of space behind the globals).
 >  Fixes the tests/lib/libc/setjmp/t_threadjmp tests, and also hopefully
 >  fixes PR port-sparc64/44902.

 I can confirm that I can now build the "perl5" package with threading
 enabled without problems on my NetBSD/sparc64 5.99.51 system.

 Please close this PR, and thanks a lot for the fix.

 	Kind regards

 -- 
 Matthias Scheler                                  http://zhadum.org.uk/

State-Changed-From-To: open->closed
State-Changed-By: martin@NetBSD.org
State-Changed-When: Fri, 29 Apr 2011 20:22:38 +0000
State-Changed-Why:
fixed - thanks for the report!


From: Matthias Scheler <tron@zhadum.org.uk>
To: port-sparc64-maintainer@netbsd.org
Cc: gnats-bugs@NetBSD.org
Subject: Re: PR/44902 CVS commit: src/lib/libc/arch/sparc64/gen
Date: Fri, 29 Apr 2011 21:46:05 +0100

 On Fri, Apr 29, 2011 at 09:17:24PM +0100, Matthias Scheler wrote:
 > On Wed, Apr 27, 2011 at 09:10:15PM +0000, Martin Husemann wrote:
 > >  Module Name:	src
 > >  Committed By:	martin
 > >  Date:		Wed Apr 27 21:08:48 UTC 2011
 > >  
 > >  Modified Files:
 > >  	src/lib/libc/arch/sparc64/gen: longjmp.c setjmp.S sigsetjmp.S
 > >  
 > >  Log Message:
 > >  Fix offsets used in the assembly code to save global registers into a
 > >  jmp_buf, add a compile time assert to catch this kind of divergence
 > >  in the C code.
 > >  Move the fixed "%npc = %pc + 4" computation to longjmp, this frees
 > >  the sigcontext sc_npc value. Use this space to save the savemask
 > >  for siglongjmp (we have run out of space behind the globals).
 > >  Fixes the tests/lib/libc/setjmp/t_threadjmp tests, and also hopefully
 > >  fixes PR port-sparc64/44902.
 > 
 > I can confirm that I can now build the "perl5" package with threading
 > enabled without problems on my NetBSD/sparc64 5.99.51 system.
 > 
 > Please close this PR, and thanks a lot for the fix.

 It seems unfortunately that the above change causes a new problem.
 Since upgrading my system "bash" stopped working. It crashes while
 running "configure" scripts (e.g. while building the package
 "pkgsrc/databases/mysql51-client"). Here is a stack trace:

 tron@sheridan:/export/scratch/tron/obj/shells/bash/work.sheridan/bash-4.2>gdb bash bash.core
 GNU gdb 6.5
 Copyright (C) 2006 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 "sparc64--netbsd"...
 Reading symbols from /usr/lib/libterminfo.so.1...done.
 Loaded symbols for /usr/lib/libterminfo.so.1
 Reading symbols from /usr/lib/libintl.so.1...done.
 Loaded symbols for /usr/lib/libintl.so.1
 Reading symbols from /usr/lib/libc.so.12...done.
 Loaded symbols for /usr/lib/libc.so.12
 Reading symbols from /usr/libexec/ld.elf_so...done.
 Loaded symbols for /usr/libexec/ld.elf_so
 Core was generated by `bash'.
 Program terminated with signal 10, Bus error.
 #0  0x00000000409bf18c in _longjmp () from /usr/lib/libc.so.12
 (gdb) where
 #0  0x00000000409bf18c in _longjmp () from /usr/lib/libc.so.12

 	Kind regards

 -- 
 Matthias Scheler                                  http://zhadum.org.uk/

From: Hauke Fath <hauke@Espresso.Rhein-Neckar.DE>
To: Matthias Scheler <tron@zhadum.org.uk>
Cc: gnats-bugs@NetBSD.org, port-sparc64-maintainer@NetBSD.org
Subject: Re: PR/44902 CVS commit: src/lib/libc/arch/sparc64/gen
Date: Fri, 29 Apr 2011 22:30:27 +0200

 At 21:17 Uhr +0100 29.4.2011, Matthias Scheler wrote:
 >>  Modified Files:
 >>  	src/lib/libc/arch/sparc64/gen: longjmp.c setjmp.S sigsetjmp.S
 >>
 >>  Log Message:
 >>  Fix offsets used in the assembly code to save global registers into a
 >>  jmp_buf, add a compile time assert to catch this kind of divergence
 >>  in the C code.
 >>  Move the fixed "%npc = %pc + 4" computation to longjmp, this frees
 >>  the sigcontext sc_npc value. Use this space to save the savemask
 >>  for siglongjmp (we have run out of space behind the globals).
 >>  Fixes the tests/lib/libc/setjmp/t_threadjmp tests, and also hopefully
 >>  fixes PR port-sparc64/44902.

 Could this be relevant for sparc? Among the many issues I see with an smp
 sparc -curent installation is miniperl dying during the perl5 build...

 	hauke

 --
 "It's never straight up and down"     (DEVO)


From: Martin Husemann <martin@duskware.de>
To: Hauke Fath <hauke@Espresso.Rhein-Neckar.DE>
Cc: Matthias Scheler <tron@zhadum.org.uk>, gnats-bugs@NetBSD.org,
	port-sparc64-maintainer@NetBSD.org
Subject: Re: PR/44902 CVS commit: src/lib/libc/arch/sparc64/gen
Date: Sat, 30 Apr 2011 00:18:00 +0200

 On Fri, Apr 29, 2011 at 10:30:27PM +0200, Hauke Fath wrote:
 > Could this be relevant for sparc? Among the many issues I see with an smp
 > sparc -curent installation is miniperl dying during the perl5 build...

 Yes, sparc fails the "t_threadjmp" test as well (but for other reasons).
 I'm looking into that...

 Martin

>Unformatted:

Home	PR Database Search