develooper Front page | perl.perl5.porters | Postings from May 2013

Re: [perl #118055] miniperl fails with SIGBUS on sparc(usethreads+use64bitint)

Thread Previous | Thread Next
Andy Dougherty
May 25, 2013 14:58
Re: [perl #118055] miniperl fails with SIGBUS on sparc(usethreads+use64bitint)
Message ID:
On Fri, 24 May 2013, Nicholas Clark wrote:

> On Fri, May 24, 2013 at 10:30:09AM +0300, Niko Tyni wrote:
> > On Wed, May 22, 2013 at 01:26:03PM -0700, Nicholas Clark via RT wrote:
> > > On Wed, May 22, 2013 at 10:39:53PM +0300, Niko Tyni wrote:
> > 
> > > I had an insight on the tram. All sorts of complex hacks are complex...
> > > 
> > > > Thanks for looking at this. I'm happy to test anything you come up with. 
> > 
> > > Would be nice to test this with & without -Duse64bitint on as many
> > > architectures as practical. (I can get to x86_64, x86, sparc and mips, but
> > > not tonight)
> > 
> > I tested with v5.18.0 and a "backported" version of the patch. All tests
> > pass with GCC 4.6.3 and -Dusethreads, both with and without -Duse64bitint,
> > on these Debian platforms:
> > 
> > armhf   (ARM hard-float, 32bit)
> > ia64    (Itanium, 64bit)
> > mips    (32bit, big endian)
> > mipsel  (32bit, little endian)
> > powerpc (32bit)
> > s390    (IBM S/390, 31bit)
> > s390x   (IBM S/390  64bit)
> > sparc   (32bit)
> Thanks. It also passed on everything I tried it on. I've pushed it to blead.

Thank you.  So far it's working fine for me and I anticipate no problems.  
It's just taking a long time to actually finish.  I'll report back when it 

Meanwhile, what would you think about tweaking it like this:

diff --git a/op.c b/op.c
index 792e8d6..fd69c56 100644
--- a/op.c
+++ b/op.c
@@ -175,7 +175,7 @@ Perl_Slab_Alloc(pTHX_ size_t sz)
      || (CvSTART(PL_compcv) && !CvSLABBED(PL_compcv)))
 	return PerlMemShared_calloc(1, sz);
-#if defined(USE_ITHREADS) && IVSIZE > U32SIZE
+#if defined(USE_ITHREADS) && IVSIZE > U32SIZE && !defined(__x86_64__)
     /* Work around a goof with alignment on our part. For sparc32 (and
        possibly other architectures), if built with -Duse64bitint, the IV
        op_pmoffset in struct pmop should be 8 byte aligned, but the slab

As far as I am aware, the alignment isn't an issue on x86_64, but there is 
a small, but barely measureable, cost to the if(sz == sizeof(struct pmop)) 
test even in cases where it isn't used.  Fiddling a bit with perbench 
benchmarks, this modified version of one of the hash tests:

my $i = "abcdefg";
for (1..2000) {
    for my $j (1..2000) {
	$hash{$i} = $j;

my $k;
foreach $k (keys %hash) {
   my $v = $hash{$k};

ran slightly quicker on x86_64 (differences were consistently at the 2-3 
sigma level as reported by dumbbench) with that suggested tweak.

> Sadly the two available sparc machines at the GCC compile farm are scheduled
> to be decommissioned at the end of June, so I probably won't be able to test
> on sparc for much longer. However, it does seem that the kernel bug is fixed.
> Previously the test suite had been be able to create an unkillable busy
> process. So it looks like it is now "safe" to run a blead smoker on 32 bit
> sparc Linux.

That would be nice.  I can continue to test on SPARC, but the machine 
isn't online most of the time, and is sometimes needed for other tasks, so 
I can't really run a smoker on it.

    Andy Dougherty

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About