Ticket #1712 (closed bug: fixed)

Opened 12 years ago

Last modified 11 years ago

Packfile tests incorrectly try to read non-native packfiles.

Reported by: doughera Owned by: NotFound
Priority: normal Milestone:
Component: none Version: trunk
Severity: medium Keywords:
Cc: Language:
Patch status: Platform:

Description

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

Change History

  Changed 12 years ago by 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.

  Changed 11 years ago by doughera

  • summary changed from Packfile failures in 2.6.0 on SPARC to Packfile tests incorrectly try to read non-native packfiles.

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.

follow-up: ↓ 4   Changed 11 years ago by 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

in reply to: ↑ 3   Changed 11 years ago by 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

  Changed 11 years ago by 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.

  Changed 11 years ago by NotFound

  • owner set to NotFound
  • status changed from new to assigned

  Changed 11 years ago by NotFound

Created and used a pbc file for most tests in r48561

follow-up: ↓ 9   Changed 11 years ago by 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.

in reply to: ↑ 8   Changed 11 years ago by jkeenan

Replying to NotFound:

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

See TT #1750.

kid51

  Changed 11 years ago by NotFound

  • status changed from assigned to closed
  • resolution set to fixed

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

Note: See TracTickets for help on using tickets.