That seems to work.

Aaah ... but it does matter in libdeflate-one.c, where free (and malloc) need to be implemented according to the stdlib.h specification, not according to perl's (re)definition of them. By undef'ing those 2 symbols, we ensure that the stdlib.h implementations are used.

Thank you for these insights.

I tried any number of things, but the

#undef malloc
[download]

idea was not one of them. I understand that XSUB.h or another Perl header file redefines malloc into a Perl function or macro which takes two arguments, but the thing which I still find confusing is that the error messages appear to be coming from XSUB.h yet the actual error is occurring within my C file libdeflate-one.c, so the error messages seem to assume that the error occurred on another line from where they actually did. Since the compiler is gcc it's not the fault of Microsoft Windows.

I have just spent a little time debugging another XS module on Strawberry Perl (for details see this diff) and I'd like to point out that

#undef realloc
[download]

and probably

#undef calloc
[download]

are also needed if the C code is using those as well.

There is no error message from Windows, and the GDB backtrace looks like this:

ok 1 - use Gzip::Zopfli;

Thread 1 received signal SIGSEGV, Segmentation fault.
0x00000000658f0794 in perl532!Perl_drand48_r () from C:\Strawberry\per
+l\bin\perl532.dll
(gdb) bt
#0  0x00000000658f0794 in perl532!Perl_drand48_r () from C:\Strawberry
+\perl\bin\perl532.dll
#1  0x0000000067948d63 in ?? () from C:\Users\ben\Documents\Gzip-Zopfl
+i-0.01\blib\arch\auto\Gzip\Zopfli\Zopfli.xs.dll
#2  0x000000006794985a in ?? () from C:\Users\ben\Documents\Gzip-Zopfl
+i-0.01\blib\arch\auto\Gzip\Zopfli\Zopfli.xs.dll
#3  0x0000000067949964 in ?? () from C:\Users\ben\Documents\Gzip-Zopfl
+i-0.01\blib\arch\auto\Gzip\Zopfli\Zopfli.xs.dll
#4  0x0000000067949bf4 in ?? () from C:\Users\ben\Documents\Gzip-Zopfl
+i-0.01\blib\arch\auto\Gzip\Zopfli\Zopfli.xs.dll
#5  0x000000006587b1e2 in perl532!Perl_clear_defarray () from C:\Straw
+berry\perl\bin\perl532.dll
#6  0x00000000658dfdd6 in perl532!Perl_runops_standard () from C:\Stra
+wberry\perl\bin\perl532.dll
#7  0x0000000065890eb7 in perl_run () from C:\Strawberry\perl\bin\perl
+532.dll
#8  0x00000000658f3ac8 in perl532!RunPerl () from C:\Strawberry\perl\b
+in\perl532.dll
#9  0x00000000004013c7 in ?? ()
#10 0x00000000004014fb in ?? ()
#11 0x00007ffe753d7034 in KERNEL32!BaseThreadInitThunk () from C:\WIND
+OWS\System32\kernel32.dll
#12 0x00007ffe764bd241 in ntdll!RtlUserThreadStart () from C:\WINDOWS\
+SYSTEM32\ntdll.dll
#13 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
[download]

I found out what was wrong by Googling and puzzling over this bug report. It took a few attempts before I thought of this realloc problem.