Re^22: Perl crash during perl_clone

[BrowserUk]

Hm. I'm afraid that is all over my head.

Where did you get Perl_sv_dump() from? Cos it doesn't appear to be in any of the docs I have. If I try to use it (on anything) it just crashes.

The only relevant reference I've found is this by syphilis, but either form crashes my machine.

And so we (I) arrive in that dead-end where most every one of my forays into XS/internals programming ends up. The one where the only option left open is trial&error combined with cargo-culting.

The one that always reminds me of the opening lines from the A-team: If your in trouble, and if you can find it, a piece of existing working code that does something sufficiently similar to what you want to do, than you can cargo-cult it and it might work. But it probably won't work everywhere, and is likely to suffer from sporadic and random errors.

[perlmonk1729]

I found this function in perlguts, section "Examining internal data structures with the dump functions".

Thanks

[BrowserUk]

I found this function in perlguts, section "Examining internal data structures with the dump functions".

Well yeah, but that doesn't define the arguments. Not even just how many.

And it use both Perl_sv_dump() and sv_dump() in the same para implying they might be the same thing. But that post I linked suggests otherwise.

My attempts to use either here just crash.

I've been trying to wrap my brain around why your making a copy of the SV rather than just storing the SV* would make a difference, and the only thing that makes any sense is that this "mortality" thing. The SV* you receive points to a temporary SV that has been GC'd or reused by the time you try to use it.

Maybe if you incremented its refcount (the SV pointed at by the SV* you receive), then Perl would know there was another reference kicking around somewhere and not recycle it?

I thought I'd try that and it worked. This (minus the unchanged bits from above) allows me to use coderefs:

void setCallback( SV *cb1, SV* cb2, SV *cb3, SV *cb4 ) {
    int i;
    saved = Perl_get_context();
    callbacks[0] = cb1; SvREFCNT_inc( cb1 );
    callbacks[1] = cb2; SvREFCNT_inc( cb2 );
    callbacks[2] = cb3; SvREFCNT_inc( cb2 );
    callbacks[3] = cb4; SvREFCNT_inc( cb2 );
    for( i=1; i < 4; ++i ) InitializeSRWLock( &locks[ i ] );
    _beginthread( &thread1, 0, NULL );
    _beginthread( &thread2, 0, NULL );
    return;
}

END_C
$|++;

{
    package fred;
    my @c = (0) x 4;

    sub callback1 { ++$c[0]; print "PCB1: $_[0] ($c[0])"; return; }
    sub callback2 { ++$c[1]; print "PCB2: $_[0] ($c[1])"; return; }
    sub callback3 { ++$c[2]; print "PCB3: $_[0] ($c[2])"; return; }
    sub callback4 { ++$c[3]; print "PCB4: $_[0] ($c[3])"; return; }
}

setCallback( \&fred::callback1, \&fred::callback2, \&fred::callback3, 
+\&fred::callback4 );

sleep 100;

[perlmonk1729]

the only thing that makes any sense is that this "mortality" thing. The SV* you receive points to a temporary SV that has been GC'd or reused by the time you try to use it.

This was precisely my theory as well. I guess "out-of-scope" etc., werent the right phrases to describe in a perl context (I'm a "C" guy, learning Perl as needed).

Maybe if you incremented its refcount

I had just stumbled across this SvREFCNT_inc yesterday and was thinking of trying it. I'm glad to hear it worked for you.

Do you think I should still be worried about going ahead with this as the right solution? So far my testing hasnt shown any negative/unexpected results.