I don't know what code is the cause of the problem.

Historically, I've been reasonably adept at using debuggers, but despite many attempts with several different debuggers, I find tracing into Perl with a debugger pointless. The nature of the run-loop dispatching means that stack traces are nearly always useless, and setting break & watch points an exercise in futility.

The most effective tool I have found for tracking down segfaults in XS code is printf. I most frequently use the following macro to track down the source of problems:

#define TAG printf( "# %s(%d)\n", __FILE__, __LINE__ )
[download]

I start by adding TAG;s at the top and bottom of each routine. The last enter tells me which routine to concentrate on. Then I tag strategic points in the routine:

SV *mapAt( SV *fileMap, U32 hiOff, U32 loOff, size_t size ) {
    SV *map = newSVpvn( "", 0 );
    void *mapAddr;
    size_t n;
TAG;
    printf( "received size: %I64d\n", size );
    ERR( mapAddr = MapViewOfFile(
        (HANDLE)SvUV( fileMap ), FILE_MAP_ALL_ACCESS,
        hiOff, loOff, size
    ));
TAG;
    if( ! size ) { // Mapping entire file
        MEMORY_BASIC_INFORMATION mi;

        ERR( VirtualQuery( mapAddr, &mi, sizeof( MEMORY_BASIC_INFORMAT
+ION ) ) );
        size = mi.RegionSize;
        printf( "Actual size mapped: %I64u\n", size );
    }

TAG;
    SvPV_set( map, mapAddr );
    SvCUR_set( map, size );
    SvLEN_set( map, size+1 );
TAG;
    return map;
}
[download]

Ideally, the macro would use fprintf( stderr,...), but using stderr within XS code under Windows blows up in horrible ways. (Due to PerlIOs layers of redefinitions of CRT entities in incompatible ways.)

It is simplistic, but it works. Once you know where your code is failing, working out why is usually not too difficult.

I also have editor macros to insert and remove the tags on the current line, but that just a nice to have.

Instead of fprintf, try Perl_warn(aTHX_ "PERL_INC_VERSION_LIST=%s\n", subdir);

try Perl_warn(...

I did. But have you ever looked at what lies behind that seemingly simple call? Debugging tools need to be simple and reliable, and Perl_warn() is neither.

When the simple act of adding the trace statement to a routine can cause it to go belly up, and the only way to track down why involves /E and wading through megabytes of post-processed C code to work out what actual code gets run, sticking to printf() is infinitely preferable.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Rip subroutines out of the XS and replace them with Perl dummies. You can even do that without changing your Perl code:

use My::XS::Module;

*My::XS::Module::xs_subroutine_1 = sub {
    # a dummy
};

*My::XS::Module::xs_subroutine_2 = sub {
    return 0; # always OK
};
[download]

That way, you can reduce the complexity as long as you have a test case that reproduces the error.

My personal guess, without seeing code, is that somewhere you don't POP enough elements of the argument stack, or have a mismatched ENTER / LEAVE pair.