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

I'll try to clarify :)

I usually upgrade AS perl builds without rebuilding the packages that don't come with it. That's worked reliably since 5.8.0. However, when I first installed 5.8.7/AS813, the installed failed right towards the end. It didn't tell me what failed, but I am guessing that it was generating the HTMLised POD. It insisted on backing the install off, but left the previous 5.8.6 build broken to the point where perl simply wouldn't start. AS support suggested that I should always uninstall the previous build, (leaving the non-AS packages in place), before installng a new AS build. I attempted this with AS813 but it still failed at the end in the same way.

I reinstalled 5.8.6 over the top of what was left and things seemed okay. A few days later AS815 became available so I got that, uninstalled 5.8.6, again leaving the non distribution packages in place and attempted the AS815 install. It went through cleanly.

However, there were various instances of previously working code doing strange things--mostly resulting in a "free to wrong pool". I've seen this message a lot in the past with code that used threads badly, but these were simple non-threaded programs. The latest of which is the subject of the OP. This a highly cut-down version of a program that has worked fine since 5.8.3 and through several upgrades of GD, that suddenly started working one time but not the next. As you can see from the OP and zentara's post above, it is really very obscure when you can call a sub successfully once, or even twice to do exactly the same processing, from different places in the code--but not twice from the same place!

So, given the immediate preceding history of failed installed and broken restorations, I was unable in good conscience to 'point the finger' at 5.8.7. Hence my need to re-build everything clean to be sure.

My fear is, that as I have now built all those packages in conjunction with 5.8.7, whatever malady is the root cause of the segfault may now be compiled into, (via errors in the Perl header files?), all the (XS components of) packages that I built in conjunction with it.

It may be that the problem was unrelated to the header files in any way, but with perl 5.8.7 delta saying

There has been a fair amount of refactoring of the C source code,

can I be sure?

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^4: Segfault on second (identical) call to a sub

Replies are listed 'Best First'.
Re^5: Segfault on second (identical) call to a sub by syphilis (Archbishop) on Feb 05, 2006 at 06:00 UTC
My fear is, that as I have now built all those packages in conjunction with 5.8.7, whatever malady is the root cause of the segfault may now be compiled into, (via errors in the Perl header files?), all the (XS components of) packages that I built in conjunction with it. I think that fear is misplaced - I think it would be a rare case that a perl extension will need to be re-compiled (or benefit in any way from re-compiling) when you switch to perl 5.8.8. Anyway, time will tell .... :-) The error can still arise in perl 5.8.8. If you have a compiler, and Inline::C installed, and you run the Object Oriented Inline example from Inline's C-Cookbook.pod, you should get the "Free to wrong pool ..." error on Windows. That error still persists with perl 5.8.8 - but that's because it's the code in the Cookbook example that's in need of correction. Cheers, Rob	[reply]
Re^6: Segfault on second (identical) call to a sub by BrowserUk (Patriarch) on Feb 05, 2006 at 14:38 UTC
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.	[reply]
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	[reply]
Re^8: Segfault on second (identical) call to a sub by BrowserUk (Patriarch) on Feb 06, 2006 at 05:57 UTC
Re^9: Segfault on second (identical) call to a sub by syphilis (Archbishop) on Feb 07, 2006 at 03:53 UTC
Some notes below your chosen depth have not been shown here


Pathologically Eclectic Rubbish Lister
	PerlMonks