Re: Problem with building XS module on AS 1401

Steffen Mueller ([email protected]) writes:
> Check the C code generated by xsubpp. Then insert ludicrous amounts of 
> printf()'s into the code that comes after the actual C++ function 
> invocation.

I did consider that. But there is not much place for printf. This is how 
it looks like:

	RETVAL = executebatch(sqlsrv, rows_affected);
	XSprePUSH; PUSHi((IV)RETVAL);
    }
    XSRETURN(1);
}

I assume these XSPrePUSH etc are macros, and if I generated the file 
after pre-processing, there would be more place for printf. But I
ran out of steam there.

> Since you're passing around SV*'s the bug might be in the code that you 
> wrote to handle the Perl datastructures if it's more than just a simple 
> SvIV on rows_affected or SvPV_nolen() on sqlsrv. Sometimes, the time of 
> destruction of "mortal"s may not be what you expect (generally during 
> nextstate ops, though), so if you have a mortal SV that gets destroyed 
> early... err. No. Then you typically get a segmentation fault, not an 
> SV* that just happens to point at &PL_sv_undef. Nevermind my drivel. :)
 
About the only operation I do on sqlsrv is SvRV. The code for rows_affected
is

    // Return rows_affected if required.
    if (sv_rows_affected != NULL) {
        sv_setiv(sv_rows_affected, rows_affected);
    }

And it is not passed in any of the calls in the test.

Hm, I made a change in the calling code, and then hard-coded rows_affected
to be 4711 and added a tracing warn. Oh, no. Rows_affected is always 
returned correctly. It's only RETVAL that gets the wrong value.


-- 
Erland Sommarskog, Stockholm, [email protected]