A while back I submitted a module to CPAN, and it has been working its way through their testing. It had passed its first 10 systems, but on the 11th the tests show errors that I can't interpret.

The system showing the errors is described as:perl 5.10.0  s390-linux-thread-multi 2.6.5-7.315-s390. The same tests have passed on similar-looking systems, such as 5.10.0    Linux    2.6.16.60-0.31-default    s390x-linux-thread-multi. UPDATE: I developed the module under 5.8.9.

Here are the first few errors reported:
#   Failed test 'get pushed element'
#   at t/2_mmArray.t line 251.
#          got: '*main::mm_array_push'
#     expected: 'eb'

#   Failed test 'avail mem after push should == before pop'
#   at t/2_mmArray.t line 260.
#          got: '7544'
#     expected: '7560'

#   Failed test 'check first unshifted value'
#   at t/2_mmArray.t line 299.
#          got: ''
#     expected: '2009'

#   Failed test 'check 2nd unshifted value'
#   at t/2_mmArray.t line 303.
#          got: '*main::mm_array_unshift'
#     expected: ''

#   Failed test 'effect of unshifting (0-length value, normal value) o
+n avail mem'
#   at t/2_mmArray.t line 312.
#          got: '-32'
#     expected: '-16'

[download]
The full report can be seen here.

The subject module is an XS one that implements full array capability in a memory that can be shared among processes. Here is the test code (under Test::More) that led to the first error:
# test 106: push it back
is (mm_array_push ($array, n2alpha(ARRAY_SIZE - 2)), ARRAY_SIZE - 1,
    "push should return array size");

# test 107
($size, $shiftCount) = mm_array_status ($array);
is ($size, ARRAY_SIZE - 1, 
    "push should increase array size by 1");

# test 108 
is ($shiftCount, 0, 
    "push should not affect shift count");

# test 109
is (mm_array_fetch ($array, ARRAY_SIZE - 2), n2alpha(ARRAY_SIZE - 2), 
    "get pushed element");

[download]
The call to mm_array_push in test 106 increased the array size by 1 as it should, but accessing the added entry via mm_array_fetch in test 109 yields something that looks like the typeglob for the push routine. A similar problem occurred later for an unshift call, and lots of other errors followed.

Does such a result (in the context of an XS routine) look familiar to anyone? Is there anything I can add to my XS interface routines to help prevent such problems? Should I ask the CPAN testers for a retest? Advice of wise and experienced monks will be much appreciated in this matter!

cmac
http://www.animalhead.com

In reply to inscrutable error in CPAN testing by cmac

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.