cmac has asked for the wisdom of the Perl Monks concerning the following question:

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'
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");
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

Replies are listed 'Best First'.
Re: inscrutable error in CPAN testing
by cdarke (Prior) on Mar 16, 2009 at 09:01 UTC
    Check your checks. Presumably you are allocating/relallocating memory somewhere, using some sort of IPC like shmem or maybe mmap. Check that the APIs called from XS are allocating enough memory, and that you are testing return values. You might also wish to check $!, or whatever mechanism you are returning errors (how do you indicate out-of-memory to the caller?). It could be that this particular tester has a low memory situation (runnning out of swap, for example).

    The large negative numbers returned by some of the tests are probably pointers and often indicate uninitialised memory - as you probably know this is common when you run out of bounds.
      The test in question allocates the minimum amount of shared memory allowed by the underlying mm module, which is 8KB. The second error message shows that 75xx of this 8K is still available at the time of the first error. Does this bear on the kind of problem you were thinking of?
        Yes, since you expected more than that to be available (7560).
Re: inscrutable error in CPAN testing
by Anonymous Monk on Mar 16, 2009 at 04:50 UTC
    Two tips, list all prerequisites modules, even the core ones ( Exporter, DynaLoader ...) and make use of Devel::PPPort.
      The problem occurs under 5.10.0. My module was developed under 5.8.9. (I'll update my problem statement with this fact also.)

      Devel::PPPort says it "attempts to bring some of the newer Perl API features to older versions of Perl". Isn't this the opposite direction from my situation?

      Also the PPPort docs have some rough spots.
      1. "the ppport.h C header file ... contains a series of macros and, if explicitly requested, functions that allow XS modules to be built using older versions of Perl". I can't see anything about how such explicit requesting is done?

      2. "the old polluting ways of original Perl modules will not be supported very far into the future, and your module will almost certainly break". My module was written in the last few months, and it's not clear how any "old polluting ways" could have snuck into it from "original Perl modules"?