You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by "Christopher H. Laco" <cl...@chrislaco.com> on 2006/03/23 05:04:50 UTC
Apache2/MP2 Segfaults when loading Text::Textile
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?
-=Chris
Re: Apache2/MP2 Segfaults when loading Text::Textile
Posted by "Christopher H. Laco" <cl...@chrislaco.com>.
Tom Schindl wrote:
> As a sidenote often it is not really desired/dangerous to run image
> creation as a mod_perl handler because of the nature of perl, memory
> allocated once is never freed until the process shutdowns or is killed
> (by your Apache::SizeLimit handler).
>
> I'm not familiar with fastcgi but you should make sure that the
> fcgi-process is killed when a certain amout of memory is exhausted like
> you would make it with Apache::SizeLimit.
>
> Tom
In this particular case, it has nothing to do with image create, but
image size detection. Text::Textile will load Image::Size, which will
load ImagE::Magick... all just to put width/height into an img tag
Textile is creating for a specified image.
Sure, Image::Info would be a better choise for Textile, but I just the
site up without core dumping apache, or having to rewrite 3 other CPAN
modules.
-=Chris
Re: No image creation in mod_perl (was RE: Apache2/MP2 Segfaults
...)
Posted by Tom Schindl <to...@gmx.at>.
Well image creation in mod_perl is not a bad idea if you ensure that the
process is killed after it succeeded a certain memory. The problem in
case of mod-perl/httpd is that that if every httpd-process is eating 20
MB of space only because you have created once an image. You must ensure
that only very view processes of your apache are used to create images
and /me thinks this could be accomplished best using the following setup.
1. light-weight httpd to server static content
2. mod-perl enabled httpd to serve dynamic content beside images
3. mod-perl enabled httpd to server images with few processes (e.g.
MaxChild 5). This ensures that you can answer 5 image creation request
simultaneously but your system will never use more than 100 MB to create
images.
If your system is not stressed heavily 1 and 3 could be run in one server.
Tom
Frank Maas wrote:
> Tom,
>
>
>>As a sidenote often it is not really desired/dangerous to run image
>>creation as a mod_perl handler because of the nature of perl, memory
>>allocated once is never freed until the process shutdowns or is killed
>>(by your Apache::SizeLimit handler).
>
>
> Ah, you got me worried there... How in your opinion should one do creation of images in a mod_perl environment. Think of captcha's, on-the-fly images, etc.?
>
> I am very interested to hear opinions about this (just before I am going to use this heavily ;-).
>
> Regards,
> Frank
>
>
Re: No image creation in mod_perl (Or Perl Memory Management is a
beast)
Posted by Tom Schindl <to...@gmx.at>.
And even "worse":
-----------------8<-----------------
#!/usr/bin/perl
use Benchmark;
$t0 = new Benchmark;
&bla();
$t1 = new Benchmark;
# Memory has grown on my machine to 110 MB
#sleep 20;
$t2 = new Benchmark;
&bla();
$t3 = new Benchmark;
# Memory has resides on my machine on 110 MB
print "First run took: " . timestr(timediff($t1, $t0)) . "\n";
print "Second run took: " . timestr(timediff($t3, $t2)) . "\n";
sleep;
sub bla {
my $var = &blo($ARGV[0]);
# undef $var;
}
sub blo {
my $var = "";
for( 1 .. 20_000_000 ) {
$var .= "xxx";
}
# undef $var;
if( ! defined $_[0] ) {
return $var;
} else {
return \$var; ## This will also result in the fact that perl
## releases the memory after the sub has been
## ended
}
}
-----------------8<-----------------
Just to quote perl gurus from the p5p you'll get to here something like
this:
Yitzchak Scott-Thoennes:
...
Memory is *not* released back to perl. Lexicals(*) hold on to their
storage space, including the string buffer, under the presumption that
they will be reused. Perl's memory management strategy can be
described as allocate as early as possible and for as long as
possible.
...
Please note the fact that Lexicals!!! hold their values until they are
undef-ed or they are also GCed when returned as references. You should
also note the time used in the second run (especially sys-time) which is
much lower because memory allocation has not to be done.
>>>Can I confirm that in the Windows implementation, if a thread allocates
>>>requires 100MB of memory and then releases it, the next thread can reuse
>>>that memory?
>>>
>>>Thanks.
>>>
>>>
>>
>>
>
Because the above said applies to any perl you won't gain much on win32
because memory allocated belongs exactly to the sub it was allocated in ;-)
Tom
Re: No image creation in mod_perl
Posted by Tom Schindl <to...@gmx.at>.
Well this example does not demonstrate the problem it demonstrates the
solution to let perl free memory allocated once by setting the variable
to undef ;-)
---------------8<---------------
#!/usr/bin/perl
&bla();
print "Done";
my $bla = <STDIN>;
sub bla {
my $var = "";
for( 1 .. 10_000_000 ) {
$var .= "xxx";
}
# undef $var; # The solution to wipe out allocated memory
# by explicitly setting vars to undef
}
---------------8<---------------
Tom
Tom Schindl wrote:
> You can try memory management yourself and see that the memory allocated
> is not wiped until the script is finished.
>
> --------------------8<--------------------
> #!/usr/bin/perl
>
> &bla();
> print "Done";
>
> sub bla {
> my $var = "";
> for( 1 .. 10_000_000 ) {
> $var .= "xxx";
> }
>
> my $bla = <STDIN>;
> undef $var;
> }
> --------------------8<--------------------
>
> You can modify this example to use threads and see what's happeing to
> your memory.
>
> Tom
>
>
> Foo Ji-Haw wrote:
>
>>Hello Carl,
>>
>>
>>>Nope that's right, so you load up one image. The perl process
>>>allocates itself 100MB of memory for it from the OS. Then doesn't
>>>release it back to the OS once it's finished with.
>>>
>>>The perl process will re-use this memory, so if you process another
>>>image you don't grab another 100MB, it's just not available at the OS
>>>level or for other processes.
>>>
>>>This isn't completely bad as long as your OS has good memory
>>>management. The unused memory in the perl process will just be swapped
>>>out to disk and left there until that process uses it again or exits.
>>
>>Can I confirm that in the Windows implementation, if a thread allocates
>>requires 100MB of memory and then releases it, the next thread can reuse
>>that memory?
>>
>>Thanks.
>>
>>
>
>
Re: No image creation in mod_perl
Posted by Tom Schindl <to...@gmx.at>.
You can try memory management yourself and see that the memory allocated
is not wiped until the script is finished.
--------------------8<--------------------
#!/usr/bin/perl
&bla();
print "Done";
sub bla {
my $var = "";
for( 1 .. 10_000_000 ) {
$var .= "xxx";
}
my $bla = <STDIN>;
undef $var;
}
--------------------8<--------------------
You can modify this example to use threads and see what's happeing to
your memory.
Tom
Foo Ji-Haw wrote:
> Hello Carl,
>
>>
>> Nope that's right, so you load up one image. The perl process
>> allocates itself 100MB of memory for it from the OS. Then doesn't
>> release it back to the OS once it's finished with.
>>
>> The perl process will re-use this memory, so if you process another
>> image you don't grab another 100MB, it's just not available at the OS
>> level or for other processes.
>>
>> This isn't completely bad as long as your OS has good memory
>> management. The unused memory in the perl process will just be swapped
>> out to disk and left there until that process uses it again or exits.
>
> Can I confirm that in the Windows implementation, if a thread allocates
> requires 100MB of memory and then releases it, the next thread can reuse
> that memory?
>
> Thanks.
>
>
Re: No image creation in mod_perl
Posted by Foo Ji-Haw <jh...@extracktor.com>.
Hello Carl,
>
> Nope that's right, so you load up one image. The perl process
> allocates itself 100MB of memory for it from the OS. Then doesn't
> release it back to the OS once it's finished with.
>
> The perl process will re-use this memory, so if you process another
> image you don't grab another 100MB, it's just not available at the OS
> level or for other processes.
>
> This isn't completely bad as long as your OS has good memory
> management. The unused memory in the perl process will just be swapped
> out to disk and left there until that process uses it again or exits.
Can I confirm that in the Windows implementation, if a thread allocates
requires 100MB of memory and then releases it, the next thread can reuse
that memory?
Thanks.
Re: No image creation in mod_perl
Posted by Carl Johnstone <mo...@fadetoblack.me.uk>.
> In (eg) the worker MPM, each process contains its own perl interpreter,
> so if each process handles one image once in its lifetime, there is a
> lot of memory that has been grabbed by perl which is not available to
> create more perl processes.
>
> ... is what makes sense to me but may be utterly meaningless.
Nope that's right, so you load up one image. The perl process allocates
itself 100MB of memory for it from the OS. Then doesn't release it back to
the OS once it's finished with.
The perl process will re-use this memory, so if you process another image
you don't grab another 100MB, it's just not available at the OS level or for
other processes.
This isn't completely bad as long as your OS has good memory management. The
unused memory in the perl process will just be swapped out to disk and left
there until that process uses it again or exits.
Carl
Re: No image creation in mod_perl (was RE: Apache2/MP2 Segfaults
...)
Posted by Clinton Gormley <cl...@traveljury.com>.
> This revelation of how Perl does not free up memory it allocates is
> worrying, especially as I do process large documents regularly.
>
> If I read you right, you are saying that $r->child_terminate will force
> the current thread to terminate, causing Apache to create a new thread.
> Is that right? I use 'threads' in place of 'processes' as I refer to the
> Windows implementation of Apache.
No, this only works with processes, not with threaded MPMs:
http://perl.apache.org/docs/2.0/api/Apache2/RequestUtil.html#C_child_terminate_
But that makes sense to me, if I have understood it correctly.
Once a perl process has allocated memory, it doesn't return it to the
system until the perl interpreter exits. It is, however, available to
the process for reuse.
So in a threaded MPM, a single process may grow in size, but all the
threads will have access to the allocated memory.
In (eg) the worker MPM, each process contains its own perl interpreter,
so if each process handles one image once in its lifetime, there is a
lot of memory that has been grabbed by perl which is not available to
create more perl processes.
... is what makes sense to me but may be utterly meaningless.
clint
Re: No image creation in mod_perl (was RE: Apache2/MP2 Segfaults
...)
Posted by Foo Ji-Haw <jh...@extracktor.com>.
Hey Carl,
> The only place where forking is useful is where you want something to
> continue processing after sending the response back to the client.
>
> You can achieve the same effective result by calling
> $r->child_terminate()
> (assuming your using pre-fork). The currently running child exits at
> the end
> of the request freeing any memory it's allocated, and the main apache
> server
> process will fork a new child to replace it if needed.
This revelation of how Perl does not free up memory it allocates is
worrying, especially as I do process large documents regularly.
If I read you right, you are saying that $r->child_terminate will force
the current thread to terminate, causing Apache to create a new thread.
Is that right? I use 'threads' in place of 'processes' as I refer to the
Windows implementation of Apache.
Thanks.
Re: No image creation in mod_perl (was RE: Apache2/MP2 Segfaults ...)
Posted by Carl Johnstone <mo...@fadetoblack.me.uk>.
> Can you fork off a separate process to do this (that will die once it is
> completed)?
The only place where forking is useful is where you want something to
continue processing after sending the response back to the client.
You can achieve the same effective result by calling $r->child_terminate()
(assuming your using pre-fork). The currently running child exits at the end
of the request freeing any memory it's allocated, and the main apache server
process will fork a new child to replace it if needed.
Carl
Re: No image creation in mod_perl (was RE: Apache2/MP2 Segfaults
...)
Posted by Sean Davis <sd...@mail.nih.gov>.
On 3/27/06 6:21 AM, "Tom Schindl" <to...@gmx.at> wrote:
> Please note that this is not only true for Image-Creation but also if
> you are restoring large string contents in a variable (e.g. after
> processing a file-upload).
>
> Tom
>
> Frank Maas wrote:
>> Tom,
>>
>>
>>> As a sidenote often it is not really desired/dangerous to run image
>>> creation as a mod_perl handler because of the nature of perl, memory
>>> allocated once is never freed until the process shutdowns or is killed
>>> (by your Apache::SizeLimit handler).
>>
>>
>> Ah, you got me worried there... How in your opinion should one do creation of
>> images in a mod_perl environment. Think of captcha's, on-the-fly images,
>> etc.?
>>
>> I am very interested to hear opinions about this (just before I am going to
>> use this heavily ;-).
Can you fork off a separate process to do this (that will die once it is
completed)?
Sean
Re: No image creation in mod_perl (was RE: Apache2/MP2 Segfaults
...)
Posted by Tom Schindl <to...@gmx.at>.
Please note that this is not only true for Image-Creation but also if
you are restoring large string contents in a variable (e.g. after
processing a file-upload).
Tom
Frank Maas wrote:
> Tom,
>
>
>>As a sidenote often it is not really desired/dangerous to run image
>>creation as a mod_perl handler because of the nature of perl, memory
>>allocated once is never freed until the process shutdowns or is killed
>>(by your Apache::SizeLimit handler).
>
>
> Ah, you got me worried there... How in your opinion should one do creation of images in a mod_perl environment. Think of captcha's, on-the-fly images, etc.?
>
> I am very interested to hear opinions about this (just before I am going to use this heavily ;-).
>
> Regards,
> Frank
>
>
Re: No image creation in mod_perl (was RE: Apache2/MP2 Segfaults ...)
Posted by Jonathan Vanasco <mo...@2xlp.com>.
i generally don't like to do that in modperl unless i have enough
webservers. i think its a bit of a waste of the mp resource.
i do this:
on upload, generate a thumbnail w/Image:Epeg (which is a super fast
implementation of epeg. previously i compiled my own epeg tools and
the perl mod is WAY faster ) and save the original
have a cronjob that passes over new uploads and redoes the thumbnail
and creates sized versions using the python imaging library ( much
faster and way more powerful than the perl modules or image magick
and way easier to code )
captchas - you can pregenerate a bunch then use rewrite to alias
them. to me, its silly to generate them on the fly - its a rather
tedious task. you can even have a cronjob create a new pool of
captchas and a new map of filenames -> text in image every few hours
if you want.
i'm ok w/using image:epeg, because it just scans the image for info
and doesn't read the whole thing into memory.
i really hate doing image manipulation stuff in mod_perl or perl in
general.
No image creation in mod_perl (was RE: Apache2/MP2 Segfaults ...)
Posted by Frank Maas <fr...@cheiron-it.nl>.
Tom,
> As a sidenote often it is not really desired/dangerous to run image
> creation as a mod_perl handler because of the nature of perl, memory
> allocated once is never freed until the process shutdowns or is killed
> (by your Apache::SizeLimit handler).
Ah, you got me worried there... How in your opinion should one do creation of images in a mod_perl environment. Think of captcha's, on-the-fly images, etc.?
I am very interested to hear opinions about this (just before I am going to use this heavily ;-).
Regards,
Frank
Re: Apache2/MP2 Segfaults when loading Text::Textile
Posted by Tom Schindl <to...@gmx.at>.
As a sidenote often it is not really desired/dangerous to run image
creation as a mod_perl handler because of the nature of perl, memory
allocated once is never freed until the process shutdowns or is killed
(by your Apache::SizeLimit handler).
I'm not familiar with fastcgi but you should make sure that the
fcgi-process is killed when a certain amout of memory is exhausted like
you would make it with Apache::SizeLimit.
Tom
Christopher H. Laco wrote:
> Christopher H. Laco wrote:
>
>>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
>>
>>
>
>
> I finally got all the stuff back up and running last night under
> mod_fastcgi. No encantation I could find (--enable--embeddable, static
> linked lib, etc) would cure the segfaults when preloading Image::Magick.
> In the end, I just ended up ditching mod_perl since it's not really a
> requirement for the sites in question.
>
> -=Chris
>
Re: Apache2/MP2 Segfaults when loading Text::Textile
Posted by "Christopher H. Laco" <cl...@chrislaco.com>.
Christopher H. Laco wrote:
> 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
>
>
I finally got all the stuff back up and running last night under
mod_fastcgi. No encantation I could find (--enable--embeddable, static
linked lib, etc) would cure the segfaults when preloading Image::Magick.
In the end, I just ended up ditching mod_perl since it's not really a
requirement for the sites in question.
-=Chris
Re: mod_perl installation problem
Posted by Jonathan Vanasco <jo...@2xlp.com>.
On Mar 23, 2006, at 9:10 AM, N L wrote:
> I write on Xterm the command: perl Makefile.PL
> MP_AP_PREFIX="path to apache2 directory" (because all
> file are in the same directory). It was fine ; After I
> wanted to do a "make test" and I get this error
> message :
> waiting 120 seconds for server to start: .Syntax error
> on line 172 of
> /Users/lineneildelbosc/.cpan/build/mod_perl-2.0.2/t/conf/httpd.conf:
> Cannot load /usr/local/apache2/modules/libphp5.so into
> server: Library not loaded:
> /usr/local/lib/libxml2.2.dylib\n Referenced from:
> /usr/local/apache2/modules/libphp5.so\n Reason: image
what directory did your multi-item package install things into?
did you type in:
MP_AP_PREFIX="path to apache2 directory"
it should be something like
MP_AP_PREFIX=/usr/local/apache2/
the message is saying that modperl/apache is looking for libphp in /
usr/local/apache2/ -- ie: that is the root of the apache install, but
its not finding it. thats probably because your system installed it
elsewhere - you need to pass that line in. its also looking for
libxml2.2.dylib in /usr/local/lib/, where it wasn't intstalled as well.
i'm kind of perplexed that you were able to make this , and it failed
on the test. it seems like you compiled it against apache right, but
set an odd basedir?
i think libapreq has bug where it uses the wrong apache root for
make test on osx - maybe this is a variant of that?
mod_perl installation problem
Posted by N L <op...@yahoo.fr>.
Hello ,
I am working on Mac Osx Tiger, I installed automaticly
a package including apache2 , php5, MySQL4, and
phpMyAdmin it is really clean and it is working fine
but now I want to install with this the mod_perl
module I saw one is able to install dynamic mod_perl
if apache is already installed. So I download
mod_perl2 toinstalle it properly manually:
As it is explained in the installation documentation
I write on Xterm the command: perl Makefile.PL
MP_AP_PREFIX="path to apache2 directory" (because all
file are in the same directory). It was fine ; After I
wanted to do a "make test" and I get this error
message :
waiting 120 seconds for server to start: .Syntax error
on line 172 of
/Users/lineneildelbosc/.cpan/build/mod_perl-2.0.2/t/conf/httpd.conf:
Cannot load /usr/local/apache2/modules/libphp5.so into
server: Library not loaded:
/usr/local/lib/libxml2.2.dylib\n Referenced from:
/usr/local/apache2/modules/libphp5.so\n Reason: image
not found
.........................................................................................................................
waiting 120 seconds for server to start: not ok
[ error] giving up after 121 secs. If you think that
your system
is slow or overloaded try again with a longer timeout
value.
by setting the environment variable
APACHE_TEST_STARTUP_TIMEOUT
to a high value (e.g. 420) and repeat the last
command.
[ error] server failed to start! (t/logs/error_log
wasn't created, start the server in the debug mode)
+--------------------------------------------------------+
| Please file a bug report:
http://perl.apache.org/bugs/ |
+--------------------------------------------------------+
make: *** [run_tests] Error 1
Is there somebody understanding what is happening and
what it means?
Thanks in advance
ln
___________________________________________________________________________
Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international.
Téléchargez sur http://fr.messenger.yahoo.com
Re: Apache2/MP2 Segfaults when loading Text::Textile
Posted by "Christopher H. Laco" <cl...@chrislaco.com>.
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
Re: Apache2/MP2 Segfaults when loading Text::Textile
Posted by Bj�rn Erik Jacobsen <bj...@sparkit.no>.
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.
Re: Apache2/MP2 Segfaults when loading Text::Textile
Posted by "Christopher H. Laco" <cl...@chrislaco.com>.
Christopher H. Laco 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?
>
> -=Chris
Sorry for the typo, I didn't backtrack during testing...
The real line is:
my $Have_ImageSize = eval 'use Image::Size; 1' ? 1 : 0;