Perl XS modules and CPAN testers

This happens when C malloc is used with the Perl free. It occurs with a Perl built with threads for Windows (MSWin32-x86-multi-thread). One solution of the problem is to use Perl's memory allocators Newx and Safefree as described in perlclib. Another solution may be to undefine Perl's redefinition of "free". See [Win32] "Free to wrong pool ..." error at Perlmonks.

This is caused on some systems by giving a value to CCFLAGS in Makefile.PL.

This is caused by using the prefix Perl_ when calling functions such as Perl_vwarn and Perl_croak. It can be resolved by using vwarn and croak.

This is an error which occurs on the NetBSD operating system. It requires -lgcc_s to be added to the compile line.

This is a known error with Perl on Solaris related to the use of different assemblers. See perlsolaris. This error seems to indicate something wrong with the testing computer rather than the program, and is probably not resolvable by the module programmer.

This seems to happen on Linux. The error string is on line 138 of DynaLoader.xs.

Unknown.

Related to this? https://github.com/ambs/text-ngram/pull/1/files

#define PERL_UNUSED_CONTEXT PERL_UNUSED_ARG(my_perl)

This is an error of the Microsoft C compiler. It is caused by having a variable declared in the CODE: section of an XS file. Use the PREINIT: section of the XS file instead.

This bubbles up from uses of the SvPV macro when the programmer uses a non-STRLEN variable for the length of a string on a 64-bit computer:

char * x;
unsigned xlen;
x = SvPV (sv, xlen);

It's actually possible to cause segmentation violation and other memory errors with some combinations of compilers and interpreters, so be diligent about using STRLEN for string lengths:

char * x;
STRLEN xlen;
x = SvPV (sv, xlen);

wstat is just the exit status multiplied by 256, which is the number of failed tests multiplied by 256. In the above case there are 5 failed tests, so wstat is 1280.

This error occurs in OpenBSD tests of XS modules.

The "non-zero wait status" seems to be 128 + the signal which killed the child process during a call to the system call "wait". So the signal is 10, which means "bus error". In other words, a memory error occurred during the execution which halted the test process and returned this status to the calling process.

References:

https://stackoverflow.com/questions/1101957/are-there-any-standard-exit-status-codes-in-linux

http://man.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/WCOREDUMP.2?query=wait&sec=2

http://man.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/sigaction.2?query=sigaction&sec=2

This indicates a segmentation fault error on BSD operating systems.

"Bizarre copy of ... " errors may be caused by a variety of conditions. It's actually an error from the file sv.c where it looks at a variable's type. This fatal error happens when Perl examines a scalar and cannot work out what to do with it.

Generally this indicates some kind of corruption has occurred.

For example, this has happened to me by putting a badly-formatted reference on the stack before calling a Perl routine from C. See perlcall.

Another way this has happened to me is by taking a pointer in the C to a Perl scalar, but forgetting to increment its reference count with SvREFCNT_inc, then when the scalar was eventually used, it had been overwritten, causing this error to occur.

An error with its location given as "in subroutine entry" is occuring within your XS or C code rather than in Perl and the Perl interpreter cannot give the line number. The best it can do is say that the error occurred somewhere after the subroutine that it points to.

References:

https://www.perlmonks.org/?node_id=415183

Macros clash with Windows header files

References:

https://www.perlmonks.org/?node_id=11128586

The solution is to add

#ifdef WIN32
#undef malloc
#undef free
#endif /* def WIN32 */