perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher H. Laco" <cl...@chrislaco.com>
Subject Re: Apache2/MP2 Segfaults when loading Text::Textile
Date Thu, 23 Mar 2006 12:54:42 GMT
BjXrn Erik Jacobsen wrote:
> At 05:04 23.03.2006, you wrote:
>> I'm working on a site running under Catalyst under ModPerl
>> 2.0.2/Apache2.0.55.
>>
>> As soon as I tried loading Text::Textile in any way, apache segfaults,
>> even when just doing apachectl configtest.
>>
>> Text::Textile is a pure perl module, and uses Exporter. Nothing special.
>>
>> I started rebuilding a copy of the lib function by function, and the
>> line that finally caused a sefault is this line:
>>
>>
>> 	my $Have_ImageSize;  = eval 'use Image::Size; 1' ? 1 : 0;
>>
>> Anyone seem this problem before?
> 
> Assuming you have Image::Magick installed, that might be the problem. 
> It seems that Image::Magick, when preloaded, is trashing memory. Or more
> likely, the possible memory/stack trashing becomes an issue when the
> module is preloaded.
> 
> I've struggled with this problem for about a year, which is roughly when it
> started to happen. It's a tricky one to track down, and compiling the entire
> world with full debugging, including Electric Fence does not seem to provide
> any useful clues.
> 
> There are at least two ways to work around the problem. 
> 
> One is to avoid preloading, either directly or indirectly, any module that
> include Image::Magick. This is doable, but performance will suffer if
> it is required frequently. Also, under FreeBSD I've seen sporadic core dumps
> of the child processes when it is not preloaded, on Debian I have not seen
> this happen. That said, you also run the risk of having an unpredictable
> httpd on subsequent requests, although I personally have seen no problems.
> 
> A better way, IMO, is to replace Image::Magick with Graphics::Magick which
> is a compatible (more or less) reimplementation if Image::Magick. You'd also
> have to edit the modules that use Image::Magick to use Graphics::Magick
> instead, or create a fake Image::Magick proxy module for Graphics::Magick.
> 
> If you don't have Image::Magick installed, I would have no idea.
> 
> If anyone have any clue about this problem, I'd be happy to know. 
> Particularly, since I've experienced the same problem with later
> versions of XML::LibXML/libxml2 too. Makes me wonder if the problems
> might not be within the libraries, but are somehow related to Apache/mod_perl.
> These problems never occur when run with the same perl version from the
> shell, outside of MP context, on the same box.
> 
> 

That's in on the nose. Text::Textile uses Image::Size, which uses
Image::Magick.  Any incantation of pre loading this modules makes apache
core.

The funny part is, it only segfaults the main httpd process. apachectl
start yields a core dump, but the child proc are created and serve pages
just fine....until an apachectl stop is issued. Then the children stop,
but the main proc cores again, sticks to 100% cpu, and isn't killable at
all.

For that matter, running these site run just fine under the Catalyst
standalone dev server, so Image::Magick itself is generally usable. But
I digress...

I saw muttering about the net about trying the --enable--embeddable
config option for Image::Magick, but that had no effect. What I haven't
tried yet, is static compiling it, and see if that cures the problem.

Unfortunately, not using Image::Magick or not preloading it isn't really
 a practical option for the sites I have that use it. It's touched by
various image, thumbnail modules, textile, and even GD::SecurityImage
for captchas.

But since Catalyst sites are just as happy running under
FastCGI/mod_fcgi, I think that's the lowest barrier to getting them up
and running without a core dumping MP install.

-=Chris



Mime
View raw message