139 - 128 = 11, which is SIGSEV on my system. (Check the system's kill -l.) Something is causing Perl to crash badly. That's most definitely a fail.

Suggestions on how to debug this?

A debug build might catch the problem with an assert. gdb with a debug build of Perl will say what crashed.

Something is probably segfaulting within your module's C code (or you've found a bug in Perl/XS). If all tests are passing, I guess the segfault would be happening rather late in the execution--maybe even right at cleanup.

To debug, by far the most efficient method would be to run it through an interactive debugger (or your preferred method of debugging segfaults) directly on a FreeBSD system.

Since you maintain several XS modules, my advice would be to grab an appropriate ISO of FreeBSD from http://www.freebsd.org/where.html and run it in a virtual machine, such as VirtualBox. Assuming average skill with basic OS installs, you can be debugging your module with standard development tools in under an hour.

If that option seems like too much work, you could try a web search for hosted FreeBSD shell accounts with development environments. I prefer the VM route, so I don't know of any I'd recommend off-hand.

I have a FreeBSD machine that I let CPAN authors use for testing and debugging. Email me for login details.

Thanks to all who've responded.

Yes, I have several VirtualBox VMs at hand for debugging cases like this, including a couple of different FreeBSDs. I just wasn't sure where to start, since simply running gdb didn't tell me much. I also could not duplicate the problem until I tried the Perl installed via ports. ikegami's tip to compile Perl with debugging on was helpful. I was able to see that the segfault is always happening during global clean up, after all my C/XS objects have been properly freed.

I've traced the problem to the MYMALLOC compile-time option. It only happens when that is on, which it is by default in FreeBSD ports Perl. So I'm now exploring that feature to see why it might be causing the issue.

More when I know it...

I was able to reproduce the issue with this simple .xs:

#include "EXTERN.h"
#include "perl.h"
#include "XSUB.h"

#include "ppport.h"


MODULE = Foo        PACKAGE = Foo        

void
test(class)
    char* class

    CODE:
        int ret = setenv("TESTME", "1", 0);
        warn("setenv TESTME complete with %d", ret);
[download]

compiling and running that like this:

[karpet@freebsd80 ~/src/segfault-test/Foo]$ make test
PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_h
+arness(0, 'blib/lib', 'blib/arch')" t/*.t
t/Foo....ok 1/1setenv TESTME complete with 0 at t/Foo.t line 11.      
+       
t/Foo....dubious                                                      
+       
    Test returned status 0 (wstat 139, 0x8b)
    after all the subtests completed successfully
Failed Test Stat Wstat Total Fail  List of Failed
----------------------------------------------------------------------
+---------
t/Foo.t        0   139     1    0  ??
Failed 1/1 test scripts. 0/1 subtests failed.
Files=1, Tests=1,  0 wallclock secs ( 0.05 cusr +  0.08 csys =  0.12 C
+PU)
Failed 1/1 test programs. 0/1 subtests failed.
*** Error code 255

Stop in /usr/home/karpet/src/segfault-test/Foo.

[karpet@freebsd80 ~/src/segfault-test/Foo]$ gdb /usr/local/bin/perl pe
+rl5.8.9.core 
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and y
+ou are
welcome to change it and/or distribute copies of it under certain cond
+itions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for det
+ails.
This GDB was configured as "i386-marcel-freebsd"...

warning: core file may not match specified executable file.
Core was generated by `perl5.8.9'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/local/lib/perl5/5.8.9/mach/CORE/libperl.so..
+.done.
Loaded symbols for /usr/local/lib/perl5/5.8.9/mach/CORE/libperl.so
Reading symbols from /lib/libm.so.5...done.
Loaded symbols for /lib/libm.so.5
Reading symbols from /lib/libcrypt.so.5...done.
Loaded symbols for /lib/libcrypt.so.5
Reading symbols from /lib/libutil.so.8...done.
Loaded symbols for /lib/libutil.so.8
Reading symbols from /lib/libc.so.7...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /usr/home/karpet/src/segfault-test/Foo/blib/arch/
+auto/Foo/Foo.so...done.
Loaded symbols for /usr/home/karpet/src/segfault-test/Foo/blib/arch/au
+to/Foo/Foo.so
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  0x282b85fc in free () from /lib/libc.so.7
(gdb) bt
#0  0x282b85fc in free () from /lib/libc.so.7
#1  0x2832b5eb in strnlen () from /lib/libc.so.7
#2  0x28265b00 in ?? () from /lib/libc.so.7
#3  0x28343000 in ?? () from /lib/libc.so.7
#4  0x2807b358 in ?? () from /libexec/ld-elf.so.1
#5  0xbfbfe9f8 in ?? ()
#6  0x283355ac in ?? () from /lib/libc.so.7
#7  0x2808d100 in ?? ()
#8  0x2807b358 in ?? () from /libexec/ld-elf.so.1
#9  0xbfbfe9f8 in ?? ()
#10 0x2804ed25 in dlsym () from /libexec/ld-elf.so.1
Previous frame inner to this frame (corrupt stack?)
(gdb)
[download]

that stack trace is identical to the one I'm seeing in my own module.

I've found the fix and noted it here.