develooper Front page | perl.perl5.porters | Postings from January 2019

Re: [perl #133495] perl-5.28.0 fails to build on Solaris 10

Thread Previous
From:
Leon Timmermans
Date:
January 17, 2019 02:34
Subject:
Re: [perl #133495] perl-5.28.0 fails to build on Solaris 10
Message ID:
CAHhgV8iQtFnHh58pScnGVDtw7ixS_39wQAKY1+Fdw2wT7h8_xw@mail.gmail.com
On Wed, Jan 16, 2019 at 3:47 PM Fabian Groffen via RT
<perlbug-followup@perl.org> wrote:
>
> On Wed, 16 Jan 2019 01:50:32 -0800, grobian@gentoo.org wrote:
> > Thread 2 received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread 1 (LWP 1)]
> >  0x0004562c in zaphod32_hash_with_state (key_len=29,
> >     key=0x26d036 "dist/Exporter/lib/Exporter.pm", state_ch=<optimized
> > out>)
> >     at zaphod32_hash.h:280
> > 280                 v1 -= U8TO32_LE(key+0);
>
> Sorry I didn't report this at my first message.  I just found a bit of time to look into this.
>
> my Configure run somehow found:
>
> try.c: In function 'main':
> try.c:46:28: warning: format '%x' expects argument of type 'unsigned int', but  argument 2 has type 'long unsigned int' [-Wformat=]
>       printf("read failed (%x)\n", *up);
>                            ~^      ~~~
>                            %lx
> try.c:56:29: warning: format '%x' expects argument of type 'unsigned int', but  argument 2 has type 'long unsigned int' [-Wformat=]
>       printf("write failed (%x)\n", *up);
>                             ~^      ~~~
>                             %lx
> (Testing for character data alignment may crash the test.  That's okay.)
> You can access character data pretty unalignedly.
>
> This is obviously wrong on sparc.  The check also fails on 5.26.2 but for some reason no bus-error there.  I manually set d_u32align and that made the 5.28.0 build succeed.

That is most helpful. That macro has two implementations, one for
platforms little endian platforms without alignment requirement and
one for platforms with requirements. It clearly picks the wrong
options here.

It's not just that, it picks the wrong one (the aligned version) on
x64 as well. This appears to be caused by not taking into account
64bitness. That doesn't explain why it thinks it can access those
bytes unalignedly on SPARC though. Could an overeager optimizer cause
it not to fail? What is the autodetected value of d_u32align when it
does work?

Yves added some hashing code in 5.27 that made usage of this macro,
AFAICT it wasn't used anywhere except in an optimization in
Digest::MD5. I guess that's why we never noticed something was broken
about it.

Leon

Thread Previous


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