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
From:
Nicholas Clark
Date:
May 20, 2013 07:20
Subject:
Re: [perl #118055] miniperl fails with SIGBUS on sparc(usethreads+use64bitint)
Message ID:
20130520071942.GH3729@plum.flirble.org
On Mon, May 20, 2013 at 05:11:38AM +0200, Leon Timmermans wrote:
> On Sun, May 19, 2013 at 9:50 PM, Niko Tyni <perlbug-followup@perl.org> wrote:
> > [ Sorry about the timing, it took a week for our sparc build server to get
> >   round to building 5.18.0-RC1, and we got the result just hours after
> >   the 5.18.0 release. ]
> >
> >
> > 5.18.0 build fails on sparc with -Dusethreads -Duse64bitint.
> > miniperl gets a SIGBUS with just about any non-trivial program.

> >   4458        pmop->op_pmoffset = av_len(PL_regex_padav);
> >   (gdb) bt
> >   #0  0x0002ffcc in Perl_newPMOP (my_perl=0x26e008, type=33, flags=0) at op.c:4458
> >   #1  0x0008c56c in S_scan_subst (my_perl=0x26e008, start=0x28c8f1 "/a/b/\n") at toke.c:9650
> >   #2  0x0008421c in Perl_yylex (my_perl=0x26e008) at toke.c:8353
> >   #3  0x000957e8 in Perl_yyparse (my_perl=0x26e008, gramtype=258) at perly.c:341
> >   #4  0x00018294 in S_parse_body (my_perl=0x26e008, env=0x0, xsinit=0x4cfa4 <xs_init>) at perl.c:2309
> >   #5  0x00016d94 in perl_parse (my_perl=0x26e008, xsinit=0x4cfa4 <xs_init>, argc=3, argv=0xffffdd04,
> >       env=0x0) at perl.c:1626
> >   #6  0x0004ce68 in main (argc=3, argv=0xffffdd04, env=0xffffdd14) at miniperlmain.c:111
> 
> This smells like an alignment issue.

Agree. Been caught out by these before.

> > Bisecting says the first bad commit is
> >
> > commit 8be227ab5eaa23f2d21fd15f70190e494496dcbe
> > Author: Father Chrysostomos <sprout@cpan.org>
> > Date:   Sat Jun 23 09:54:31 2012 -0700
> >
> >     CV-based slab allocation for ops
> 
> That makes perfect sense with my theory. Probably that allocator
> should do some padding to 64-bit boundaries.

I think it needs to be to the alignment of the largest thing in an OP.
Which on a 32 bit sparc with 64 bit IVs is (currently) 64 bits:


struct pmop {
    BASEOP
    OP *	op_first;
    OP *	op_last;
#ifdef USE_ITHREADS
    IV          op_pmoffset;
#else
    REGEXP *    op_pmregexp;            /* compiled expression */
#endif


But really, that "IV" should be something else. "STRLEN", I think, or even
just size_t, because it's being used as an array index, and arrays can't
be 64 bits large on a 32 bit system.

We can't change that for 5.18.x. But as well as the alignment thing, we
should fix it for the future.

Nicholas Clark

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About