Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

Segfault on second (identical) call to a sub

by BrowserUk (Patriarch)
on Feb 04, 2006 at 18:35 UTC ( [id://527970]=perlquestion: print w/replies, xml ) Need Help??

BrowserUk has asked for the wisdom of the Perl Monks concerning the following question:

Update: The problem described in this post is fixed in GD v2.31 now on cpan.

Is there anything obvious as to why the "free to wrong pool" and segfault should happen, but only on the second call to this sub?

Does it occur on other platforms/versions?

#! perl -slw use strict; use GD; sub x{ my( $x, $y ) = @_; GD::Image->trueColor( 1 ); my $gd = GD::Image->new( $x, $y ); my $raw = $gd->gd; my $img = GD::Image->newFromGdData( $raw ) or die "$!, $^E"; return $img->jpeg; } print "Perl:$]; $GD::VERSION"; my $cap = x( 100, 100 ); printf 'Waiting'; <STDIN>; $cap = x( 100, 100 ); __END__ C:\Perl\test>junk3 Perl:5.008007; 2.28 Waiting Free to wrong pool 2227b0 not a797469 at C:\Perl\test\junk3.pl line 9, + <STDIN> line 1.

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.

Replies are listed 'Best First'.
Re: Segfault on second (identical) call to a sub
by Tanktalus (Canon) on Feb 04, 2006 at 18:46 UTC
    $ perl junk3.pl Perl:5.008007; 2.30 Waiting $
    No problems on this Linux box - slightly newer GD, I see.
Re: Segfault on second (identical) call to a sub
by qq (Hermit) on Feb 04, 2006 at 19:37 UTC
    ~ rjolly$ perl browseruk.pl Perl:5.008007; 2.30 Waiting Segmentation fault

    Fails here. OS X 10.3.9

Re: Segfault on second (identical) call to a sub
by zentara (Archbishop) on Feb 04, 2006 at 20:36 UTC
    I have linux, I get
    Perl:5.008007; 2.30Waiting *** glibc detected *** free(): invalid pointer: 0x08281410 ***

    Curiously, if I put the second call in a separate sub, it runs error free.

    #!/usr/bin/perl use warnings; use strict; use GD; print "Perl:$]; $GD::VERSION"; my $cap = x( 100, 100 ); printf 'Waiting'; <STDIN>; $cap = zz( 100, 100 ); ################################################# sub x{ my( $x, $y ) = @_; GD::Image->trueColor( 1 ); my $gd = GD::Image->new( $x, $y ); my $raw = $gd->gd; my $img = GD::Image->newFromGdData( $raw ) or die "$!, $^E"; return $img->jpeg; } sub zz{ my( $x, $y ) = @_; GD::Image->trueColor( 1 ); my $gd = GD::Image->new( $x, $y ); my $raw = $gd->gd; my $img = GD::Image->newFromGdData( $raw ) or die "$!, $^E"; return $img->jpeg; }

    I'm not really a human, but I play one on earth. flash japh
Re: Segfault on second (identical) call to a sub
by helphand (Pilgrim) on Feb 04, 2006 at 19:41 UTC

    Dies here on Linux 64 bit with the most recent GD, different message though...

    helphand@helphand:~> perl segfault.pl Perl:5.008006; 2.30 Waiting *** glibc detected *** free(): invalid pointer: 0x0000000000849d10 *** Aborted helphand@helphand:~>

    Scott

Re: Segfault on second (identical) call to a sub
by syphilis (Archbishop) on Feb 04, 2006 at 22:01 UTC
    I get the same error as you've reported - on Windows 2000 with perl 5.008007 and GD-2.30. However, the same script runs fine when I switch to perl 5.008008 (same box, and same build of GD).This would suggest that the issue lies with perl, itself - and has been successfully addressed with the release of perl-5.8.8.

    Cheers,
    Rob

      Many thanks for this information.

      I've seen various manifestations of this bug ever since upgrading to 5.8.7, but I've been shy of reporting them as my first attempt at the upgrade using the AS 813 msi went belly up at the nth hour and insisted on rolling back, but left my 5.8.6 installed screwed.

      I managed to 'recover' by using the quickly available AS815 build, but I was never really convinced that the screw up hadn't left something not quite right in my setup. This time, I completely blew away everything, including all the non-AS core packages which I've previously got away with leaving in place (5.8.0->5.8.1->5.8.2->...->5.8.6), and installed completely clean.

      Unfortunately, I am still seeing the same problems which probably means that they are down to 5.8.7 core and all the time I spent rebuilding all my packages was wasted as I'll have to go through it all again for 5.8.8 :(

      I think I may just revert to 5.8.6 which seems to have been a very good, stable build.


      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.
        Unfortunately, I am still seeing the same problems which probably means that they are down to 5.8.7 core and all the time I spent rebuilding all my packages was wasted as I'll have to go through it all again for 5.8.8

        Not sure that I understand you correctly ... I don't think you have to re-build any packages when you upgrade. The GD-2.30 that triggers the error on perl 5.8.7 is the very same GD-2.30 that produces no error on perl 5.8.8. It was built probably using perl 5.8.7, or perhaps perl 5.8.6, but I didn't re-build it when I installed perl 5.8.8.

        (I don't think ActiveState have yet released a 5.8.8 build, and I don't know how long it will be before they do.)

        Cheers,
        Rob
Re: Segfault on second (identical) call to a sub
by acid06 (Friar) on Feb 06, 2006 at 04:14 UTC
    I don't know if it helps at all, but while trying to trick it into working I managed to make matters even worse.

    The code below produces the "free to wrong pool" error message even on the first call.

    use strict; use GD; print "Perl:$]; $GD::VERSION \n"; for (1..10) { print "Iteration $_\n"; my $cap = x_generator( 100, 100 )->(); } sub x_generator { my ($x, $y) = @_; return sub { GD::Image->trueColor( 1 ); my $gd = GD::Image->new( $x, $y ); my $raw = $gd->gd; my $img = GD::Image->newFromGdData( $raw ) or die "$!, $^E"; return $img->jpeg; }; } __END__ Perl:5.008007; 2.30 Iteration 1 Free to wrong pool 222888 not 15c1b142 at testbug.pl line 9.


    acid06
    perl -e "print pack('h*', 16369646), scalar reverse $="

      Thanks, that did help. The extra level of sub call/return allowed me to see the stack frame just before and after the trap occurs (in 5.8.8). It's happening as perl cleans up it's stack after the nested call; in Perl_free_temps(). It shows (I think), that the problem is nothing to do with GD but rather with the perl executable itself:

      PID: 320 TID: 1716 - Stack Contents for 0x280EAF30 0x280EAF30: perl58.dll:VMem::Free + 0x0054 <Void> 0x280EF62F: perl58.dll:CPerlHost::Free + 0x0021 <Void> 0x280EBE12: perl58.dll:PerlMemFree + 0x0016 <Void> 0x280E4E37: perl58.dll:Perl_safesysfree + 0x002A <Void> 0x280AEE3B: perl58.dll:Perl_sv_clear + 0x06EE <Void> 0x280AF2B0: perl58.dll:Perl_sv_free + 0x013E <Void> 0x280024D5: perl58.dll:Perl_av_undef + 0x008D <Void> 0x280AED0E: perl58.dll:Perl_sv_clear + 0x05C1 <Void> 0x280AF2B0: perl58.dll:Perl_sv_free + 0x013E <Void> 0x280350D8: perl58.dll:Perl_pad_undef + 0x0227 <Void> 0x280EF62F: perl58.dll:CPerlHost::Free + 0x0021 <Void> 0x2802CD37: perl58.dll:Perl_cv_undef + 0x0138 <Void> 0x280AECEA: perl58.dll:Perl_sv_clear + 0x059D <Void> 0x280AF2B0: perl58.dll:Perl_sv_free + 0x013E <Void> 0x280A2CEA: perl58.dll:Perl_free_tmps + 0x0077 <Void> 0x28065C6F: perl58.dll:Perl_pp_nextstate + 0x005F <op *> 0x280A26CD: perl58.dll:Perl_runops_standard + 0x000F <Int> 0x2803A9C5: perl58.dll:S_run_body + 0x018F <Void> 0x2803A562: perl58.dll:perl_run + 0x008A <Int> 0x280EEC9F: perl58.dll:RunPerl + 0x00A1 <Int> 0x7C0068F7: __getmainargs + 0x00BD 0x00401012: perl.exe:main + 0x0012 <Int> 0x0040115A: perl.exe:mainCRTStartup + 0x0143 <Int> 0x77E814C7: GetCurrentDirectoryW + 0x0044

      In every other version I've traced, the stack is already corrupted by the time the trap occurs and so it was impossible to tell where I was in the code. I your version, the trap occurs much closer to the origin of the corruption and so the stack trace is still intact.

      If I could get a version of the trap that didn't call GD at all would be the best demonstration, but maybe the above stacktrace is convincing when combined with the same code running clean under 5.8.6--which I will now re-install.

      Thanks again for your help.


      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.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://527970]
Approved by Arunbear
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others surveying the Monastery: (5)
As of 2024-03-29 07:46 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found