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.