Re^11: Segfault on second (identical) call to a sub

I'm no expert on XS files either, which is why I usually let Inline::C handle that side of things ... but I don't think 'data' should be safefree()'d ... and I wish you had pointed it out sooner :-)

I got sidetracked into thinking that there must be something bodgey in the way the GD::Image objects were being created.

You could probably go a little further and not even declare and assign a value to 'data'. I think one could just as well write

RETVAL = (GD__Image) gdImageCreateFromGdPtr(len,(void*)SvPV(imageData,
+ len));
[download]

but that's only a minor point.
It's unclear to me how 'len' gets assigned the appropriate value for when it's needed ... but it seems to happen ok.

You should probably go to http://rt.cpan.org/Public/Dist/Display.html?Name=GD and report the bug there - or at least let the author know.

Well spotted !!

Cheers,
Rob

Comment on Re^11: Segfault on second (identical) call to a sub Download Code

Replies are listed 'Best First'.
Re^12: Segfault on second (identical) call to a sub by BrowserUk (Patriarch) on Feb 07, 2006 at 07:23 UTC
and I wish you had pointed it out sooner :-) I wish I'd noticed it earlier :) It was only by comparing your Inline C to the XS that it stood out. Previously I'd just checked that allocs and frees were being done with XS macros and not crt functions. Thanks again for your help. It's unclear to me how 'len' gets assigned the appropriate value for when it's needed I wondered that too, but if you unwind the SvPV() macro, you eventually realise that the len parameter passed to it is not used to indicate the length of anything, but rather is used to retrieve the length of the data held in the SV. This is done using the SvCUR() macro. It takes a bit of unwinding and could probably bear a mention in perlapi. I've updated GD.xs 2.30 locally with this and got rid of a few unused var warnings which allowed it to compile clean and pass it's test suit. I then thrashed it for a while calling the OP sub and another like it that used GD2 data in a loop and it seems fine. I've generated a patch against 2.30 and sent it directly to L.Stein along with a warning that I don't really know what I am doing with this stuff. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal? "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice.	[reply]
Re^13: Segfault on second (identical) call to a sub by syphilis (Archbishop) on Feb 07, 2006 at 09:03 UTC
I wondered that too, but if you unwind the SvPV() macro, you eventually realise that the len parameter passed to it is not used to indicate the length of anything, but rather is used to retrieve the length of the data held in the SV. Come to think about it ... I think I've seen that alluded to before. Hopefully it will stick with me this time. Cheers, Rob	[reply]