FAQ
Under 5.10.0, Solaris, with 64 bit integers, ext Storable still fails
badly.
Let me know what other information I can include to help get this
resolved.

ext/Storable/t/attach_errors..................................FAILED--
expected 35 tests, saw 0
ext/Storable/t/attach_singleton...............................FAILED--
expected 11 tests, saw 0
ext/Storable/t/blessed........................................FAILED--
no leader found
ext/Storable/t/canonical......................................FAILED--
no leader found
ext/Storable/t/circular_hook..................................FAILED--
no leader found
ext/Storable/t/code...........................................FAILED--
expected 59 tests, saw 0
ext/Storable/t/compat01.......................................skipped
ext/Storable/t/compat06.......................................FAILED--
no leader found
ext/Storable/t/croak..........................................FAILED--
no leader found
ext/Storable/t/dclone.........................................FAILED--
no leader found
ext/Storable/t/downgrade......................................FAILED--
no leader found
ext/Storable/t/file_magic.....................................FAILED--
no leader found
ext/Storable/t/forgive........................................FAILED--
no leader found
ext/Storable/t/freeze.........................................FAILED--
no leader found
ext/Storable/t/integer........................................FAILED--
no leader found
ext/Storable/t/interwork56....................................FAILED--
no leader found
ext/Storable/t/just_plain_nasty...............................FAILED--
no leader found
ext/Storable/t/lock...........................................FAILED--
no leader found
ext/Storable/t/malice.........................................FAILED--
no leader found
ext/Storable/t/overload.......................................FAILED--
no leader found
ext/Storable/t/recurse........................................FAILED--
no leader found
ext/Storable/t/restrict.......................................FAILED--
no leader found
ext/Storable/t/retrieve.......................................FAILED--
no leader found
ext/Storable/t/sig_die........................................FAILED--
expected 1 tests, saw 0
ext/Storable/t/store..........................................FAILED--
no leader found
ext/Storable/t/threads........................................FAILED--
no leader found
ext/Storable/t/tied_hook......................................FAILED--
no leader found
ext/Storable/t/tied_items.....................................FAILED--
no leader found
ext/Storable/t/tied...........................................FAILED--
no leader found
ext/Storable/t/utf8hash.......................................FAILED--
no leader found
ext/Storable/t/utf8...........................................FAILED--
no leader found
ext/Storable/t/weak...........................................FAILED--
no leader found
On Jul 2, 2008, at 12:39 AM, Paul Fenwick via RT wrote:

According to our records, your request regarding
"Storable seg faults under perl 5.8.0 solaris, maximal 64bit"
has been resolved.

If you have any further questions or concerns, please respond to
this message.

For other topics, please create a new ticket.

Please don't feel obligated to say "Thanks" or "Kudos" or "I owe you
a beer" -- if you respond to this message it will reopen the ticket.
If you must, please send email directly to the person who handled
your ticket, and not to the tracking system.

<URL: http://rt.perl.org/rt3/Ticket/Display.html?id=18049 >

Search Discussions

  • Bram at Jul 5, 2008 at 7:19 pm

    Citeren Drew Schatt <schatt@schatt.com>:

    Under 5.10.0, Solaris, with 64 bit integers, ext Storable still fails badly.
    Let me know what other information I can include to help get this resolved.
    Can you send the output of perl -V?
    Was it compiled with -Duse64bitall or with -Duse64bitint?

    On cpanteters I see the following reports of Solaris for Storable
    (from 5.10.0):

    http://www.nntp.perl.org/group/perl.cpan.testers/2008/06/msg1668441.html :
    use64bitint=undef, use64bitall=undef

    http://www.nntp.perl.org/group/perl.cpan.testers/2008/04/msg1296110.html :
    use64bitint=define, use64bitall=undef

    http://www.nntp.perl.org/group/perl.cpan.testers/2007/11/msg811340.html
    use64bitint=define, use64bitall=undef


    And/or is it possible that you build perl-current (blead) to see if
    there is an improvement there? (check perldoc perlhack)

    Kind regards,

    Bram
  • Brian Fraser via RT at Apr 27, 2012 at 3:45 pm

    On Sat Jul 05 12:20:00 2008, p5p@perl.wizbit.be wrote:
    Citeren Drew Schatt <schatt@schatt.com>:
    Under 5.10.0, Solaris, with 64 bit integers, ext Storable still
    fails badly.
    Let me know what other information I can include to help get this
    resolved.

    Can you send the output of perl -V?
    Was it compiled with -Duse64bitall or with -Duse64bitint?

    On cpanteters I see the following reports of Solaris for Storable
    (from 5.10.0):

    http://www.nntp.perl.org/group/perl.cpan.testers/2008/06/msg1668441.html
    :
    use64bitint=undef, use64bitall=undef

    http://www.nntp.perl.org/group/perl.cpan.testers/2008/04/msg1296110.html
    :
    use64bitint=define, use64bitall=undef

    http://www.nntp.perl.org/group/perl.cpan.testers/2007/11/msg811340.html
    use64bitint=define, use64bitall=undef


    And/or is it possible that you build perl-current (blead) to see if
    there is an improvement there? (check perldoc perlhack)

    Kind regards,

    Bram
    Turns out that under sparc, use64bitint and use64bitall are implicitly
    enabled, so that wasn't it.

    But in any case, these failures appear to be gone in newer versions of
    Perl, so I vote to close this.


    ---
    via perlbug: queue: perl5 status: open
    https://rt.perl.org:443/rt3/Ticket/Display.html?id=18049
  • Nicholas Clark at May 3, 2012 at 10:24 am

    On Fri, Apr 27, 2012 at 08:45:41AM -0700, Brian Fraser via RT wrote:

    Turns out that under sparc, use64bitint and use64bitall are implicitly
    enabled, so that wasn't it.

    But in any case, these failures appear to be gone in newer versions of
    Perl, so I vote to close this.
    Brian has now also built 5.10.0 on his Sparc Solaris machine, 64 bit, and
    can't replicate it.

    Looking at the original bug report:

    Received signal #11, SIGSEGV [default]
    siginfo: SIGSEGV SEGV_MAPERR addr=0x0000000C

    and

    ::stack
    Perl_sv_setiv+4(10023fc60, 0, 10036b3a0, 23fc00, 100000000, 1)
    Storable.so`init_perinterp+0x150(0, 38, 0, 115908, 0, 100270eb0)
    Storable.so`boot_Storable+0x7d4(570, 10023fc60, 10023fc60, ffffffff7d519638, 400, 8)


    I think that it's attempting to read the SvFLAGS() on a NULL SV pointer:

    void
    Perl_sv_setiv(pTHX_ register SV *sv, IV i)
    {
    dVAR;
    SV_CHECK_THINKFIRST_COW_DROP(sv);
    switch (SvTYPE(sv)) {


    which will be at offset 0xC on a machine with 64 bit addresses (and a 32 bit
    U32 types. ie not-a-Cray)

    Which "can't happen", as the calling code should have allocated a new SV
    already, and be dereferencing it via SvRV().

    Given that the build is optimised:


    optimize='-O',

    it's reminding me of problems we've had with another routine in sv.c which
    Sun's (current) compiler doesn't like at -xO3.

    So I'm not sure whether it's a subtle bug in the compiler's optimiser, or
    a subtle bug in the perl source code. In that, the perl source code is
    strictly written in "something not entirely unlike C", given that it
    breaches the C standard's requirements on aliasing, accessing the same data
    via cast and uncast pointers left right and centre.
    (If the source *were* strictly conformant, we'd not be insisting that gcc
    compile it with -fno-strict-aliasing)

    But I think we have to close the bug as we know that current Sparc compilers
    can build the 5.10.0 code 64 bit and pass tests.

    Nicholas Clark

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupperl5-porters @
categoriesperl
postedJul 5, '08 at 7:11a
activeMay 3, '12 at 10:24a
posts4
users4
websiteperl.org

People

Translate

site design / logo © 2021 Grokbase