Re: segmentation fault under mod_perl+XML::XPath
Hello, Ged and other.
Thanks for long suggestion letter. I've solved my problem with mod_perl
compiled staticaly.
GH> Hi there,
GH> Haven't seen any replies, so I thought you'd like to hear from someone. :)
Thanks...
GH> On Wed, 2 Jul 2003, Ruslan U. Zakirov wrote:
>> I've tried to use XML::XPath under mod_perl 1.27 and Apache 1.3.27, but
>> got segmentation fault
GH> It's not uncommon to see XML and segfaults in the same post. :(
GH> Have you searched the archives?
Looked at it. My problem was different.
>> Under command line and CGI it's working fine and all tests during installation of
>> XML::XPath were fine, but the same code crush apache+mod_perl.
GH> [snip]
>> Apache - with so, unique_id, no expat
>> mod_perl with everything as DSO
GH> Whenever I see segfaults in a DSO Apache I'd say try static linking if
GH> you don't know what else to try. :)
Exactly this method is a solution.
>> Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
GH> Did you compile this Perl yourself? The standard advice is to compile
GH> mod_perl and Perl with the same compiler.
>> usemymalloc=n, bincompat5005=undef
GH> Highly unlikely, but maybe a malloc problem?
>> ccversion='', gccversion='2.95.3 20010315 (release) [FreeBSD]', gccosandvers=''
GH> You should be OK with that compiler, is that what you're using yourself?
GH> Hope you're not using gcc 3.x with that Perl...
I don't want to try 3.x yet.
>> Dynamic Linking:
>> dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
>> cccdlflags='-DPIC -fpic', lddlflags='-shared -L/usr/local/lib'
GH> Never heard of Perl (as opposed to mod_perl) dynamic linking causing a
GH> problem, so don't worry about that. (Until later.:)
>> Backtrace:
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x80711c5 in poolCopyString ()
>> (gdb) bt
>> #0 0x80711c5 in poolCopyString ()
GH> This is the code in xmlparse.c from my 1.3.27 source tree:
GH> --
GH> static const XML_Char *poolCopyString(STRING_POOL *pool, const XML_Char *s)
GH> {
GH> do {
GH> if (!poolAppendChar(pool, *s))
GH> return 0;
GH> } while (*s++);
GH> s = pool->start;
GH> poolFinish(pool);
GH> return s;
GH> }
GH> --
GH> Assuming you're using the same thing...
GH> As far as I can see this must mean that your pointer s is invalid, and
GH> either the dereference *s causes a memory bound error or else the s++
GH> increment tries to increment it off the end of the stack or something.
GH> There's nothing else in that function that would be likely to cause the
GH> fault, if pool were invalid I'd expect it to happen in poolAppendChar().
GH> I have no idea why these might be but it's a bit serious of course.
GH> You're into XS territory, the sort of thing that can easily be thrown
GH> by struct alignment problems such as you might get on the less well
GH> exercised configurations - which probably includes FreeBSD - and an
GH> unsuitable combination of compilers/dso/libraries/...
GH> You shouldn't have to be delving this deeply into these packages, but
GH> if a static link or a compiler change doesn't fix it and you don't
GH> mind cranking gdb a bit further you could find out what that pointer
GH> is pointing to and if it's a valid XML_Char pointer.
GH> Hope this gets you started in the right direction, but please don't
GH> take it as authoritative as I've never used FreeBSD nor XML::XPath.
Big thanks for your reply.
GH> 73,
GH> Ged.
Ruslan.
Re: segmentation fault under mod_perl+XML::XPath
Hello again, On Thu, 3 Jul 2003, Ged Haywood wrote: > There's nothing else in that function that would be likely to cause the > fault, if pool were invalid I'd expect it to happen in poolAppendChar(). Of course unless poolAppendChar() turns out to be a function defined by a macro, which it does, so forget that last bit. Could be pool too. :( 73, Ged.
Re: segmentation fault under mod_perl+XML::XPath
Hi there,
Haven't seen any replies, so I thought you'd like to hear from someone. :)
On Wed, 2 Jul 2003, Ruslan U. Zakirov wrote:
> I've tried to use XML::XPath under mod_perl 1.27 and Apache 1.3.27, but
> got segmentation fault
It's not uncommon to see XML and segfaults in the same post. :(
Have you searched the archives?
> Under command line and CGI it's working fine and all tests during installation of
> XML::XPath were fine, but the same code crush apache+mod_perl.
[snip]
> Apache - with so, unique_id, no expat
> mod_perl with everything as DSO
Whenever I see segfaults in a DSO Apache I'd say try static linking if
you don't know what else to try. :)
> Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
Did you compile this Perl yourself? The standard advice is to compile
mod_perl and Perl with the same compiler.
> usemymalloc=n, bincompat5005=undef
Highly unlikely, but maybe a malloc problem?
> ccversion='', gccversion='2.95.3 20010315 (release) [FreeBSD]', gccosandvers=''
You should be OK with that compiler, is that what you're using yourself?
Hope you're not using gcc 3.x with that Perl...
> Dynamic Linking:
> dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
> cccdlflags='-DPIC -fpic', lddlflags='-shared -L/usr/local/lib'
Never heard of Perl (as opposed to mod_perl) dynamic linking causing a
problem, so don't worry about that. (Until later.:)
> Backtrace:
> Program received signal SIGSEGV, Segmentation fault.
> 0x80711c5 in poolCopyString ()
> (gdb) bt
> #0 0x80711c5 in poolCopyString ()
This is the code in xmlparse.c from my 1.3.27 source tree:
--
static const XML_Char *poolCopyString(STRING_POOL *pool, const XML_Char *s)
{
do {
if (!poolAppendChar(pool, *s))
return 0;
} while (*s++);
s = pool->start;
poolFinish(pool);
return s;
}
--
Assuming you're using the same thing...
As far as I can see this must mean that your pointer s is invalid, and
either the dereference *s causes a memory bound error or else the s++
increment tries to increment it off the end of the stack or something.
There's nothing else in that function that would be likely to cause the
fault, if pool were invalid I'd expect it to happen in poolAppendChar().
I have no idea why these might be but it's a bit serious of course.
You're into XS territory, the sort of thing that can easily be thrown
by struct alignment problems such as you might get on the less well
exercised configurations - which probably includes FreeBSD - and an
unsuitable combination of compilers/dso/libraries/...
You shouldn't have to be delving this deeply into these packages, but
if a static link or a compiler change doesn't fix it and you don't
mind cranking gdb a bit further you could find out what that pointer
is pointing to and if it's a valid XML_Char pointer.
Hope this gets you started in the right direction, but please don't
take it as authoritative as I've never used FreeBSD nor XML::XPath.
73,
Ged.
Re: Segmentation fault - is Error.pm the culprit?
> This code essentially worked fine 2 weeks ago but at the time I removed my > DBI HandleError subroutine. Today when adding it back in I am facing > this problem I had a similar problem with HandleError, see the samples at: http://bowman.bs/bugs/perl/ I just stopped using HandleError. It also mysteriously seemed to be effected by whether or not mod_perl was a dso. It put it in perlbug I think. Brad -- Intelligence is nothing more than discussing things with others. Limitless wisdom comes of this. -- Hagakure
Re: Segmentation fault - is Error.pm the culprit?
"Richard Clarke" <[EMAIL PROTECTED]> writes: > I'm using a subclass of Error.pm to throw exceptions when a DBI > error happens. The SEGV only happens after I "return SERVER_ERROR" > in response to the thrown and propogated error. I do not know whether it can be related to your problem but for me some cryptical problems disappeared when I replaced default Error.pm with the newer version from CPAN.
Re: segmentation fault using a startup file
Ged Haywood wrote: On 27 Nov 2002, Jan Theofel wrote: Especially because we use SuSE Linux Enterprise Server which is a hihgly integrated system and we would loose the benefits of this system when we compile apache on our own. I don't understand that at all. Can somebody help me out here? Sure. Many (linux|other) systems nowadays rely on Apache and Perl to do the UI to the system. Therefore they sometimes (always?) patch or change these tools to do what they want them to do. And when you want to add your own things collisions might happen. Therefore if you want to keep the system intact, build your own Apache and your own Perl in a different directory. You especially want this if you are a developer that need to make sure that the product works with various versions. e.g. I have: % ls ~/perl/ 5.005_03 5.6.0 5.6.0-ithread 5.6.1 5.6.1-ithread 5.8.0 5.8.0-ithread blead blead-ithread % ls ~/httpd/ 1.3 2.0 prefork prefork-apreq threaded worker Of course you probably don't need them all, but you get the idea. the only caveat of installing your own Apache is that you can't use port 80, if the system's Apache uses it. A simple rewrite rule solves this problem. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
RE: segmentation fault using a startup file
Jan Theofel wrote: > Am Mon, 2002-11-25 um 17.46 schrieb Jan Theofel: > > > > (Re)starting apache results in the following segmentation fault: > > The problem with this segmentation fault is XML::Simple which I use > togeather with mod_perl. This seems to be a knowen problem > but without a known solution. It was a known problem with older versions of Apache. Specifically, the Apache build process statically linked in expat (for mod_dav?) and XML::Parser dynamically loaded expat causing a symbol conflict/segfault. My understanding is that modern builds of Apache no longer bundle expat but use the system supplied one so both Apache and XML::Parser share the dynamically loaded one - which of course is the 'right answer'. I'm not sure what version that change came in at (1.3.22 rings a bell) although I guess it's possible that SUSE may have forced a static linkage. What version of XML::Simple are you using? If it is 1.08 or earlier, then the expat conflict is almost certainly your problem. You could upgrade to 1.08_01 which allows you to use any SAX parser (eg: XML::LibXML) instead of expat/XML::Parser. If you're already running version 1.08_01 and you have SAX installed then work out which parser module you're using (the last one in lib/XML/SAX/ParserDetails.ini). Try selecting a different one (by swapping the order around in the ini file). Regards Grant
Re: segmentation fault using a startup file
On Wed, 27 Nov 2002, Ged Haywood wrote: > Date: Wed, 27 Nov 2002 20:56:01 + (GMT) > From: Ged Haywood <[EMAIL PROTECTED]> > To: Jan Theofel <[EMAIL PROTECTED]> > Cc: mod_perl mailinglist <[EMAIL PROTECTED]> > Subject: Re: segmentation fault using a startup file > > Hi Jan, > > On 27 Nov 2002, Jan Theofel wrote: > > > Am Mit, 2002-11-27 um 17.33 schrieb Ged Haywood: > > > > > > What is it about compiling your own Apache that troubles you? > > > > It is a lot of work to do. > > Only the first couple of times. Takes me about two minutes nowadays. I agree. The first few times I compiles anything on Unix, I thought "Wow, this is hard." Now I understand how things fit together and why it's a Good Thing to compile your own stuff. I feel dirty now when I use RPMs of Perl, Apache, or vi. > > Especially because we use SuSE Linux Enterprise Server which is a > > hihgly integrated system and we would loose the benefits of this > > system when we compile apache on our own. > > I don't understand that at all. Can somebody help me out here? A few months ago I tried out some different Linux distros. I liked Debian a lot until I got this wierd feeling about system dependencies on their own Perl. I ditched it within hours of that as I felt that it might prove easy to break the system. If you feel that you can't compile your own Apache on SuSE, you should probably consider a different distro for your web server and rely on those other nice bits on systems where you can do without the flexibility of compiling your own stuff. What will you do when the next security hole is found in Apache and you can't upgrade for fear of breaking your system? ky
Re: segmentation fault using a startup file
Hi Jan, On 27 Nov 2002, Jan Theofel wrote: > Am Mit, 2002-11-27 um 17.33 schrieb Ged Haywood: > > > > What is it about compiling your own Apache that troubles you? > > It is a lot of work to do. Only the first couple of times. Takes me about two minutes nowadays. > Especially because we use SuSE Linux Enterprise Server which is a > hihgly integrated system and we would loose the benefits of this > system when we compile apache on our own. I don't understand that at all. Can somebody help me out here? 73, Ged.
Re: segmentation fault using a startup file
Hello, Am Mit, 2002-11-27 um 17.33 schrieb Ged Haywood: > > On 27 Nov 2002, Jan Theofel wrote: > > > Am Mon, 2002-11-25 um 17.46 schrieb Jan Theofel: > > > > > > (Re)starting apache results in the following segmentation fault: > > > > The problem with this segmentation fault is XML::Simple > > [snip] > > All I could find is that you can either: > > 1. Compile your own apache > > [snip] > > What is it about compiling your own Apache that troubles you? It is a lot of work to do. Especially because we use SuSE Linux Enterprise Server which is a hihgly integrated system and we would loose the benefits of this system when we compile apache on our own. Jan -- Jan Theofel Fon: +49 (7 11) 48 90 83 - 0 ETES - EDV-Systemhaus GbRFax: +49 (7 11) 48 90 83 - 50 Libanonstrasse 58 A * D-70184 Stuttgart Web: http://www.etes.de __ Inflex - eMail Scanning and Protection Queries to: [EMAIL PROTECTED]
Re: segmentation fault using a startup file
Hi there, On 27 Nov 2002, Jan Theofel wrote: > Am Mon, 2002-11-25 um 17.46 schrieb Jan Theofel: > > > > (Re)starting apache results in the following segmentation fault: > > The problem with this segmentation fault is XML::Simple > [snip] > All I could find is that you can either: > 1. Compile your own apache > [snip] What is it about compiling your own Apache that troubles you? 73, Ged.
Re: segmentation fault using a startup file
Hello, Am Mon, 2002-11-25 um 17.46 schrieb Jan Theofel: > > (Re)starting apache results in the following segmentation fault: The problem with this segmentation fault is XML::Simple which I use togeather with mod_perl. This seems to be a knowen problem but without a known solution. All I could find is that you can either: 1. Compile your own apache 2. Use another XML parser perl module Is someone here with another solution? Thanks, Jan -- Jan Theofel Fon: +49 (7 11) 48 90 83 - 0 ETES - EDV-Systemhaus GbRFax: +49 (7 11) 48 90 83 - 50 Libanonstrasse 58 A * D-70184 Stuttgart Web: http://www.etes.de __ Inflex - eMail Scanning and Protection Queries to: [EMAIL PROTECTED]
RE: segmentation fault using a startup file
Yeah, Randy, I second the motion.
We know that DBI 1.28 does _NOT_ work!
Aloha => Beau.
-Original Message-
From: Randy Kobes [mailto:[EMAIL PROTECTED]]
Sent: Monday, November 25, 2002 7:34 AM
To: Jan Theofel
Cc: mod_perl mailinglist
Subject: Re: segmentation fault using a startup file
On 25 Nov 2002, Jan Theofel wrote:
> Hello,
>
> I have another problem using Perl::PerlRun with a startup file in
> apache. The line added to the apache configuration file was:
>
> PerlRequire /home/www/[...]/shop/engine/apachestartup.pl
>
> (Re)starting apache results in the following segmentation fault:
[ .. ]
> As soon as I remove the comment one of the modules which have a # at
> their line, I get the segmantation fault. (All modules named eq* are my
> own modules for that shop.)
>
> --- snip ---
> #!/usr/bin/perl -w
>
> $ENV{MOD_PERL} or die "ERROR: not running under mod_perl.\n";
>
> use lib "/home/www/[...]/shop/engine/";
> use strict;
>
> # use these Perl modules
> use Apache::PerlRun;
> # use Apache::DBI;
Do you have the latest DBI (1.30), and also the latest
appropriate DBD::* driver? If not, try upgrading to see if that
helps.
--
best regards,
randy kobes
Re: segmentation fault using a startup file
On 25 Nov 2002, Jan Theofel wrote:
> Hello,
>
> I have another problem using Perl::PerlRun with a startup file in
> apache. The line added to the apache configuration file was:
>
> PerlRequire /home/www/[...]/shop/engine/apachestartup.pl
>
> (Re)starting apache results in the following segmentation fault:
[ .. ]
> As soon as I remove the comment one of the modules which have a # at
> their line, I get the segmantation fault. (All modules named eq* are my
> own modules for that shop.)
>
> --- snip ---
> #!/usr/bin/perl -w
>
> $ENV{MOD_PERL} or die "ERROR: not running under mod_perl.\n";
>
> use lib "/home/www/[...]/shop/engine/";
> use strict;
>
> # use these Perl modules
> use Apache::PerlRun;
> # use Apache::DBI;
Do you have the latest DBI (1.30), and also the latest
appropriate DBD::* driver? If not, try upgrading to see if that
helps.
--
best regards,
randy kobes
Re: Segmentation Fault with mod_php and mod_perl
Doug and Stas,
I try to compile PHP with largefile support with no luck so I follow
Doug's advice and rebuild mod_perl with PERL_USELARGEFILES=0. This solves
the problem. Thanks a lot for helping me out!
Alex
>From: Doug MacEachern <[EMAIL PROTECTED]>
>To: Alex Lee <[EMAIL PROTECTED]>
>CC: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
>Subject: Re: Segmentation Fault with mod_php and mod_perl
>Date: Wed, 28 Aug 2002 19:09:07 -0700 (PDT)
>
>On Wed, 28 Aug 2002, Alex Lee wrote:
>
> > Stas,
> >
> > I am sorry, I got too excited when I saw the segmentation fault.
> > Here is the output of 'bt':
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x75a10 in php_xbithack_handler (r=0x927840) at mod_php4.c:778
> > 778 if (!(r->finfo.st_mode & S_IXUSR)) {
>
>99.99% sure this is largefiles related, as somebody else mentioned.
>you need to make sure php was compiled with the same flags as httpd.
>that is, if you built php before mod_perl, you need to recompile php so it
>uses the largefile flags. or.. rebuilt modperl/httpd with Makefile.PL
>PERL_USELARGEFILES=0
>
>
_
Chat with friends online, try MSN Messenger: http://messenger.msn.com
Re: Segmentation Fault with mod_php and mod_perl
On Wed, 28 Aug 2002, Alex Lee wrote:
> Stas,
>
> I am sorry, I got too excited when I saw the segmentation fault.
> Here is the output of 'bt':
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x75a10 in php_xbithack_handler (r=0x927840) at mod_php4.c:778
> 778 if (!(r->finfo.st_mode & S_IXUSR)) {
99.99% sure this is largefiles related, as somebody else mentioned.
you need to make sure php was compiled with the same flags as httpd.
that is, if you built php before mod_perl, you need to recompile php so it
uses the largefile flags. or.. rebuilt modperl/httpd with Makefile.PL
PERL_USELARGEFILES=0
Re: Segmentation Fault with mod_php and mod_perl
Stas,
I am sorry, I got too excited when I saw the segmentation fault.
Here is the output of 'bt':
Program received signal SIGSEGV, Segmentation fault.
0x75a10 in php_xbithack_handler (r=0x927840) at mod_php4.c:778
778 if (!(r->finfo.st_mode & S_IXUSR)) {
(gdb) bt
#0 0x75a10 in php_xbithack_handler (r=0x927840) at mod_php4.c:778
#1 0x17aeb0 in ap_invoke_handler ()
#2 0x199a28 in process_request_internal ()
#3 0x199aac in ap_process_request ()
#4 0x18c948 in child_main ()
#5 0x18cbdc in make_child ()
#6 0x18cdf8 in startup_children ()
#7 0x18d82c in standalone_main ()
#8 0x18e488 in main ()
Thanks for offering to help!
Alex
>From: Stas Bekman <[EMAIL PROTECTED]>
>To: Alex Lee <[EMAIL PROTECTED]>
>CC: [EMAIL PROTECTED]
>Subject: Re: Segmentation Fault with mod_php and mod_perl
>Date: Wed, 28 Aug 2002 11:00:42 +0800
>
>Alex Lee wrote:
>
>> This is what I got from core backtrace:
>>
>>gdb /usr/local/src/apache/current/src/httpd
>[...]
>>Program received signal SIGSEGV, Segmentation fault.
>>0x75a10 in php_xbithack_handler (r=0x927840) at mod_php4.c:778
>>778if (!(r->finfo.st_mode & S_IXUSR)) {
>
>please finish reading the section explaining how to get the backtrace.
>You've got only the first frame. You need to execute 'bt' or 'where' to get
>it all.
>
>>Are you going to say this is a PHP bug? :-)
>>But how come if I only activate PHP module, it works fine.
>
>Something affects a datastructure which PHP uses and segfaults in it. But
>get first the whole backtrace.
>
_
Chat with friends online, try MSN Messenger: http://messenger.msn.com
Re: Segmentation Fault with mod_php and mod_perl
Alex Lee wrote:
> This is what I got from core backtrace:
>
> gdb /usr/local/src/apache/current/src/httpd
[...]
> Program received signal SIGSEGV, Segmentation fault.
> 0x75a10 in php_xbithack_handler (r=0x927840) at mod_php4.c:778
> 778if (!(r->finfo.st_mode & S_IXUSR)) {
please finish reading the section explaining how to get the backtrace.
You've got only the first frame. You need to execute 'bt' or 'where' to
get it all.
> Are you going to say this is a PHP bug? :-)
> But how come if I only activate PHP module, it works fine.
Something affects a datastructure which PHP uses and segfaults in it.
But get first the whole backtrace.
> Alex
>
>> From: Stas Bekman <[EMAIL PROTECTED]>
>> To: Alex Lee <[EMAIL PROTECTED]>
>> CC: [EMAIL PROTECTED]
>> Subject: Re: Segmentation Fault with mod_php and mod_perl
>> Date: Tue, 27 Aug 2002 11:54:38 +0800
>>
>> Alex Lee wrote:
>>
>>> There seems to be conflict between mod_php 4.2.2 and mod_perl 1.27
>>> running with Apache 1.3.26 on Solaris 8 platform(FreeBSD with the
>>> same configuration seems to work fine).
>>
>> [...]
>>
>>> Segmentation Fault (11)
>>
>> [...]
>>
>>> running with "truss ./httpd -X" produce:
>>
>>
>> Sending the core backtrace should help more that the output of truss.
>> See
>> http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems
>> __
>> Stas BekmanJAm_pH --> Just Another mod_perl Hacker
>> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
>> mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
>> http://modperlbook.org http://apache.org http://ticketmaster.com
>
>
>
>
>
> _
> Send and receive Hotmail on your mobile device: http://mobile.msn.com
--
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Segmentation Fault with mod_php and mod_perl
Hi Stas,
This is what I got from core backtrace:
gdb /usr/local/src/apache/current/src/httpd
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.8"...
(gdb) run -X -f `pwd`/t/conf/httpd.conf -d `pwd`/t
Starting program: /usr/local/src/apache/current/src/httpd -X -f
`pwd`/t/conf/httpd.conf -d `pwd`/t
[New LWP 1]
[New LWP 2]
[New LWP 3]
[New LWP 4]
Program received signal SIGSEGV, Segmentation fault.
0x75a10 in php_xbithack_handler (r=0x927840) at mod_php4.c:778
778 if (!(r->finfo.st_mode & S_IXUSR)) {
Are you going to say this is a PHP bug? :-)
But how come if I only activate PHP module, it works fine.
Alex
>From: Stas Bekman <[EMAIL PROTECTED]>
>To: Alex Lee <[EMAIL PROTECTED]>
>CC: [EMAIL PROTECTED]
>Subject: Re: Segmentation Fault with mod_php and mod_perl
>Date: Tue, 27 Aug 2002 11:54:38 +0800
>
>Alex Lee wrote:
>>There seems to be conflict between mod_php 4.2.2 and mod_perl 1.27 running
>>with Apache 1.3.26 on Solaris 8 platform(FreeBSD with the same
>>configuration seems to work fine).
>[...]
>>Segmentation Fault (11)
>[...]
>>running with "truss ./httpd -X" produce:
>
>Sending the core backtrace should help more that the output of truss.
>See
>http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems
>__
>Stas BekmanJAm_pH --> Just Another mod_perl Hacker
>http://stason.org/ mod_perl Guide ---> http://perl.apache.org
>mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
>http://modperlbook.org http://apache.org http://ticketmaster.com
_
Send and receive Hotmail on your mobile device: http://mobile.msn.com
Re: Segmentation Fault with mod_php and mod_perl
On Monday, 2002-08-26 at 10:43:57 -0700, Alex Lee wrote: > There seems to be conflict between mod_php 4.2.2 and mod_perl 1.27 running > with Apache 1.3.26 on Solaris 8 platform(FreeBSD with the same > configuration seems to work fine). > Please help! > Or if you know of a working combination of Apache/mod_perl/mod_php on > Solaris 8, let me know.. I had that a while ago. It is probably a problem with largefile support. Statically linking both mod_perl and mod_php worked for me, same versions you have. But I have to admit the version somebody else compiled crashed like your statically linked apache. The way I do it, and it is possible this avoids the problem is to first do apache+mod_perl, sans mod_php. If this tests OK, I "make install" mod_php, and do mod_perl again. The first step may leave some traces mod_php picks up. HTH, Lupe Christoph -- | [EMAIL PROTECTED] | http://www.lupe-christoph.de/ | | Big Misunderstandings #6398: The Titanic was not supposed to be| | unsinkable. The designer had a speech impediment. He said: "I have | | thith great unthinkable conthept ..." |
Re: Segmentation Fault with mod_php and mod_perl
Alex Lee wrote: > There seems to be conflict between mod_php 4.2.2 and mod_perl 1.27 > running with Apache 1.3.26 on Solaris 8 platform(FreeBSD with the same > configuration seems to work fine). [...] > Segmentation Fault (11) [...] > running with "truss ./httpd -X" produce: Sending the core backtrace should help more that the output of truss. See http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Segmentation Fault with mod_php and mod_perl
Hmm. That's what I did in the first place and I can't even get Apache to
compile in that case. It kept complaining about mod_proxy can't resolve some
external symbols, if I remember correctly. So I thought maybe you can't do
both DSO and static at the same time. After I changed both to static linked,
it compiled fine. But then keep getting segmentation fault when accessing
the default page. The strange thing is that perl CGI programs run fine.
Alex
>From: "C. David Wilde" <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: "Alex Lee" <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
>Subject: Re: Segmentation Fault with mod_php and mod_perl
>Date: Mon, 26 Aug 2002 12:54:04 -0700
>
>On Monday 26 August 2002 10:43 am, Alex Lee wrote:
>I ran into this on a RH7 box. I compiled mod_perl into apache and compiled
>PHP as a DSO with APXS. Worked for me, but YMMV.
>
> > There seems to be conflict between mod_php 4.2.2 and mod_perl 1.27
>running
> > with Apache 1.3.26 on Solaris 8 platform(FreeBSD with the same
> > configuration seems to work fine).
> >
> > The Apache configuration as follows:
> >
> > CC="gcc" \
> > CFLAGS=" -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE
> > -D_FILE_OFFSET_BITS=64" \
> >
> > ./configure \
> > "--with-layout=Apache" \
> > "--prefix=/usr/apache" \
> > "--enable-module=info" \
> > "--enable-module=proxy" \
> > "--enable-module=usertrack" \
> > "--enable-module=rewrite" \
> > "--enable-module=speling" \
> > "--activate-module=src/modules/perl/libperl.a" \
> > "--activate-module=src/modules/php4/libphp4.a" \
> > "--disable-rule=EXPAT" \
> > "$@"
> >
> > will cause Apache to Segmentation fault:
> > [Wed Aug 21 11:59:47 2002] [notice] child pid 17907 exit signal
> > Segmentation Fault (11)
> > when accessing the default page(index.html). But the CGI script runs
> > fine, so does "server-status" and "server-info".
> >
> > If I take out the activate-module line for either mod_perl or mod_php,
> > the problem disapper.
> >
> > BTW, the mod_perl "make test" runs fine.
> >
> > running with "truss ./httpd -X" produce:
> >
> > lwp_cond_wait(0xFEFE5550, 0xFEFE5560, 0xFEFDEDB8) (sleeping...)
> > lwp_cond_wait(0xFEFE5550, 0xFEFE5560, 0xFEFDEDB8) (sleeping...)
> > door_return(0x, 0, 0x, 0) (sleeping...)
> > accept(16, 0xFFBEF798, 0xFFBEF7BC, 1)= 5
> > fcntl(19, F_SETLKW64, 0x00301C60)= 0
> > sigaction(SIGUSR1, 0xFFBEF5D0, 0xFFBEF6D0) = 0
> > getsockname(5, 0xFFBEF7A8, 0xFFBEF7BC, 1)= 0
> > setsockopt(5, 6, 1, 0xFFBEF70C, 4, 1)= 0
> > alarm(300) = 0
> > read(5, " G E T / H T T P / 1".., 4096) = 404
> > sigaction(SIGUSR1, 0xFFBED4C0, 0xFFBED5C0) = 0
> > time() = 1029956894
> > alarm(300) = 300
> > alarm(0) = 300
> > stat64("/usr/apache/htdocs", 0x00425108) = 0
> > sigaction(SIGALRM, 0x, 0xFFBEF490) = 0
> > stat64("/usr/apache/htdocs/index.html", 0x0044A108) = 0
> > stat64("/usr/apache/htdocs/index.html", 0x00425EC0) = 0
> > Incurred fault #6, FLTBOUNDS %pc = 0x00073554
> > siginfo: SIGSEGV SEGV_MAPERR addr=0x0060
> > Received signal #11, SIGSEGV [default]
> > siginfo: SIGSEGV SEGV_MAPERR addr=0x0060
> > *** process killed ***
> >
> > Please help!
> > Or if you know of a working combination of Apache/mod_perl/mod_php on
> > Solaris 8, let me know..
> >
> > Thanks!
> >
> > Alex
> >
> >
> > _
> > Send and receive Hotmail on your mobile device: http://mobile.msn.com
_
Join the worlds largest e-mail service with MSN Hotmail.
http://www.hotmail.com
Re: Segmentation Fault with mod_php and mod_perl
On Monday 26 August 2002 10:43 am, Alex Lee wrote:
I ran into this on a RH7 box. I compiled mod_perl into apache and compiled
PHP as a DSO with APXS. Worked for me, but YMMV.
> There seems to be conflict between mod_php 4.2.2 and mod_perl 1.27 running
> with Apache 1.3.26 on Solaris 8 platform(FreeBSD with the same
> configuration seems to work fine).
>
> The Apache configuration as follows:
>
> CC="gcc" \
> CFLAGS=" -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE
> -D_FILE_OFFSET_BITS=64" \
>
> ./configure \
> "--with-layout=Apache" \
> "--prefix=/usr/apache" \
> "--enable-module=info" \
> "--enable-module=proxy" \
> "--enable-module=usertrack" \
> "--enable-module=rewrite" \
> "--enable-module=speling" \
> "--activate-module=src/modules/perl/libperl.a" \
> "--activate-module=src/modules/php4/libphp4.a" \
> "--disable-rule=EXPAT" \
> "$@"
>
> will cause Apache to Segmentation fault:
> [Wed Aug 21 11:59:47 2002] [notice] child pid 17907 exit signal
> Segmentation Fault (11)
> when accessing the default page(index.html). But the CGI script runs
> fine, so does "server-status" and "server-info".
>
> If I take out the activate-module line for either mod_perl or mod_php,
> the problem disapper.
>
> BTW, the mod_perl "make test" runs fine.
>
> running with "truss ./httpd -X" produce:
>
> lwp_cond_wait(0xFEFE5550, 0xFEFE5560, 0xFEFDEDB8) (sleeping...)
> lwp_cond_wait(0xFEFE5550, 0xFEFE5560, 0xFEFDEDB8) (sleeping...)
> door_return(0x, 0, 0x, 0) (sleeping...)
> accept(16, 0xFFBEF798, 0xFFBEF7BC, 1) = 5
> fcntl(19, F_SETLKW64, 0x00301C60) = 0
> sigaction(SIGUSR1, 0xFFBEF5D0, 0xFFBEF6D0) = 0
> getsockname(5, 0xFFBEF7A8, 0xFFBEF7BC, 1) = 0
> setsockopt(5, 6, 1, 0xFFBEF70C, 4, 1) = 0
> alarm(300) = 0
> read(5, " G E T / H T T P / 1".., 4096)= 404
> sigaction(SIGUSR1, 0xFFBED4C0, 0xFFBED5C0) = 0
> time() = 1029956894
> alarm(300) = 300
> alarm(0) = 300
> stat64("/usr/apache/htdocs", 0x00425108) = 0
> sigaction(SIGALRM, 0x, 0xFFBEF490) = 0
> stat64("/usr/apache/htdocs/index.html", 0x0044A108) = 0
> stat64("/usr/apache/htdocs/index.html", 0x00425EC0) = 0
> Incurred fault #6, FLTBOUNDS %pc = 0x00073554
> siginfo: SIGSEGV SEGV_MAPERR addr=0x0060
> Received signal #11, SIGSEGV [default]
> siginfo: SIGSEGV SEGV_MAPERR addr=0x0060
>*** process killed ***
>
> Please help!
> Or if you know of a working combination of Apache/mod_perl/mod_php on
> Solaris 8, let me know..
>
> Thanks!
>
> Alex
>
>
> _
> Send and receive Hotmail on your mobile device: http://mobile.msn.com
Re: Segmentation fault
Vitor wrote: > Hello Folks, > > I am having a big problem here. > > While i try to open a new Mail::CClient connection, i get these message : > > [Fri Jul 19 17:56:28 2002] [notice] child pid 6146 exit signal Segmentation > fault (11) > > I am using Perl 5.6.1, Apache/1.3.23 , PHP/4.1.1 mod_perl/1.26, without > shared libraries, and HTML::Mason templating system. > > I don't know if is a callback problem, because to login, Mail::CClient uses > a login callback. > > It works well as a cgi, but under mod_perl/Mason, i get those message. You need to send a backtrace and other info as explained at: http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems and probably post it to the mason list and not here if this happens only under mason. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Segmentation fault 11 (php/mod_perl)
Bob Pickles wrote: > I've been hacking at this a couple days. At first I really wanted to > get mod_perl working as a DSO. Got everything compiled, and added lines > to httpd.conf. Died on startup if I had AddModule mod_perl.c. > Following a tip on this list, I gave up on DSO and went static > compile. And then what happened? Did you start with a clean conf file? There should be no LoadModule/AddModule stuff in it for a static server. - Perrin
Apache::Site [WAS] Re: Segmentation fault
> > We already did this! The question is - with 2 apache config, > > proxy-front-end apache logs every request, even if power apache daemon > > crushed with segfault, simple-proxy daemon logs request with URI and > > 502 status. We know time of segfault and can find 502 request in > > access logs with such time, and we can find out a request, wich causes > > seg fault. All right. It's working for 2 apache config. If we use > > simple 1 apache daemon, I think, we will have in logs segfault message > > only. Is there way to find out segfault request for simple > > configuration ? > > Provide a custom loghandler, which runs before the content generation phase > or whichever phase the segfault happens at. Though you won't know the > status, > but there is nothing you can do after segfault. Or I can think of two steps > handler, which let's say logs something before the potentially segfaulting > handler and the status after the handler is run. So in case of segfaults > the status will be missing. (First of all, sorry for gruesome english) Thank you for response. As I understand, with simple configuration we should assign global URI translation (for instance) handler where we will log request's URI. After segfault we can find (via awk or other text processor) logged URI without status. Right? Huh... I think installation of mod_accel or mod_proxy front-end is simpler solution. Thank you again and I will be happy to hear some feedback from mod_perl guru about module, which was developed by my team. It's another framework and Matt Sergeant compared it with Mason although it is much simpler and we purposed other aims. Our target was to ease implementing web application as Apache handler, because, we consider web site not a collection of html generating page-scripts, (Apache::Registry, ASP and many other technix way), but whole application with one entry point - Apache handler. We think that URI processing and translating is a task of application, at any case for projects such large e-shop or central online information portal of region. Another aim was to integrate TemplateToolkit usage as standart output technique - it is excellent app, although descendant from our module can return another status (redirect and others) or generate output via another way freely. Our module helps to maintain high performance web application as pure Apache handler is fast and easy and programmer focuses on business tasks of site only. I put part of our programmer's letter below and ask - is there future for such module? | We develope the Module that will be capable of: | * use simple interface for dynamic site creating (and dynamic parts for | any almost static site); | * use simple urls with no query strings at all; | * use smart templates (standard header and footer, for example). | | That very early beta works on: | * http://www.neftechimia.ru/en/ -- business site | * http://review.samara.ru/ -- newspaper site | | Note that the module is filter-aware and on "Neftechimia" there is AxKit | postprocessing | (that slowers down overall request performance six(!!!) times (I think this | may be changed | with new AxKit's Provider) but simplifies site supporting for | non-professional webmaster | -- all templates may be changed through the web-interface) | | III. THE FUTURE | | Though we need some advices: | * is there any need for such thing? | * if so, which name we should choose (it's Apache::Site for now)? | * what features must it also have? | * what do you think about it? | | IV. THE CODE | | As I said above it is very early beta. No POD, Comments only. | * http://www.webzavod.ru/software/Apache-Site.tar.gz | | V. THE AUTHOR | | Gregory "Grishace" [gree-shah-s] Belenky | WebZavod (http://www.webzavod.ru/) programmer | Sergey Polyakov aka "BeerBong" Chief of WebZavod http://www.webzavod.ru Tel. +7 (8462) 43-93-85 | +7 (8462) 43-93-86 mailto:[EMAIL PROTECTED]
Re: Segmentation fault
BeerBong wrote: > We already did this! The question is - with 2 apache config, > proxy-front-end apache logs every request, even if power apache daemon > crushed with segfault, simple-proxy daemon logs request with URI and > 502 status. We know time of segfault and can find 502 request in > access logs with such time, and we can find out a request, wich causes > seg fault. All right. It's working for 2 apache config. If we use > simple 1 apache daemon, I think, we will have in logs segfault message > only. Is there way to find out segfault request for simple > configuration ? Provide a custom loghandler, which runs before the content generation phase or whichever phase the segfault happens at. Though you won't know the status, but there is nothing you can do after segfault. Or I can think of two steps handler, which let's say logs something before the potentially segfaulting handler and the status after the handler is run. So in case of segfaults the status will be missing. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Segmentation fault
- Original Message - From: "Ged Haywood" <[EMAIL PROTECTED]> To: "Gregory Belenky" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Saturday, February 09, 2002 12:39 AM Subject: Re: Segmentation fault > Hi there, > > On Fri, 8 Feb 2002, Gregory Belenky wrote: > > > Just found that Apache::Util::unescape_uri when gets undefined value as > > parameter not returns undefined value, but make SUBJ! > > Why that's happens? > > Perhaps I'm being dense, I do not understand the question. What is "SUBJ"? SUBJ = subject. Apache::Util has a bug which causes segemntation fault. We know this, and solve the problem - we prevent passing possible empty string to this method. > > > if we have to use one mod_perl-powered Apache - how we can find > > request, that breaks server? > > Would it not be better to prevent the server from breaking? We already did this! The question is - with 2 apache config, proxy-front-end apache logs every request, even if power apache daemon crushed with segfault, simple-proxy daemon logs request with URI and 502 status. We know time of segfault and can find 502 request in access logs with such time, and we can find out a request, wich causes seg fault. All right. It's working for 2 apache config. If we use simple 1 apache daemon, I think, we will have in logs segfault message only. Is there way to find out segfault request for simple configuration ? > > 73, > Ged. > > > >
Re: Segmentation fault
Hi there, On Fri, 8 Feb 2002, Gregory Belenky wrote: > Just found that Apache::Util::unescape_uri when gets undefined value as > parameter not returns undefined value, but make SUBJ! > Why that's happens? Perhaps I'm being dense, I do not understand the question. What is "SUBJ"? > if we have to use one mod_perl-powered Apache - how we can find > request, that breaks server? Would it not be better to prevent the server from breaking? 73, Ged.
Re: segmentation fault child pid exit
Hi there, On Mon, 24 Sep 2001, Chaiyakul, Annie wrote: > I am running apache 1.3.19, mod_perl 1.26 mod_ssl 2.7.1-1.3.14 mm-1.1.3, > openssl-0.9.6, and perl 5.6.1 [snip] > let me know what information I need to provide. Please read the file called SUPPORT in your mod_perl directory. You might also search the mod_perl List archives for mention of mod_ssl, it frequently appears... 73, Ged.
Re: Segmentation Fault
Andrei A. Voropaev wrote: > The funny part is that in our case we also get Segmentation fault from time to > time but there's no coredump file. That's because your environment is set not to allow core dumps. I have posted the details of how to set it up a few weeks ago, Please check the list. > I even tried to attach gdb to apache child > and wait for Segfault. I got it but I'm not sure I could understand it. Please > see below for examples. > > The only thing I can say here that after we drastically reduced usage of > module Carp.pm the Segmentation faults almost disappeared. (I mean it. Before > the change we had Segfaults 5-6 times every minute. Now we have it once in > 20-30 minutes). Please note that Carp::croak was used by Mason object in > method 'abort' so we had to stop using it. Yup, unfortunately we are going to see a lot of posts caused by people using 5.6.0 as all major linux distros has this version by default. BTW, I've installed Mandrake 8.1beta3 a few days ago (a release candidate, which is really great :) and it comes 5.6.1!!! So I hope that all new distros will be informed enough to adopt 5.6.1. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Segmentation Fault
At 10:33 AM +0400 9/20/01, Andrei A. Voropaev wrote:
>The funny part is that in our case we also get Segmentation fault from time to
>time but there's no coredump file. I even tried to attach gdb to apache child
>and wait for Segfault. I got it but I'm not sure I could understand it. Please
>see below for examples.
>
>The only thing I can say here that after we drastically reduced usage of
>module Carp.pm the Segmentation faults almost disappeared. (I mean it. Before
>the change we had Segfaults 5-6 times every minute. Now we have it once in
>20-30 minutes). Please note that Carp::croak was used by Mason object in
>method 'abort' so we had to stop using it.
I had this very same problem on a system I setup last november for
the 2000 elections. We had three servers, all running linux, apache,
and mod_perl (probably all different versions), and this was the only
box that core dumped.
I later discovered that there was a bug in Carp under perl 5.6.0 and
that upgrading would have fixed my problem...
At 10:32 AM -0800 1/31/01, Doug MacEachern wrote:
>On Wed, 31 Jan 2001, Robert Landrum wrote:
>
>> Has anyone else had problems with the Carp module and mod_perl?
>
>there were bugs related to Carp in 5.6.0, fixed in 5.6.1-trial1,2
You can continue to use Mason by putting a line in startup.pl
*Carp::croak = sub { die };
*Carp::carp = sub { warn };
Rob
>Andrei
>
>--
>Program received signal SIGSEGV, Segmentation fault.
>0x406041ec in Perl_sv_setsv () from /etc/httpd/modules/libperl.so
>(gdb) bt
>#0 0x406041ec in Perl_sv_setsv () from /etc/httpd/modules/libperl.so
>#1 0x405fa329 in Perl_pp_sassign () from /etc/httpd/modules/libperl.so
>#2 0x405f9f0a in Perl_runops_standard () from /etc/httpd/modules/libperl.so
>#3 0x405ba456 in S_call_body () from /etc/httpd/modules/libperl.so
>#4 0x405ba028 in perl_call_sv () from /etc/httpd/modules/libperl.so
>#5 0x405ef71f in Perl_vdie () from /etc/httpd/modules/libperl.so
>#6 0x405ef859 in Perl_die () from /etc/httpd/modules/libperl.so
>#7 0x406231f6 in Perl_pp_die () from /etc/httpd/modules/libperl.so
>#8 0x405f9f0a in Perl_runops_standard () from /etc/httpd/modules/libperl.so
>#9 0x405ba456 in S_call_body () from /etc/httpd/modules/libperl.so
>#10 0x405ba231 in perl_call_sv () from /etc/httpd/modules/libperl.so
>#11 0x4059c225 in perl_call_handler () from /etc/httpd/modules/libperl.so
>#12 0x4059ba6b in perl_run_stacked_handlers () from
>/etc/httpd/modules/libperl.so
>#13 0x4059a1c8 in perl_handler () from /etc/httpd/modules/libperl.so
>#14 0x08054ead in ap_invoke_handler () at eval.c:41
>#15 0x0806704c in ap_some_auth_required () at eval.c:41
>#16 0x080670c3 in ap_process_request () at eval.c:41
>#17 0x0805f6d7 in ap_child_terminate () at eval.c:41
>#18 0x0805f919 in ap_child_terminate () at eval.c:41
>#19 0x0805fc6b in ap_child_terminate () at eval.c:41
>#20 0x080601ac in ap_child_terminate () at eval.c:41
>#21 0x080608a3 in main () at eval.c:41
>#22 0x40141177 in __libc_start_main (main=0x8060420 , argc=3,
>ubp_av=0xbb3c,
>init=0x804fa50 <_init>, fini=0x808a570 <_fini>, rtld_fini=0x4000e184
><_dl_fini>,
>stack_end=0xbb2c) at ../sysdeps/generic/libc-start.c:129
>
>(gdb) info frame
> Stack level 0, frame at 0xb418:
> eip = 0x406041ec in Perl_sv_setsv; saved eip 0x405fa329
> called by frame at 0xb448
> Arglist at 0xb418, args:
> Locals at 0xb418, Previous frame's sp is 0x0
> Saved registers:
> ebx at 0xb40c, ebp at 0xb418, esi at 0xb410, edi at 0xb414,
> eip at 0xb41c
>-
>
>(gdb) bt
>#0 0x406059be in Perl_sv_clear () from /etc/httpd/modules/libperl.so
>#1 0x40605d6f in Perl_sv_free () from /etc/httpd/modules/libperl.so
>#2 0x405f8afd in Perl_av_clear () from /etc/httpd/modules/libperl.so
>#3 0x40618ea9 in Perl_leave_scope () from /etc/httpd/modules/libperl.so
>#4 0x4061758c in Perl_pop_scope () from /etc/httpd/modules/libperl.so
>#5 0x4061c535 in Perl_die_where () from /etc/httpd/modules/libperl.so
>#6 0x405efb5a in Perl_vcroak () from /etc/httpd/modules/libperl.so
>#7 0x405efbf9 in Perl_croak () from /etc/httpd/modules/libperl.so
>#8 0x406039a5 in Perl_sv_setsv () from /etc/httpd/modules/libperl.so
>#9 0x405fbd47 in Perl_pp_aassign () from /etc/httpd/modules/libperl.so
>#10 0x405f9f0a in Perl_runops_standard () from /etc/httpd/modules/libperl.so
>#11 0x405ba456 in S_call_body () from /etc/httpd/modules/libperl.so
>#12 0x405ba028 in perl_call_sv () from /etc/httpd/modules/libperl.so
>#13 0x405ef71f in Perl_vdie () from /etc/httpd/modules/libperl.so
>#14 0x405ef859 in Perl_die () from /etc/httpd/modules/libperl.so
>#15 0x406231f6 in Perl_pp_die () from /etc/httpd/modules/libperl.so
>#16 0x405f9f0a in Perl_runops_standard () from /etc/httpd/modules/libperl.so
>#17 0x405ba456 in S_call_body () from /etc/httpd/modules/libperl.so
>#18 0x405ba231 in
Re: Segmentation Fault
The funny part is that in our case we also get Segmentation fault from time to time but there's no coredump file. I even tried to attach gdb to apache child and wait for Segfault. I got it but I'm not sure I could understand it. Please see below for examples. The only thing I can say here that after we drastically reduced usage of module Carp.pm the Segmentation faults almost disappeared. (I mean it. Before the change we had Segfaults 5-6 times every minute. Now we have it once in 20-30 minutes). Please note that Carp::croak was used by Mason object in method 'abort' so we had to stop using it. Andrei -- Program received signal SIGSEGV, Segmentation fault. 0x406041ec in Perl_sv_setsv () from /etc/httpd/modules/libperl.so (gdb) bt #0 0x406041ec in Perl_sv_setsv () from /etc/httpd/modules/libperl.so #1 0x405fa329 in Perl_pp_sassign () from /etc/httpd/modules/libperl.so #2 0x405f9f0a in Perl_runops_standard () from /etc/httpd/modules/libperl.so #3 0x405ba456 in S_call_body () from /etc/httpd/modules/libperl.so #4 0x405ba028 in perl_call_sv () from /etc/httpd/modules/libperl.so #5 0x405ef71f in Perl_vdie () from /etc/httpd/modules/libperl.so #6 0x405ef859 in Perl_die () from /etc/httpd/modules/libperl.so #7 0x406231f6 in Perl_pp_die () from /etc/httpd/modules/libperl.so #8 0x405f9f0a in Perl_runops_standard () from /etc/httpd/modules/libperl.so #9 0x405ba456 in S_call_body () from /etc/httpd/modules/libperl.so #10 0x405ba231 in perl_call_sv () from /etc/httpd/modules/libperl.so #11 0x4059c225 in perl_call_handler () from /etc/httpd/modules/libperl.so #12 0x4059ba6b in perl_run_stacked_handlers () from /etc/httpd/modules/libperl.so #13 0x4059a1c8 in perl_handler () from /etc/httpd/modules/libperl.so #14 0x08054ead in ap_invoke_handler () at eval.c:41 #15 0x0806704c in ap_some_auth_required () at eval.c:41 #16 0x080670c3 in ap_process_request () at eval.c:41 #17 0x0805f6d7 in ap_child_terminate () at eval.c:41 #18 0x0805f919 in ap_child_terminate () at eval.c:41 #19 0x0805fc6b in ap_child_terminate () at eval.c:41 #20 0x080601ac in ap_child_terminate () at eval.c:41 #21 0x080608a3 in main () at eval.c:41 #22 0x40141177 in __libc_start_main (main=0x8060420 , argc=3, ubp_av=0xbb3c, init=0x804fa50 <_init>, fini=0x808a570 <_fini>, rtld_fini=0x4000e184 <_dl_fini>, stack_end=0xbb2c) at ../sysdeps/generic/libc-start.c:129 (gdb) info frame Stack level 0, frame at 0xb418: eip = 0x406041ec in Perl_sv_setsv; saved eip 0x405fa329 called by frame at 0xb448 Arglist at 0xb418, args: Locals at 0xb418, Previous frame's sp is 0x0 Saved registers: ebx at 0xb40c, ebp at 0xb418, esi at 0xb410, edi at 0xb414, eip at 0xb41c - (gdb) bt #0 0x406059be in Perl_sv_clear () from /etc/httpd/modules/libperl.so #1 0x40605d6f in Perl_sv_free () from /etc/httpd/modules/libperl.so #2 0x405f8afd in Perl_av_clear () from /etc/httpd/modules/libperl.so #3 0x40618ea9 in Perl_leave_scope () from /etc/httpd/modules/libperl.so #4 0x4061758c in Perl_pop_scope () from /etc/httpd/modules/libperl.so #5 0x4061c535 in Perl_die_where () from /etc/httpd/modules/libperl.so #6 0x405efb5a in Perl_vcroak () from /etc/httpd/modules/libperl.so #7 0x405efbf9 in Perl_croak () from /etc/httpd/modules/libperl.so #8 0x406039a5 in Perl_sv_setsv () from /etc/httpd/modules/libperl.so #9 0x405fbd47 in Perl_pp_aassign () from /etc/httpd/modules/libperl.so #10 0x405f9f0a in Perl_runops_standard () from /etc/httpd/modules/libperl.so #11 0x405ba456 in S_call_body () from /etc/httpd/modules/libperl.so #12 0x405ba028 in perl_call_sv () from /etc/httpd/modules/libperl.so #13 0x405ef71f in Perl_vdie () from /etc/httpd/modules/libperl.so #14 0x405ef859 in Perl_die () from /etc/httpd/modules/libperl.so #15 0x406231f6 in Perl_pp_die () from /etc/httpd/modules/libperl.so #16 0x405f9f0a in Perl_runops_standard () from /etc/httpd/modules/libperl.so #17 0x405ba456 in S_call_body () from /etc/httpd/modules/libperl.so #18 0x405ba231 in perl_call_sv () from /etc/httpd/modules/libperl.so #19 0x4059c225 in perl_call_handler () from /etc/httpd/modules/libperl.so #20 0x4059ba6b in perl_run_stacked_handlers () from /etc/httpd/modules/libperl.so #21 0x4059a1c8 in perl_handler () from /etc/httpd/modules/libperl.so #22 0x08054ead in ap_invoke_handler () at eval.c:41 #23 0x0806704c in ap_some_auth_required () at eval.c:41 #24 0x080670c3 in ap_process_request () at eval.c:41 #25 0x0805f6d7 in ap_child_terminate () at eval.c:41 #26 0x0805f919 in ap_child_terminate () at eval.c:41 #27 0x0805fc6b in ap_child_terminate () at eval.c:41 #28 0x080601ac in ap_child_terminate () at eval.c:41 #29 0x080608a3 in main () at eval.c:41 #30 0x40141177 in __libc_start_main (main=0x8060420 , argc=3, ubp_av=0xbb3c, init=0x804fa50 <_init>, fini=0x808a570 <_fini>, rtld_fini=0x4000e184 <_
Re: Segmentation Fault
[EMAIL PROTECTED] wrote: > Hi All, > > We are rigorously testing our application and trying to refresh the page > continously... I know the customer will be a nerd to do this but still a > possibility. > Interestingly after some repeated attempts we get the following error in our > log file. > > [Wed Sep 19 13:56:02 2001] [notice] child pid 1041 exit signal Segmentation > fault (11) > > Highly appreciated if anyone can throw some light. You have to send the backtrace. See the SUPPORT file for more details. Make sure to setup your enviroment so it'll dump core on segv. In bash run: % ulimit -c unlimited before starting the server (from the same console). _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Segmentation Fault (11)
On Sat, 23 Jun 2001, Douglas C. Heestand wrote: > I am getting the following messages in my "back-end" apache install logfile > (the one that handles perl scripts using mod_perl and PerlRun)... > > [17:03:49 2001] [notice] child pid 15064 exit signal Segmentation Fault (11) > [17:04:27 2001] [notice] child pid 17127 exit signal Segmentation Fault (11) > [17:04:55 2001] [notice] child pid 15065 exit signal Segmentation Fault (11) > [17:05:06 2001] [notice] child pid 17102 exit signal Segmentation Fault (11) > > I am running... > > Apache: 1.3.19 (for both front-end and back-end) > mod_perl: 1.25 > perl: 5.005_03 > > > The httpd processes can last for about 10 minutes before they all die off > and get respawned. > > Any ideas on where I should start looking to debug this problem? You will find SUPPORT file in the mod_perl source distro. Follow the intructions in this file. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: segmentation fault when using custom config module
On Wed, 29 Nov 2000, Dave Rolsky wrote: > I created a module that contains custom configs with the following code: i cannot reproduce this with or without the patch just posted. i did have to change this line for it to run: $AH = HTML::Mason::ApacheHandler( interp => $interp ); to: $AH = HTML::Mason::ApacheHandler->new( interp => $interp ); but it only caused a server error, no core dump. give the patch a shot anyhow, if you're still having this problem, we'll need a stack trace (see SUPPORT).
Perl 5.6.1 - When? [Was Re: Segmentation fault]
On Fri, Dec 15, 2000 at 09:43:05AM -0500, Vivek Khera wrote: > > Is there some place that has collected the "recommended" patches for > 5.6.0? There don't seem to be any patches for it on CPAN... You'd > think that 5.6.1 would come out by now to fix up the problems people > have been having with 5.6 especially in mod_perl... 5.6.1-trial1 expected by this weekend. That should include all the recommended list of patches for 5.6.0. See: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-12/msg00586.html Ajit
Re: Segmentation fault
> "JH" == Jeremy Howard <[EMAIL PROTECTED]> writes: JH> I suggested applying this patch: JH> http://www.geocrawler.com/archives/3/182/2000/6/0/3863601/ JH> Did this not work? After applying the patch did you recompile both Perl JH> _and_ mod_perl? Is there some place that has collected the "recommended" patches for 5.6.0? There don't seem to be any patches for it on CPAN... You'd think that 5.6.1 would come out by now to fix up the problems people have been having with 5.6 especially in mod_perl... -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
RE: Segmentation fault
On Thu, 14 Dec 2000, Per Moeller wrote: > A couple of days ago I asked the question below, but nobody seemed to be > able to answer it. > > Well, in case somebody else runs into this problem I can tell that my > solution to the problem was to use perl5.005 and not install perl5.6.0 until > after i completed the installation of mod_perl / Apache and the modules i > needed for it. Huh? You've built mod_perl with one version of perl, but then installed another binary incompatible (+ different hardcoded INC) perl version and you think to get away with that? All the new modules that you are going to build won't work with mod_perl if they have XS in them and you build these with another perl version... Unless you've managed to keep both installation around, but then it doesn't matter. > > // Per Moeller > > > -Original Message- > > From: Per Moeller [mailto:[EMAIL PROTECTED]] > > Sent: 12. december 2000 23:49 > > To: [EMAIL PROTECTED] > > Subject: Segmentation fault > > > > > > Does anyone have problems with Apache 1.3.12 / Mod_perl 1.24 making it's > > childs do segmentation faults whenever the server is requested to execute > a > > mod_perl module? > > > > If I request a piece of graphics, it works fine, but not if the page is > > generated by mod_perl. I have no compile errors, all the modules works on > > the previous development machine but not on this newly installed machine. > > > > The only difference I can see, is that I installed perl 5.6.0 before > > installing the mod_perl apache, should that cause any problems? > > > > The system is running on FreeBSD 4.2. > > > > > > // Per Moeller > > > > > > _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Segmentation fault
Per Moeller wrote: > A couple of days ago I asked the question below, but nobody seemed to be > able to answer it. > > Well, in case somebody else runs into this problem I can tell that my > solution to the problem was to use perl5.005 and not install perl5.6.0 until > after i completed the installation of mod_perl / Apache and the modules i > needed for it. > I suggested applying this patch: http://www.geocrawler.com/archives/3/182/2000/6/0/3863601/ Did this not work? After applying the patch did you recompile both Perl _and_ mod_perl?
RE: Segmentation fault
A couple of days ago I asked the question below, but nobody seemed to be able to answer it. Well, in case somebody else runs into this problem I can tell that my solution to the problem was to use perl5.005 and not install perl5.6.0 until after i completed the installation of mod_perl / Apache and the modules i needed for it. // Per Moeller > -Original Message- > From: Per Moeller [mailto:[EMAIL PROTECTED]] > Sent: 12. december 2000 23:49 > To: [EMAIL PROTECTED] > Subject: Segmentation fault > > > Does anyone have problems with Apache 1.3.12 / Mod_perl 1.24 making it's > childs do segmentation faults whenever the server is requested to execute a > mod_perl module? > > If I request a piece of graphics, it works fine, but not if the page is > generated by mod_perl. I have no compile errors, all the modules works on > the previous development machine but not on this newly installed machine. > > The only difference I can see, is that I installed perl 5.6.0 before > installing the mod_perl apache, should that cause any problems? > > The system is running on FreeBSD 4.2. > > > // Per Moeller > >
Re: Segmentation fault
> "PM" == Per Moeller <[EMAIL PROTECTED]> writes: PM> The only difference I can see, is that I installed perl 5.6.0 before PM> installing the mod_perl apache, should that cause any problems? PM> The system is running on FreeBSD 4.2. A mod_perl snapshot from CVS as of yesterday works just fine with the stock perl 5.005_03 that is part of FreeBSD 4.2. What I do is install apache+mod_ssl from /usr/ports/www/apache13-modssl, then install mod_perl from a cvs checked out copy using apxs (just follow the instructions in README.apaci). Works great. As for moving to perl 5.6, I don't know what problems that would cause. Perhaps you should try using the latest CVS snapshot of mod_perl to see if that works. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
Re: Segmentation fault
Alex Algard wrote: > I've seen a similar issue on our machine. We're running: > <...> > > > Does anyone have problem with Apache 1.3.12 / Mod_perl 1.24 making it's > > childs do segmentation faults whenever the server requested to execute a > > perl module? > > > > If I request a piece of graphics, it works fine, but not if the page is > > generated by mod_perl. I have no compile errors, all the modules works on > > the previous development machine but not this newly installed machine. > > > > The only difference I can see, is that I installed perl 5.6.0 before > > installing the mod_perl apache, should that cause any problems? > > > > The system is running on FreeBSD 4.2. > > Maybe it's this old bug: http://www.geocrawler.com/archives/3/182/2000/6/0/3863601/ PS--Alex: Please add your message _after_ the original message, not _before_, since otherwise long threads get hard to follow. Thanks!
RE: Segmentation fault
I've seen a similar issue on our machine. We're running: - mod_perl 1.24 - apache 1.3.12-25 - RedHat 7.0 - plenty of spare RAM and only when we include certain of our own Perl modules in startup.pl do we see the following in the error_log: [Mon Dec 11 13:11:17 2000] [notice] child pid 2991 exit signal Segmentation fault (11) If we only use these certain modules in our mod_perl scripts (and not in startup.pl), the segmentation faults don't occur. I was unable to spend any time on tracking the bug down, but I'd also be curious to hear more about this issue and any suggestions. Alex Algard > -Original Message- > From: Per Moeller [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, December 12, 2000 2:49 PM > To: [EMAIL PROTECTED] > Subject: Segmentation fault > > > Does anyone have problem with Apache 1.3.12 / Mod_perl 1.24 making it's > childs do segmentation faults whenever the server requested to execute a > perl module? > > If I request a piece of graphics, it works fine, but not if the page is > generated by mod_perl. I have no compile errors, all the modules works on > the previous development machine but not this newly installed machine. > > The only difference I can see, is that I installed perl 5.6.0 before > installing the mod_perl apache, should that cause any problems? > > The system is running on FreeBSD 4.2. > > > // Per Moeller
Re: segmentation fault when using custom config module
On Wed, 29 Nov 2000, Matt Sergeant wrote:
> On Wed, 29 Nov 2000, Dave Rolsky wrote:
>
> > my $cfg = Apache::ModuleConfig->get($r);
>
> Try:
>
> my $cfg = Apache::ModuleConfig->get($r, __PACKAGE__);
I should have said that its segfaulting before it ever gets into the
handler sub. I changed handler to:
sub handler
{
warn "HANDLER\n";
}
and it still segfaulted.
-dave
/*==
www.urth.org
We await the New Sun
==*/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: segmentation fault when using custom config module
On Wed, 29 Nov 2000, Dave Rolsky wrote: > my $cfg = Apache::ModuleConfig->get($r); Try: my $cfg = Apache::ModuleConfig->get($r, __PACKAGE__); -- /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Segmentation fault (11) on any script
Hi, Ted
I had got the fault some time ago.
I compiled PHP4 with the built-in MySQL support, so that my mod_perl scripts about DBI
were
all down with the damn error. It made me sick so long. After I instead build it with
my
local MySQL support files, the mess was gone.
Hope my experience can help you.
- Original Message -
From: "Ted Sindzinski" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, October 19, 2000 4:56 AM
Subject: Segmentation fault (11) on any script
| Last night I removed my standard rpm of apache, and installed the latest
| binary and mod perl binary. For both apache and mod perl, all standard
| modules (everything) were added in. I have also installed dbi, dbd and
| such.
|
| however, when I try to run any script, even a hello world script, my
| browser returns a no data error and the error log shows:
|
| [Wed Oct 18 16:52:50 2000] [notice] Apache/1.3.14 (Unix)
| mod_perl/1.24_01 configured -- resuming normal operations
| [Wed Oct 18 16:52:53 2000] [notice] child pid 25267 exit signal
| Segmentation fault (11)
|
| My httpd.conf setup information is as follows:
|
| **
|
| ServerType standalone
| ServerRoot "/usr/local/apache"
| DocumentRoot "/home"
| PidFile /var/run/httpd.pid
| ScoreBoardFile /var/run/httpd.scoreboard
| Timeout 300
| KeepAlive On
| MaxKeepAliveRequests 100
| KeepAliveTimeout 15
| #ExtendedStatus On
| MinSpareServers 32
| MaxSpareServers 64
| StartServers 32
| MaxClients 256
| MaxRequestsPerChild 10
|
| PerlModule Apache::Registry
| PerlModule Apache::DBI
| PerlRequire conf/startup.pl
| PerlFreshRestart Off
|
| Alias /ads/ /home/adserver/ads/
|
|SetHandler perl-script
|PerlHandler Apache::Registry
|Options ExecCGI
|allow from all
|PerlSendHeader On
|
|
|
| *
|
| Startup.pl is:
|
| #!/usr/bin/perl
|
| BEGIN {
|
|use Apache ();
|use lib Apache->server_root_relative('/usr/lib/perl');
| }
|
| use Apache::Registry ();
| use Apache::Constants();
| #use Apache::DBI;
|
| use CGI qw(-compile :all);
| use CGI::Carp ();
|
| # Load any other reqd modules
|
| 1;
|
| **
|
| Plesae let me know if you can't see something for me to change, thanks.
|
|
| Ted Sindzinski
|
|
|
Re: segmentation fault with CGI::Application
On Wed, 19 Jul 2000, Michael J Schout wrote:
> I have been trying to get CGI::Application to work under mod_perl today. So
> far with no success.
>
> Finally I removed everything except CGI::Application from the config files, and
> the server dumps core on startup.
>
> I have a very stripped odwn httpd.conf that basically loads the bare minimum
> apache modules, then does "PerlModule CGI::Appliation".
>
> Starting httpd dumps core when it tries to start up.
>
> Running it through the debugger produces this:
i think this is one of the bugs fixed by the Perl patch (which will be
in 5.6.1), see:
[EMAIL PROTECTED]">http://forum.swarthmore.edu/epigone/modperl/dilkhumyox/[EMAIL PROTECTED]
the patch below to mod_perl might also fix it.
--- perl_util.c~Tue Jun 13 10:25:38 2000
+++ perl_util.c Tue Jun 13 11:16:45 2000
@@ -547,12 +547,14 @@
{
dTHR;
SV *sv = sv_newmortal();
+COP *old_cop = curcop;
dTHRCTX;
sv_setpvn(sv, "require ", 8);
MP_TRACE_d(fprintf(stderr, "loading perl module '%s'...", name));
sv_catpv(sv, name);
perl_eval_sv(sv, G_DISCARD);
+curcop = old_cop;
if(s) {
if(perl_eval_ok(s) != OK) {
MP_TRACE_d(fprintf(stderr, "not ok\n"));
Re: segmentation fault with CGI::Application [SOLVED]
Ok. Turns out that what the real problem here was that CGI::Application uses CGI::Carp, and I needed a newer version of CGI::Carp. So I seem to have sovled this :) Mike On Wed, 19 Jul 2000, Michael J Schout wrote: > I have been trying to get CGI::Application to work under mod_perl today. So > far with no success. > > Finally I removed everything except CGI::Application from the config files, and > the server dumps core on startup. > > I have a very stripped odwn httpd.conf that basically loads the bare minimum > apache modules, then does "PerlModule CGI::Appliation". > > Starting httpd dumps core when it tries to start up. > > Running it through the debugger produces this: > > This GDB was configured as "i386-redhat-linux"... > Core was generated by `httpd -f >/nis.home/mschout/dev/gkgdrs/gkgnsi/conf/redirect/httpd.conf'. > Program terminated with signal 11, Segmentation fault. > > #0 0x80ad4d2 in Perl_gv_init () > (gdb) bt > #0 0x80ad4d2 in Perl_gv_init () > #1 0x80ae690 in Perl_gv_fetchpv () > #2 0x806a0a5 in perl_section_hash_init () > #3 0x806a375 in perl_section () > #4 0x806a16d in perl_section_self_boot () > #5 0x8068033 in perl_cmd_module () > #6 0x8080519 in invoke_cmd () > #7 0x808089c in ap_handle_command () > #8 0x80808e8 in ap_srm_command_loop () > #9 0x8080c57 in ap_process_resource_config () > #10 0x80812e4 in ap_read_config () > #11 0x8088bc5 in main () > #12 0x400d79cb in __libc_start_main (main=0x80889e0 , argc=3, > argv=0xb904, init=0x8062c24 <_init>, fini=0x8123e1c <_fini>, > rtld_fini=0x4000ae60 <_dl_fini>, stack_end=0xb8fc) > at ../sysdeps/generic/libc-start.c:92 > > Taking out the "PerlModule CGI::Application" line causes the server to start up >normally. > > Taking a quick glance through Application.pm, I dont see anything that should > be causing the interpreter to freak out. I suspect the problem is outside of > CGI::Application somewhere, but CGI::Application is demonstrating some bug here > ;). > > Anyone have any ideas? > > I'm using: > > perl 5.6.0 > mod_perl 1.24 > Linux 2.2.x > > Has anyone else gotten CGI::Application to run in this environment? Anyone > else seen this? > > Mike >
Re: Segmentation Fault [was: The Eagle has Landed!]
ANy word on why the startup print line is executing twice. I'm having the same
problem. But I'm running apache w/o the -X option.
Greg Leidreiter wrote:
> Hello all,
>
> I have recompiled mod_perl/apache with PERL_DEBUG=1
>
> running
>
> gdb httpd
>
> followed by
>
> run httpd -X
>
> produces the following output:
>
> startup.pl is attempting to modify the include path...
>
> startup.pl is attempting to modify the include path...
>
> Program received signal SIGSEGV, segmentation fault
> 0x807ca20 in perl_handler_ismethod()
>
> (It is interesting that the "...modification..." line appears twice. I added
> it (once only!)
> to the beginning of my startup.pl so that I could see if it was being found.
> It somehow seems to be being found more than I expected!)
>
> bt produces:
>
> #0 0x807ca20 in perl_handler_ismethod()
> #1 0x807d2c4 in perl_call_handler()
> #2 0x807ce36 in perl_run_stacked_handler()
> #3 0x807bb7d in perl_handler()
> #4 0x8096af3 in ap_invoke_handler()
> #5 0x80aa0f9 in ap_some_auth_required()
> #6 0x80aa15c in ap_process_request()
> #7 0x80a1a0e in ap_child_terminate()
> #8 0x80a1b9c in ap_child_terminate()
> #9 0x80a1cf9 in ap_child_terminate()
> #10 0x80a2326 in ap_child_terminate()
> #11 0x80a2ab3 in main()
> #12 0x400d31eb in --libc_start_main (main=0x80a276c , argc=3,
> argv=0xbce4, init=0x8061f9c <_init>, fini=0x8136d7c <_fini>,
> rtld_fini=0x4000a610 <_dl_fini>, stack_end=0xbcdc) at
> ../sysdeps/generic/libc-start.c:90
>
> If this makes sense to anybody please drop me a line, I've read all the way
> through chapters
> 1-6 and I'm itching to try out some code... just can't get the setup
> straight :0
>
> Thanks,
> Greg
>
> PS. Here is the config again, just to be sure:
>
> Perl 5.6.0
> Apache 1.3.12
> mod_perl-1.24
>
> ServerRoot is /usr/local/apache
> underneath which I have created the lib/perl/Apache tree for holding
> mod_perl modules,
> and dutifully entered the required code in a file called Hello.pm in this
> directory.
>
> DocumentRoot is /usr/local/apache/htdocs
>
> in httpd.conf I have added the following:
> --
>
> Include conf/perl.conf
>
> --
>
> conf/perl.conf looks like this:
> --
> PerlRequire conf/startup.pl
> PerlFreshRestart On
>
>
> SetHandler perl-script
> PerlHandler Apache::Hello
>
>
> ---
>
> and startup.pl looks like this:
> ---
> #!/usr/local/bin/perl
>
> print "\n\tstartup.pl is attempting to modify the include path...\n\n";
>
> BEGIN {
> use Apache();
> use lib Apache->server_root_relative('lib/perl');
> }
>
> use Apache::Registry
> use Apache::Constants
> use CGI qw(-compile :all);
> use CGI::Carp;
>
> 1;
> --
--
Jeff Saenz
[EMAIL PROTECTED]
Re: Segmentation Fault [was: The Eagle has Landed!]
Hi there, On Sat, 15 Jul 2000, Greg Leidreiter wrote: > I have recompiled mod_perl/apache with PERL_DEBUG=1 > startup.pl is attempting to modify the include path... > startup.pl is attempting to modify the include path... > Program received signal SIGSEGV, segmentation fault > 0x807ca20 in perl_handler_ismethod() > (It is interesting that the "...modification..." line appears > twice. I added it (once only!) to the beginning of my startup.pl so > that I could see if it was being found. It somehow seems to be > being found more than I expected!) Have a look for $Apache::Server::Starting an PERL_STARTUP_DONE_CHECK in the Guide. They in the configuration and troubleshooting sections in my (oldish - February) copy. The Guide's kindofa moving target. Eric will probably help you with the sigsev. They seem to be getting more common thesedays... 73, Ged.
Re: Segmentation Fault
On Wed, 7 Jun 2000, Pierre Laplante wrote:
>
> I am using RH 6.2, mod-perl 1.24, apache 1.3.12 with the following
> program with Apache/registry:
>
> #!/usr/bin/perl -w
> use strict;
>
> my $p = new xyz;
> for(my $i=0; $i < 10; ++$i) {
> for(my $j=1;$j<100;++$j) {
> my $file = "../xml/$j.xml";
> my $t = $p -> loadxml($file);
> }
> }
> print "Content-type: text/html\n\nallo\n";
>
> package xyz;
> use XML::Parser;
> sub new { bless {}; }
>
> sub loadxml {
> my($self, $file)=@_;
> my $p = new XML::Parser(Style => 'Tree');
> my $t = $p -> parsefile($file);
> return $t;
> }
>
> After a few run, I got a segmentation fault with apache.
>
> Any idea?
works fine for me. see the SUPPORT doc for hints on getting a stacktrace.
Re: Segmentation fault (11) with mod_perl 1.23...
Doug MacEachern wrote: > On Thu, 25 May 2000, Mark Haviland wrote: > > No...I was hoping to be able to use it as a DSO, but maybe I can't win > > on this one > > it would be worth testing a static build to confirm that the problem is > dso related. if it is, where to go from there i'm not sure, the dso > troubles are supposed to have been ironed out. can you send me your > perl -V? Finally - some free time to compile :). I just got done compiling a static version mod_perl inside the httpd. After modifying the config file to match my 'dynamic' httpd (ie. adding the PerlRequire with a different config.pl file that has a 'use Sybase::CTlib;' in it.), I fired it up and...no core dump or segmentation fault. And, I'm now able to successfully query my db. So, it looks like something is wrong with DSO and perl...the dynaloader ??? Any ideas ?? Here's my perl -V: [root@hsimrhpc1 logs]# perl -V Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration: Platform: osname=linux, osvers=2.2.5-22smp, archname=i386-linux uname='linux porky.devel.redhat.com 2.2.5-22smp #1 smp wed jun 2 09:11:51 edt 1999 i686 unknown ' hint=recommended, useposix=true, d_sigaction=define usethreads=undef useperlio=undef d_sfio=undef Compiler: cc='cc', optimize='-O2 -m486 -fno-strength-reduce', gccversion=egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) cppflags='-Dbool=char -DHAS_BOOL -I/usr/local/include' ccflags ='-Dbool=char -DHAS_BOOL -I/usr/local/include' stdchar='char', d_stdstdio=undef, usevfork=false intsize=4, longsize=4, ptrsize=4, doublesize=8 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 alignbytes=4, usemymalloc=n, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -ldl -lm -lc -lposix -lcrypt libc=, so=so, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Built under linux Compiled at Feb 2 2000 15:35:58 @INC: /usr/lib/perl5/5.00503/i386-linux /usr/lib/perl5/5.00503 /usr/lib/perl5/site_perl/5.005/i386-linux /usr/lib/perl5/site_perl/5.005 .
Re: Segmentation fault (11) with mod_perl 1.23...
On Tue, 23 May 2000, Mark Haviland wrote: > Doug, > > Sorry for the consistent eMails, but I guess I wasn't entirely correct in my > statment about my version of perl being the problem. After some more tests, I've > found that things go wrong (ie. I get a Segfault) when I attempt to pre load the > Sybase::CTlib module (or any module that uses it) in the PerlRequire file. But, > when I have the 'use Sybase::CTlib' inside of my handler, then everything is ok. the next step would be to get a stacktrace (mod_perl built with PERL_DEBUG=1 prefered), see the SUPPORT doc for hints.
Re: Segmentation fault (11) with mod_perl 1.23...
Doug, Sorry for the consistent eMails, but I guess I wasn't entirely correct in my statment about my version of perl being the problem. After some more tests, I've found that things go wrong (ie. I get a Segfault) when I attempt to pre load the Sybase::CTlib module (or any module that uses it) in the PerlRequire file. But, when I have the 'use Sybase::CTlib' inside of my handler, then everything is ok. Any ideas ? -Mark Mark Haviland wrote: > Doug, > > I think I just figured out my problem. I upgraded my system, but was using a > version of perl that I had compiled before my upgrade (duh!). I set up an > httpd server that came with redhat 6.2 (and mod_perl 1.23) and things seems to > work fine. It looks like i need to recompile perl :). > > -Mark > > Mark Haviland wrote: > > > Hi Doug, > > > > Sorry for the delayed response - I just got back into town yesterday so was > > 'out of action' for awhile. > > > > Doug MacEachern wrote: > > > > > On Fri, 12 May 2000, Mark Haviland wrote: > > > > > > > Hey all... > > > > > > > > I just upgraded my box to redhat 6.2.2 and compiled Apache 1.3.12 with > > > > mod_perl (1.23) as a DSO (outside the Apache tree using apxs). Now, > > > > modules that use to work are suddenly causing seg faults. The one in > > > > particular that doens't seem to jive with mod_perl is Sybase::CTlib. > > > > Has anybody else seen this problem ? > > > > > > what versions of things did you upgrade from? where you using dso with > > > the older versions? > > > > I upgraded from mod_perl 1.21. Yes I was using dso with the prior > > version. Here's some info about the version of perl that I compiled > > against: > > > > Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration: > > Platform: > > osname=linux, osvers=2.2.5-15, archname=i686-linux > > uname='linux hsimrhpc1.harmonic.com 2.2.5-15 #1 mon apr 19 23:00:46 edt > > 1999 i686 unknown ' > > hint=previous, useposix=true, d_sigaction=define > > usethreads=undef useperlio=undef d_sfio=undef > > Compiler: > > cc='cc', optimize='-O2', gccversion=egcs-2.91.66 19990314/Linux > > (egcs-1.1.2 release) > > cppflags='-Dbool=char -DHAS_BOOL' > > ccflags ='-Dbool=char -DHAS_BOOL' > > stdchar='char', d_stdstdio=undef, usevfork=false > > intsize=4, longsize=4, ptrsize=4, doublesize=8 > > d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 > > alignbytes=4, usemymalloc=n, prototype=define > > Linker and Libraries: > > ld='cc', ldflags =' -L/usr/local/lib' > > libpth=/usr/local/lib /lib /usr/lib > > libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lc -lposix -lcrypt > > libc=, so=so, useshrplib=false, libperl=libperl.a > > Dynamic Linking: > > dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' > > cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' > > > > Characteristics of this binary (from libperl): > > Built under linux > > Compiled at Oct 13 1999 10:39:19 > > %ENV: > > PERL5LIB="/usr/hsi/perl5/lib" > > @INC: > > /usr/hsi/perl5/lib > > /usr/hsi/perl5/lib/5.00503/i686-linux > > /usr/hsi/perl5/lib/5.00503 > > /usr/hsi/perl5/lib/site_perl/5.005/i686-linux > > /usr/hsi/perl5/lib/site_perl/5.005 > > . > > > > > > > > > > > > unload_xs_so: 0x8396fc0 > > > > > > hmm, i wonder if the dso "fix" broke things for you, what happens if you > > > comment out this line of mod_perl.c: > > > unload_xs_so(librefs); > > > > I uncommented the line and now the server (httpd) just cores when I attempt > > to start... > > > > /usr/hsi/apache-1.3.12/bin/hsi-httpd -X -f > > /usr/hsi/apache-1.3.12/conf/hsi-httpd.conf.2080 > > perl_parse args: '/dev/null' ...allocating perl interpreter...ok > > constructing perl interpreter...ok > > ok > > running perl interpreter...ok > > mod_perl: 0 END blocks encountered during server startup > > loading perl module 'Apache'...loading perl module > > 'Apache::Constants::Exports'...ok > > ok > > loading perl module 'Tie::IxHash'...ok > > perl_section: > > perl_section: > > perl_section: > > perl_section: > > perl_section: > > perl_section: > > perl_section: > > PerlRequire: arg=`conf/startup_cfg.pl' > > attempting to require `conf/startup_cfg.pl' > > Segmentation fault (core dumped) > > > > It seems that is cores when it reaches the line for "use Sybase::CTlib;" > > in my 'conf/statup_cfg.pl' file. > > > > Now, when I look at the CTlib.pm I notice the following: > > > > package Sybase::CTlib; > > > > require Exporter; > > use AutoLoader; > > require DynaLoader; > > > > use Carp; > > . > > . > > . > > > > Perhaps something to do with the Exporter or DynaLoader ?? > > > > -Mark
Re: Segmentation fault (11) with mod_perl 1.23...
Doug, I think I just figured out my problem. I upgraded my system, but was using a version of perl that I had compiled before my upgrade (duh!). I set up an httpd server that came with redhat 6.2 (and mod_perl 1.23) and things seems to work fine. It looks like i need to recompile perl :). -Mark Mark Haviland wrote: > Hi Doug, > > Sorry for the delayed response - I just got back into town yesterday so was > 'out of action' for awhile. > > Doug MacEachern wrote: > > > On Fri, 12 May 2000, Mark Haviland wrote: > > > > > Hey all... > > > > > > I just upgraded my box to redhat 6.2.2 and compiled Apache 1.3.12 with > > > mod_perl (1.23) as a DSO (outside the Apache tree using apxs). Now, > > > modules that use to work are suddenly causing seg faults. The one in > > > particular that doens't seem to jive with mod_perl is Sybase::CTlib. > > > Has anybody else seen this problem ? > > > > what versions of things did you upgrade from? where you using dso with > > the older versions? > > I upgraded from mod_perl 1.21. Yes I was using dso with the prior > version. Here's some info about the version of perl that I compiled > against: > > Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration: > Platform: > osname=linux, osvers=2.2.5-15, archname=i686-linux > uname='linux hsimrhpc1.harmonic.com 2.2.5-15 #1 mon apr 19 23:00:46 edt > 1999 i686 unknown ' > hint=previous, useposix=true, d_sigaction=define > usethreads=undef useperlio=undef d_sfio=undef > Compiler: > cc='cc', optimize='-O2', gccversion=egcs-2.91.66 19990314/Linux > (egcs-1.1.2 release) > cppflags='-Dbool=char -DHAS_BOOL' > ccflags ='-Dbool=char -DHAS_BOOL' > stdchar='char', d_stdstdio=undef, usevfork=false > intsize=4, longsize=4, ptrsize=4, doublesize=8 > d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 > alignbytes=4, usemymalloc=n, prototype=define > Linker and Libraries: > ld='cc', ldflags =' -L/usr/local/lib' > libpth=/usr/local/lib /lib /usr/lib > libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lc -lposix -lcrypt > libc=, so=so, useshrplib=false, libperl=libperl.a > Dynamic Linking: > dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' > cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' > > Characteristics of this binary (from libperl): > Built under linux > Compiled at Oct 13 1999 10:39:19 > %ENV: > PERL5LIB="/usr/hsi/perl5/lib" > @INC: > /usr/hsi/perl5/lib > /usr/hsi/perl5/lib/5.00503/i686-linux > /usr/hsi/perl5/lib/5.00503 > /usr/hsi/perl5/lib/site_perl/5.005/i686-linux > /usr/hsi/perl5/lib/site_perl/5.005 > . > > > > > > > > unload_xs_so: 0x8396fc0 > > > > hmm, i wonder if the dso "fix" broke things for you, what happens if you > > comment out this line of mod_perl.c: > > unload_xs_so(librefs); > > I uncommented the line and now the server (httpd) just cores when I attempt > to start... > > /usr/hsi/apache-1.3.12/bin/hsi-httpd -X -f > /usr/hsi/apache-1.3.12/conf/hsi-httpd.conf.2080 > perl_parse args: '/dev/null' ...allocating perl interpreter...ok > constructing perl interpreter...ok > ok > running perl interpreter...ok > mod_perl: 0 END blocks encountered during server startup > loading perl module 'Apache'...loading perl module > 'Apache::Constants::Exports'...ok > ok > loading perl module 'Tie::IxHash'...ok > perl_section: > perl_section: > perl_section: > perl_section: > perl_section: > perl_section: > perl_section: > PerlRequire: arg=`conf/startup_cfg.pl' > attempting to require `conf/startup_cfg.pl' > Segmentation fault (core dumped) > > It seems that is cores when it reaches the line for "use Sybase::CTlib;" > in my 'conf/statup_cfg.pl' file. > > Now, when I look at the CTlib.pm I notice the following: > > package Sybase::CTlib; > > require Exporter; > use AutoLoader; > require DynaLoader; > > use Carp; > . > . > . > > Perhaps something to do with the Exporter or DynaLoader ?? > > -Mark
Re: Segmentation fault (11) with mod_perl 1.23...
Hi Doug, Sorry for the delayed response - I just got back into town yesterday so was 'out of action' for awhile. Doug MacEachern wrote: > On Fri, 12 May 2000, Mark Haviland wrote: > > > Hey all... > > > > I just upgraded my box to redhat 6.2.2 and compiled Apache 1.3.12 with > > mod_perl (1.23) as a DSO (outside the Apache tree using apxs). Now, > > modules that use to work are suddenly causing seg faults. The one in > > particular that doens't seem to jive with mod_perl is Sybase::CTlib. > > Has anybody else seen this problem ? > > what versions of things did you upgrade from? where you using dso with > the older versions? I upgraded from mod_perl 1.21. Yes I was using dso with the prior version. Here's some info about the version of perl that I compiled against: Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration: Platform: osname=linux, osvers=2.2.5-15, archname=i686-linux uname='linux hsimrhpc1.harmonic.com 2.2.5-15 #1 mon apr 19 23:00:46 edt 1999 i686 unknown ' hint=previous, useposix=true, d_sigaction=define usethreads=undef useperlio=undef d_sfio=undef Compiler: cc='cc', optimize='-O2', gccversion=egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) cppflags='-Dbool=char -DHAS_BOOL' ccflags ='-Dbool=char -DHAS_BOOL' stdchar='char', d_stdstdio=undef, usevfork=false intsize=4, longsize=4, ptrsize=4, doublesize=8 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 alignbytes=4, usemymalloc=n, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lc -lposix -lcrypt libc=, so=so, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Built under linux Compiled at Oct 13 1999 10:39:19 %ENV: PERL5LIB="/usr/hsi/perl5/lib" @INC: /usr/hsi/perl5/lib /usr/hsi/perl5/lib/5.00503/i686-linux /usr/hsi/perl5/lib/5.00503 /usr/hsi/perl5/lib/site_perl/5.005/i686-linux /usr/hsi/perl5/lib/site_perl/5.005 . > > > > unload_xs_so: 0x8396fc0 > > hmm, i wonder if the dso "fix" broke things for you, what happens if you > comment out this line of mod_perl.c: > unload_xs_so(librefs); I uncommented the line and now the server (httpd) just cores when I attempt to start... /usr/hsi/apache-1.3.12/bin/hsi-httpd -X -f /usr/hsi/apache-1.3.12/conf/hsi-httpd.conf.2080 perl_parse args: '/dev/null' ...allocating perl interpreter...ok constructing perl interpreter...ok ok running perl interpreter...ok mod_perl: 0 END blocks encountered during server startup loading perl module 'Apache'...loading perl module 'Apache::Constants::Exports'...ok ok loading perl module 'Tie::IxHash'...ok perl_section: perl_section: perl_section: perl_section: perl_section: perl_section: perl_section: PerlRequire: arg=`conf/startup_cfg.pl' attempting to require `conf/startup_cfg.pl' Segmentation fault (core dumped) It seems that is cores when it reaches the line for "use Sybase::CTlib;" in my 'conf/statup_cfg.pl' file. Now, when I look at the CTlib.pm I notice the following: package Sybase::CTlib; require Exporter; use AutoLoader; require DynaLoader; use Carp; . . . Perhaps something to do with the Exporter or DynaLoader ?? -Mark
Re: Segmentation fault (11) with mod_perl 1.23...
On Fri, 12 May 2000, Mark Haviland wrote: > Hey all... > > I just upgraded my box to redhat 6.2.2 and compiled Apache 1.3.12 with > mod_perl (1.23) as a DSO (outside the Apache tree using apxs). Now, > modules that use to work are suddenly causing seg faults. The one in > particular that doens't seem to jive with mod_perl is Sybase::CTlib. > Has anybody else seen this problem ? what versions of things did you upgrade from? where you using dso with the older versions? > unload_xs_so: 0x8396fc0 hmm, i wonder if the dso "fix" broke things for you, what happens if you comment out this line of mod_perl.c: unload_xs_so(librefs);
RE: Segmentation Fault: RedHat 6.[01] / Apache 1.3.12 / mod_perl 1.22 / perl 5.005_03 / IE 5
> "DM" == Doug MacEachern <[EMAIL PROTECTED]> writes: DM> On Mon, 3 Apr 2000, Vivek Khera wrote: >> What if someone sets PerlFreshRestart No and has DSO enabled? Then >> they don't get what they think they do. DM> right, the docs should be updated to reflect that. Why not disable this command similarly to how the SSI command is disabled when we go DSO?
RE: Segmentation Fault: RedHat 6.[01] / Apache 1.3.12 / mod_perl 1.22 / perl 5.005_03 / IE 5
On Mon, 3 Apr 2000, Vivek Khera wrote: > What if someone sets PerlFreshRestart No and has DSO enabled? Then > they don't get what they think they do. right, the docs should be updated to reflect that.
RE: Segmentation Fault: RedHat 6.[01] / Apache 1.3.12 / mod_perl 1.22 / perl 5.005_03 / IE 5
> "DM" == Doug MacEachern <[EMAIL PROTECTED]> writes: >> If so, then it should be an error or warning to specify it when using DSO. DM> well, it's still a FreshRestart, just fresher than static-modperl :) What if someone sets PerlFreshRestart No and has DSO enabled? Then they don't get what they think they do. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-301-545-6996 PGP & MIME spoken herehttp://www.kciLink.com/home/khera/
Re: Segmentation Fault: RedHat 6.[01] / Apache 1.3.12 / mod_perl1.22 / perl 5.005_03 / IE 5
On Thu, 30 Mar 2000, Robert Jenks wrote: > I'm having a very strange problem. I'm running a very large application > under apache/mod_perl (100+ modules; httpd children grow to 40+MB). The > application uses Apache::DBI (DBD::Oracle) & CGI.pm, so I have it running as > a handler and everything works fine except... :) > > If the first request to httpd comes from IE5 to the web root, the child > httpd process will segfault. However from any other client I've tried ( > Netscape Comm. and "telnet 0 80 GET /" it works fine and doesn't segfault. > Even stranger, if I point IE5 at "/perl-status?inc", and then at "/" it > doesn't segfault (from that point forward it doesn't segfault; even if it > hits a new child httpd). see the SUPPORT doc for hints on getting a stacktrace, that should help find the culprit.
RE: Segmentation Fault: RedHat 6.[01] / Apache 1.3.12 / mod_perl 1.22 / perl 5.005_03 / IE 5
On Fri, 31 Mar 2000, Vivek Khera wrote: > > "DM" == Doug MacEachern <[EMAIL PROTECTED]> writes: > > DM> mod_perl dso will do a full tear-down (perl_destruct()), regardless of > DM> PerlFreshRestart (which still behaves the same old way) > > Implying that PerlFreshRestart is ignored when mod_perl is DSO. > Correct? right. > If so, then it should be an error or warning to specify it when using DSO. well, it's still a FreshRestart, just fresher than static-modperl :)
RE: Segmentation Fault: RedHat 6.[01] / Apache 1.3.12 / mod_perl 1.22 / perl 5.005_03 / IE 5
> "DM" == Doug MacEachern <[EMAIL PROTECTED]> writes: DM> mod_perl dso will do a full tear-down (perl_destruct()), regardless of DM> PerlFreshRestart (which still behaves the same old way) Implying that PerlFreshRestart is ignored when mod_perl is DSO. Correct? If so, then it should be an error or warning to specify it when using DSO.
RE: Segmentation Fault: RedHat 6.[01] / Apache 1.3.12 / mod_perl 1.22 / perl 5.005_03 / IE 5
On Fri, 31 Mar 2000, Vivek Khera wrote: > > "GY" == Geoffrey Young <[EMAIL PROTECTED]> writes: > > GY> PerlFreshRestart causes a great many problems, most for indeterminate > GY> reasons, but its behavior is at least documented > > I'm curious, now with the new code in 1.22 that dl_unloads all of the > perl XS modules and with the perl shared object also being unloaded, > doesn't PerlFreshStart cause a whole new perl interpreter to be > instantiated? I haven't investigated this but it seems to make > sense. Has anyone looked into this? mod_perl dso will do a full tear-down (perl_destruct()), regardless of PerlFreshRestart (which still behaves the same old way)
RE: Segmentation Fault: RedHat 6.[01] / Apache 1.3.12 / mod_perl 1.22 / perl 5.005_03 / IE 5
> "GY" == Geoffrey Young <[EMAIL PROTECTED]> writes: GY> there's an old thread that discusses the code/behavior of PerlFreshRestart GY> (at least in 1.21): GY> http://forum.swarthmore.edu/epigone/modperl/peepranbling Right; that's an old thread. The behavior of the DSO modules has changed since 1.21. My question is regarding the new behavior of how DSO modules get totally unloaded and reloaded now. Or do they? -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-301-545-6996 PGP & MIME spoken herehttp://www.kciLink.com/home/khera/
RE: Segmentation Fault: RedHat 6.[01] / Apache 1.3.12 / mod_perl 1.22 / perl 5.005_03 / IE 5
there's an old thread that discusses the code/behavior of PerlFreshRestart (at least in 1.21): http://forum.swarthmore.edu/epigone/modperl/peepranbling in particular that post from Doug near the bottom might help answer whether a new interpreter is instantiated (I think he is saying no here, but I'm not sure :) I dunno about 1.22 either... HTH --Geoff > -Original Message- > From: Vivek Khera [mailto:[EMAIL PROTECTED]] > Sent: Friday, March 31, 2000 10:37 AM > To: Mod Perl List > Subject: RE: Segmentation Fault: RedHat 6.[01] / Apache 1.3.12 / > mod_perl 1.22 / perl 5.005_03 / IE 5 > > > >>>>> "GY" == Geoffrey Young <[EMAIL PROTECTED]> writes: > > GY> PerlFreshRestart causes a great many problems, most for > indeterminate > GY> reasons, but its behavior is at least documented > > I'm curious, now with the new code in 1.22 that dl_unloads all of the > perl XS modules and with the perl shared object also being unloaded, > doesn't PerlFreshStart cause a whole new perl interpreter to be > instantiated? I haven't investigated this but it seems to make > sense. Has anyone looked into this? > > -- > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Vivek Khera, Ph.D.Khera Communications, Inc. > Internet: [EMAIL PROTECTED] Rockville, MD +1-301-545-6996 > PGP & MIME spoken herehttp://www.kciLink.com/home/khera/ >
RE: Segmentation Fault: RedHat 6.[01] / Apache 1.3.12 / mod_perl 1.22 / perl 5.005_03 / IE 5
> "GY" == Geoffrey Young <[EMAIL PROTECTED]> writes: GY> PerlFreshRestart causes a great many problems, most for indeterminate GY> reasons, but its behavior is at least documented I'm curious, now with the new code in 1.22 that dl_unloads all of the perl XS modules and with the perl shared object also being unloaded, doesn't PerlFreshStart cause a whole new perl interpreter to be instantiated? I haven't investigated this but it seems to make sense. Has anyone looked into this? -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-301-545-6996 PGP & MIME spoken herehttp://www.kciLink.com/home/khera/
RE: Segmentation Fault: RedHat 6.[01] / Apache 1.3.12 / mod_perl 1.22 / perl 5.005_03 / IE 5
Title: Segmentation Fault: RedHat 6.[01] / Apache 1.3.12 / mod_perl 1.22 / perl 5.005_03 / IE 5
PerlFreshRestart causes a great many problems, most for
indeterminate reasons, but its behavior is at least
documented
see http://perl.apache.org/guide/troubleshooting.html#Evil_things_might_happen_when_us
--Geoff
-Original Message-From: Robert Jenks
[mailto:[EMAIL PROTECTED]]Sent: Thursday, March 30, 2000 2:13
PMTo: 'Geoffrey Young'Subject: RE: Segmentation Fault:
RedHat 6.[01] / Apache 1.3.12 / mod_perl 1.22 / perl 5.005_03 / IE
5
I
removed PerlFreshRestart and it seems to be working fine now.
Fortunately I don't need this option, so this won't be a problem, however it
is curious that it was causing segfaults.
Thanks for the help...
-Robert
-Original Message-From: Geoffrey Young
[mailto:[EMAIL PROTECTED]]Sent: Thursday, March 30, 2000 11:46
AMTo: 'Robert Jenks'; modperl (E-mail)Subject: RE:
Segmentation Fault: RedHat 6.[01] / Apache 1.3.12 / mod_perl 1.22 / perl
5.005_03 / IE 5
I'm not really the expert in this, but you might
want to try removing PerlFreshRestart and Apache::StatINC from your config
and see if that helps...
HTH
--Geoff
-Original Message-From: Robert Jenks
[mailto:[EMAIL PROTECTED]]Sent: Thursday, March 30, 2000
11:03 AMTo: modperl (E-mail)Subject: Segmentation
Fault: RedHat 6.[01] / Apache 1.3.12 / mod_perl 1.22 / perl 5.005_03 / IE
5
I'm having a very strange problem. I'm
running a very large application under apache/mod_perl (100+ modules;
httpd children grow to 40+MB). The application uses Apache::DBI
(DBD::Oracle) & CGI.pm, so I have it running as a handler and
everything works fine except... :)
If the first request to httpd comes from IE5 to
the web root, the child httpd process will segfault. However from
any other client I've tried ( Netscape Comm. and "telnet 0 80 GET /" it
works fine and doesn't segfault. Even stranger, if I point IE5 at
"/perl-status?inc", and then at "/" it doesn't segfault (from that point
forward it doesn't segfault; even if it hits a new child
httpd).
I haven't been able to isolate the problem
because I haven't been able to get apache to give me a core file.
I've tried the "ulimit -c unlimited" without success. Any hints,
RwhatFM, etc
My build script is attached. (which includes
building mod_ssl, but this even happened before I added mod_ssl)
Thanks in advance... -- Robert
Jenks
-httpd.conf
ServerType standalone ServerRoot "/Suite/apache" PidFile /Suite/apache/logs/httpd.pid ScoreBoardFile /Suite/apache/logs/httpd.scoreboard ResourceConfig /dev/null AccessConfig /dev/null Timeout
300 KeepAlive On MaxKeepAliveRequests 100 KeepAliveTimeout 15 MinSpareServers 1 MaxSpareServers 3 StartServers
3 MaxClients 3 MaxRequestsPerChild 0 ExtendedStatus on Port 80
User nobody Group nobody ServerAdmin
[EMAIL PROTECTED] ServerName
server.mydomain.com DocumentRoot
/Suite/AppSites/practice Options
FollowSymLinks
AllowOverride None Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
Allow from all
AccessFileName .htaccess Order allow,deny Deny from all
UseCanonicalName On
TypesConfig
/Suite/apache/conf/mime.types
DefaultType text/plain
MIMEMagicFile
/Suite/apache/conf/magic
HostnameLookups Off
ErrorLog /Suite/apache/logs/error_log
LogLevel warn
LogFormat "%h %l %u %t \"%r\" %>s %b
\"%{Referer}i\" \"%{User-Agent}i\"" combined LogFormat "%h %l %u %t \"%r\" %>s %b" common LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent
CustomLog /Suite/apache/logs/access_log
common CustomLog
/Suite/apache/logs/referer_log referer CustomLog /Suite/apache/logs/agent_log agent
ServerSignature Off
BrowserMatch "Mozilla/2"
nokeepalive
BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0
force-response-1.0
BrowserMatch "RealPlayer 4\.0" force-response-1.0 BrowserMatch "Java/1\.0"
force-response-1.0
BrowserMatch "JDK/1\.0" force-response-1.0
PerlInitHandler Apache::StatINC
PerlSetEnv ORACLE_HOME
/u01/app/oracle/product/8.1.5 PerlRequire conf/startup.pl PerlFreshResta
RE: Segmentation Fault: RedHat 6.[01] / Apache 1.3.12 / mod_perl 1.22 / perl 5.005_03 / IE 5
Title: Segmentation Fault: RedHat 6.[01] / Apache 1.3.12 / mod_perl 1.22 / perl 5.005_03 / IE 5
I'm not really the expert in this, but you might want
to try removing PerlFreshRestart and Apache::StatINC from your config and see if
that helps...
HTH
--Geoff
-Original Message-From: Robert Jenks
[mailto:[EMAIL PROTECTED]]Sent: Thursday, March 30, 2000
11:03 AMTo: modperl (E-mail)Subject: Segmentation Fault:
RedHat 6.[01] / Apache 1.3.12 / mod_perl 1.22 / perl 5.005_03 / IE
5
I'm having a very strange problem. I'm
running a very large application under apache/mod_perl (100+ modules; httpd
children grow to 40+MB). The application uses Apache::DBI (DBD::Oracle)
& CGI.pm, so I have it running as a handler and everything works fine
except... :)
If the first request to httpd comes from IE5 to the
web root, the child httpd process will segfault. However from any other
client I've tried ( Netscape Comm. and "telnet 0 80 GET /" it works fine and
doesn't segfault. Even stranger, if I point IE5 at "/perl-status?inc",
and then at "/" it doesn't segfault (from that point forward it doesn't
segfault; even if it hits a new child httpd).
I haven't been able to isolate the problem because
I haven't been able to get apache to give me a core file. I've tried the
"ulimit -c unlimited" without success. Any hints, RwhatFM,
etc
My build script is attached. (which includes
building mod_ssl, but this even happened before I added mod_ssl)
Thanks in advance... -- Robert Jenks
-httpd.conf ServerType standalone ServerRoot "/Suite/apache" PidFile
/Suite/apache/logs/httpd.pid ScoreBoardFile
/Suite/apache/logs/httpd.scoreboard ResourceConfig /dev/null AccessConfig /dev/null Timeout
300 KeepAlive On MaxKeepAliveRequests 100 KeepAliveTimeout 15 MinSpareServers
1 MaxSpareServers 3 StartServers 3 MaxClients
3 MaxRequestsPerChild 0 ExtendedStatus on Port
80 User nobody Group nobody ServerAdmin
[EMAIL PROTECTED] ServerName
server.mydomain.com DocumentRoot
/Suite/AppSites/practice Options
FollowSymLinks
AllowOverride None Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
Allow from all
AccessFileName .htaccess Order allow,deny Deny from all
UseCanonicalName On
TypesConfig
/Suite/apache/conf/mime.types
DefaultType text/plain
MIMEMagicFile
/Suite/apache/conf/magic
HostnameLookups Off
ErrorLog /Suite/apache/logs/error_log
LogLevel warn
LogFormat "%h %l %u %t \"%r\" %>s %b
\"%{Referer}i\" \"%{User-Agent}i\"" combined LogFormat "%h %l %u %t \"%r\" %>s %b" common LogFormat "%{Referer}i -> %U" referer LogFormat "%{User-agent}i" agent
CustomLog /Suite/apache/logs/access_log
common CustomLog
/Suite/apache/logs/referer_log referer CustomLog /Suite/apache/logs/agent_log agent
ServerSignature Off
BrowserMatch "Mozilla/2"
nokeepalive BrowserMatch
"MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0 BrowserMatch "RealPlayer 4\.0"
force-response-1.0
BrowserMatch "Java/1\.0" force-response-1.0 BrowserMatch "JDK/1\.0" force-response-1.0
PerlInitHandler Apache::StatINC PerlSetEnv ORACLE_HOME /u01/app/oracle/product/8.1.5
PerlRequire conf/startup.pl PerlFreshRestart On
SetHandler perl-script
PerlHandler Apache::Suite::Practice
Options
+ExecCGI
SetHandler default-handler SetHandler default-handler SetHandler default-handler SetHandler server-status SetHandler perl-script
PerlHandler Apache::Status -httpd.conf
<>
