I tried to understand the errors ("undefined subroutine, not a CODE ref) and added Perl_sv_dump while the SV is being registered and before call_sv. It confirmed that a code-ref was properly being registered/cached, but by the time it came to calling the PCB, its "contents" had changed (i.e "printf sv" prints same value, but Perl_sv_dump shows changes).
I'm a novice at the perl-internal reprenstations, but picked up enough bits that led to my theory :-)
This is a print from my real project, as I was caching/registering a PCB. The "SV = PVCV", the correct "module-name", "subname" and the rest of the details in the sv_dump print suggested the code-ref was correct at registration time.
SV = RV(0xa519e7c) at 0xa519e70
REFCNT = 1
FLAGS = (PADMY,ROK)
RV = 0xa51a290
SV = PVCV(0xa4fd0e8) at 0xa51a290
REFCNT = 2
FLAGS = ()
COMP_STASH = 0x98a2d30 "module-name"
...
caching perl-sub ref 173121136d in 159850504d context
Here is the output when the PCB gets called (and gives an "not a CODE ref" error).
context is 159850504d is calling 173121136d
SV = RV(0xa519e7c) at 0xa519e70
REFCNT = 1
FLAGS = (PADSTALE,PADMY)
....
Note the 'context' and 'sv' values printed are as expected. However, the details (e.g "FLAGS" and others not shown) are totally different. In addition, FLAGS says "STALE" (anything stale cannot be good). Also, it wasnt a "PVCV" anymore.
That got me thinking if somehow it was "going out of scope" (not sure thats the correct term to use)
So, I added the newSVsv() just before caching the PCB. See the revised snippet from the myModule.xs that I shared earlier.
RegisterCB2 (SV *SubRef)
CODE:
cb_ptr2 = newSVsv(SubRef);
printf("registered %lud\n", cb_ptr2);
Perl_sv_dump(orig_perl, cb_ptr2);
RETVAL = 1;
OUTPUT:
RETVAL
Note: I'vent dont anything since last night, so I may still revise this based on any test failures. Also, I will experiment with the 'modname:subname' syntax with SWIG. Will update after that.
|