in reply to Re^5: Segfault on second (identical) call to a sub
in thread Segfault on second (identical) call to a sub

5.8.8 certainly cures the problem with my cut down code above, but not with the code from which it is derived :(

Now to go through the process of reducing it all over again.

Update:

If you get a moment, could you try wrapping the sub call in the OP code in a loop and calling say 10 times under 5.8.8? From what I am seeing, it appears that 5.8.8 allows me to call it twice without failure, but goes belly up after 4 or 5 times.

The cuprit appears to be something in GD, but a quick scan of GD.xs shows none of the bad things demo'd in in the OO Inline C example. It use Safemalloc/Safefree exclusively and make no calls to str(n)dup(), or any of the other dodgey crt string functions.

I tried upgrading GD to 2.30. It builds clean(ish), but segfaults when running it's testsuite. (And yes. I made sure I had the latest version of gdlib: v2.0.33 :)


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.
  • Comment on Re^6: Segfault on second (identical) call to a sub

Replies are listed 'Best First'.
Re^7: Segfault on second (identical) call to a sub
by syphilis (Archbishop) on Feb 06, 2006 at 00:48 UTC
    Yeah ..... bummer !!
    I'm building against a pre-compiled GD library I got from somewhere. It's recent, but I don't know what version it is and couldn't find a quick way of determining the version. GD-2.30 builds cleanly against it for me (using MinGW compiler) and the tests run fine - except for one warning:

    "t/Polyline....Subroutine scale redefined at D:\comp58_M\GD-2.30\blib\lib/GD/Polyline.pm line 52."

    The error in your test script arises when 'my $raw = $gd->gd;' is called. That calls the XS function gdgd(), which can produce the "Free to wrong pool..." error on subsequent iterations.
    At first I thought it might be the gdFree() that gdgd() calls, but the fault occurs after that - ie, I guess, when gdgd() exits/returns. There's not a lot of code in gdgd() so I fiddled about with it for quite some time but couldn't get anywhere .... which means I'm about stumped. I did get some mileage from allocating with New() ... but success seemed to depend upon the strategic placement of debug printf() statements ... which is not a good sign :-)

    Cheers,
    Rob

      I'm currently using the pre-compiled bgd.dll (v2.0.33) from boutell.com and GD.pm v2.28 that I compiled myself (with 5.8.7) without problems. Attempting to build GD.pm 2.30 against the same version bgd.lib & 5.8.8 compiles okay but traps in it's test suite, but from the results I get from tracing acid06's version of the problem, I suspect that the trap is down to perl rather than GD.

      I was about to quote the "something rotten" bit from Hamlet, but realised that timing is not good.


      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.
        Well ... there may well be something not right with perl - but afaict there is something not right with GD-2.30, either. The following script outputs "11037 11037 ERROR 1", but surely $raw and $raw2 should be equivalent. (Note that I'm looping thru the loop only once .... which means I'm not really looping at all :-)
        use strict; use warnings; use GD; for(1 .. 1) { x(100, 100); print $_, " "; } sub x{ my $im = GD::Image->new( @_); my $raw = $im->gd; my $im2 = GD::Image->newFromGdData( $raw ) or die "$!, $^E"; my $raw2 = $im2->gd; # my $len = length($raw); if($raw ne $raw2) {print length($raw), " ", length($raw2), " ERROR + "} }
        If I then remove the '#' so that the length of $raw is evaluated, the script then outputs "1 " - which is as I would expect.

        And when I further change the script so that it loops 10 times, I get the "Free to wrong pool..." error immediately (irrespective of whether the length of $raw is evaluated or not). Contrast that behaviour with the following Inline::C script that does (I believe) precisely the same thing - but manages to interface with the GD library flawlessly. (You'll probably need to amend the 'LIBS' and 'INC' config info.)
        use warnings; package my_gd; use Inline C => Config => BUILD_NOISY => 1, LIBS => '-LD:/gd/gdwin32 -lbgd', INC => '-ID:/gd/gdwin32/include'; use Inline C => <<'EOC'; #include <stdio.h> #include <gd.h> SV * new(int x, int y) { gdImagePtr * image; SV * obj_ref, *obj; New(1, image, 1, gdImagePtr); if(image == NULL)croak("Failed to allocate memory in new()"); obj_ref = newSViv(0); obj = newSVrv(obj_ref, "my_gd"); *image = gdImageCreate(x, y); sv_setiv(obj, (IV)image); SvREADONLY_on(obj); return obj_ref; } SV * gdgdImageCreateFromGdPtr(SV * data, int len) { gdImagePtr * image; SV * obj_ref, *obj; New(1, image, 1, gdImagePtr); if(image == NULL)croak("Failed to allocate memory in gdgdImageCre +ateFromGdPtr()"); obj_ref = newSViv(0); obj = newSVrv(obj_ref, "my_gd"); *image = gdImageCreateFromGdPtr(len, SvPV(data, len)); sv_setiv(obj, (IV)image); SvREADONLY_on(obj); return obj_ref; } SV * gdgd(SV * image) { void * data; int size; SV * t; data = gdImageGdPtr(*((gdImagePtr *)SvIV(SvRV(image))), &size); t = newSVpv((char*) data, size); gdFree(data); return t; } void DESTROY(SV * image) { printf("Destroying "); Safefree((gdImagePtr *)SvIV(SvRV(image))); } EOC $| = 1; for(1 .. 10) { x(100, 100); print $_, " "; } sub x{ my $im = new(@_); my $raw = gdgd($im); my $im2 = gdgdImageCreateFromGdPtr($raw, length($raw)); my $raw2 = gdgd($im2); # print length($raw), " "; if($raw ne $raw2) {print "ERROR"} }
        Note that DESTROY() prints "Destroying " - just so you can see that/when it's being called. It's probably less confusing if you comment that out.

        I'm going to stop short of saying that there is something wrong with the GD-2.30 source - I'm not all that familiar with either the GD library or the perl module, and I might be doing something (embarrassingly) stupid. But I feel that it's possible to write the perl interface to the GD library in such a way that the errors we're seeing with the GD module do not occur.

        Cheers,
        Rob