Packfile tests incorrectly try to read non-native packfiles.

[doughera]

I am seeing new packfile test failures on Solaris/SPARC with the released version of 2.6.0. Specifically, here's what I get:

Failed Test                         Stat Wstat Total Fail  List of Failed
-------------------------------------------------------------------------------
t/compilers/opsc/02-parse-all-ops.t    0   131    20   24  9-20
t/compilers/opsc/06-opsfile.t          0   131     7   14  1-7
t/compilers/opsc/07-emitter.t          0   131    22   44  1-22
t/pmc/packfile.t                       1   256    36   52  11-36
t/pmc/packfileconstanttable.t          1   256    16   32  1-16
t/pmc/packfiledirectory.t              1   256    20   32  5-20
t/pmc/packfilefixupentry.t             1   256     3    6  1-3
t/pmc/packfilefixuptable.t             1   256     3    6  1-3
t/pmc/packfilerawsegment.t             1   256     7   14  1-7
t/pmc/stringhandle.t                   1   256    25    1  11
10 tests and 717 subtests skipped.
Failed 10/355 test scripts. 113/12427 subtests failed.
Files=355, Tests=12427, 1466 wallclock secs (915.86 cusr + 256.53 csys = 1172.39 CPU)
Failed 10/355 test programs. 113/12427 subtests failed.

t/pmc/packfile
t/pmc/packfileconstanttable
t/pmc/packfiledirectory
t/pmc/packfilefixupentry
t/pmc/packfilefixuptable
t/pmc/packfilerawsegment
    All fail with:
        cvt_num12_num8_le: long double conversion unsupported

These failures are new for 2.6.0. I have no idea why the test is trying to do this conversion. It should only be reading native packfiles. I didn't think reading non-native packfiles was supported.

For completeness, here are the other failures:

t/compilers/opsc/02-parse-all-ops
t/compilers/opsc/06-opsfile
t/compilers/opsc/07-emitter
    All fail with:
        Parrot VM: PANIC: Out of mem!

These tests have consistently failed this way ever since the opsc merge. (This system is particularly starved for memory.)

t/pmc/stringhandle
    Fails with:
        Parrot VM: PANIC: Out of mem!

This test has consistently failed ever since the immutable strings were merged.

Summary of my parrot 2.6.0 (r0) configuration:
  configdate='Wed Jul 21 15:20:09 2010 GMT'
  Platform:
    osname=solaris, archname=sun4-solaris
    jitcapable=0, jitarchname=nojit,
    jitosname=solaris, jitcpuarch=sun4
    execcapable=0
    perl=perl5.8
  Compiler:
    cc='cc', ccflags=' -DDISABLE_GC_DEBUG=1 -DNDEBUG -DHAS_GETTEXT',
  Linker and Libraries:
    ld='cc', ldflags=' -L/usr/lib -L/usr/ccs/lib -L/opt/SUNWspro/SC4.2/lib -L/usr/local/lib ',
    cc_ldflags='',
    libs='-lsocket -lnsl -ldl -lm -lpthread -lrt -lintl'
  Dynamic Linking:
    share_ext='.so', ld_share_flags='-G -L/usr/lib -L/usr/ccs/lib -L/opt/SUNWspro/SC4.2/lib -L/usr/local/lib',
    load_ext='.so', ld_load_flags='-G -L/usr/lib -L/usr/ccs/lib -L/opt/SUNWspro/SC4.2/lib -L/usr/local/lib'
  Types:
    iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4,
    ptrsize=4,  byteorder=4321,
    nv=double, numvalsize=8, doublesize=8, longdoublesize=16

[doughera]

I'm not sure what, exactly, these tests are supposed to be testing. However, the problem that shows up here seems to be a reappearance of TT #357, where the release manager guide explicitly instructs the release manager to generate new .pbc files and include them in the release without ever having them tested on other systems.

[doughera]

I have changed the title of this ticket to more accurately reflect one of the main problems: The packfile tests are simply wrong. The binary packfiles used in the tests are generated on one particular system, but the test assumes they can be read on all systems. That is simply not true, as this ticket demonstrates. Some of the conversions are supported, but others are not. Until portable packfiles are implemented, this test should be skipped. Alternatively, the packfiles required for the test could be natively generated on the system as part of the build process.

[rurban@…]

2010/8/5 Parrot <parrot-tickets@lists.parrot.org>:
> #1712: Packfile tests incorrectly try to read non-native packfiles.
> ----------------------+-----------------------------------------------------
>  Reporter:  doughera  |       Owner:
>     Type:  bug       |      Status:  new
>  Priority:  normal    |   Milestone:
> Component:  none      |     Version:  trunk
>  Severity:  medium    |    Keywords:
>     Lang:            |       Patch:
>  Platform:            |
> ----------------------+-----------------------------------------------------
>
> Comment(by doughera):
>
>  I have changed the title of this ticket to more accurately reflect one of
>  the main problems:  The packfile tests are simply wrong.  The binary
>  packfiles used in the tests are generated on one particular system, but
>  the test assumes they can be read on all systems.  That is simply not
>  true, as this ticket demonstrates.  Some of the conversions are supported,
>  but others are not.  Until portable packfiles are implemented, this test
>  should be skipped.  Alternatively, the packfiles required for the test
>  could be natively generated on the system as part of the build process.

This is simply not true.
The tests are right, the native pbcs were wrong.
The release manager simply forgot to update these pbc's as kid has shown.
Generating and testing pseudo-pbc's will please the tests but will not
check for real failure cases.

The test should be improved to check for forgotton updates maybe, for newbies.

Or just provide packfile version portability as it was designed this
way but deleted by Allison to get out v1.0.

Your are once again trying to harm to keep pbc platform portable by
disabling these tests (the hilarious TT #357),
on the ground that
1) pbc are not platform portable (which is not true until shown
otherwise), and will never get detected if someone
will break it and the native pbc tests will be disabled again,
or 2) that my tests are bad, which is also not true.
Unsupported conversions should be maintained in my TT #357 testmatrix,
until someone comes
along and apply my old patches to support the yet unsupported conversions.
-- 
Reini Urban
http://code.google.com/p/cygwin-rurban/source/browse/trunk/release/parrot#parrot/patches

[doughera]

Replying to rurban@…:

1) pbc are not platform portable (which is not true until shown otherwise),

The original failure I reported above was:

 cvt_num12_num8_le: long double conversion unsupported

[NotFound]

Parrot should read non-native pbc, but these tests are for testing other things, the ones in t/native_pbc are fr that. They are skipped because of the known problems, and by reusing the same binarires for the packfile test we reproduce the same problems we are trying to skip. This is insane.

The packfile tests should use its own pbc files, natively generated in the build system.

[NotFound]

Created and used a pbc file for most tests in r48561

[NotFound]

Created a pbc file for the packfile annotations tests, and delete the annotations files in native_pbc, which weren't related to native_pbc

This completes the tasks related to this ticket. The native_pbc own issues can be discussed in TT #357

Ticket left open for a now, will close in a few days unless something unexpected happens.

[jkeenan]

Replying to NotFound:

Ticket left open for a now, will close in a few days unless something unexpected happens.

See TT #1750.

kid51

[NotFound]

Problems with the new pbc files for the packfile tests are only marginally related with this ticket, so I'm closing it.