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.