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.
segmentation fault under mod_perl+XML::XPath
Hello.
I've tried to use XML::XPath under mod_perl 1.27 and Apache 1.3.27, but
got segmentation fault with this peace of code:
use XML::XPath;
my $mfname='/proj/optolink/html/.meta.xml';
my $xp = XML::XPath-new(filename = $mfname);
my $ns = $xp-find('//[EMAIL PROTECTED]yes]');
Perl 5.8.0, Apache - with so, unique_id, no expat
mod_perl with everything as DSO
Under command line it's working fine and all tests during installation of
XML::XPath were fine, but the same code crush apache+mod_perl.
Backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x80711c5 in poolCopyString ()
(gdb) bt
#0 0x80711c5 in poolCopyString ()
#1 0x806cf71 in XML_SetBase ()
#2 0x28cfcc92 in XS_XML__Parser__Expat_SetBase ()
from
/usr/local/lib/perl5/site_perl/5.8.0/i386-freebsd/auto/XML/Parser/Expat/Expat.so
#3 0x28c398fb in Perl_pp_entersub () from
/usr/local/libexec/apache/libperl.so
#4 0x28c33c28 in Perl_runops_standard ()
from /usr/local/libexec/apache/libperl.so
#5 0x28bf2f36 in S_call_body () from /usr/local/libexec/apache/libperl.so
#6 0x28bf2d16 in Perl_call_sv () from
/usr/local/libexec/apache/libperl.so
#7 0x28bd3d56 in perl_call_handler ()
from /usr/local/libexec/apache/libperl.so
#8 0x28bd359e in perl_run_stacked_handlers ()
from /usr/local/libexec/apache/libperl.so
#9 0x28bd1d64 in perl_handler () from
/usr/local/libexec/apache/libperl.so
#10 0x8052595 in ap_invoke_handler ()
#11 0x806225c in process_request_internal ()
#12 0x80622bd in ap_process_request ()
#13 0x805b52e in child_main ()
#14 0x805b6a0 in make_child ()
#15 0x805b7bd in startup_children ()
#16 0x805bcb4 in standalone_main ()
#17 0x805c397 in main ()
#18 0x804ebe1 in _start ()
Any help would be good.
Ruslan.
segmentation fault under mod_perl+XML::XPath
Hello.
I've tried to use XML::XPath under mod_perl 1.27 and Apache 1.3.27, but
got segmentation fault with this peace of code:
use XML::XPath;
my $mfname='/proj/optolink/html/.meta.xml';
my $xp = XML::XPath-new(filename = $mfname);
my $ns = $xp-find('//[EMAIL PROTECTED]yes]');
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.
Apache - with so, unique_id, no expat
mod_perl with everything as DSO
Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
Platform:
osname=freebsd, osvers=4.5-stable, archname=i386-freebsd
uname='freebsd flamengo.citl.miee.ru 4.5-stable freebsd 4.5-stable #3: tue apr 23
15:48:51 msd 2002 [EMAIL PROTECTED]:usrsrcsyscompileflamengo i386 '
config_args='-de'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing
-I/usr/local/include',
optimize='-O',
cppflags='-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing
-I/usr/local/include'
ccversion='', gccversion='2.95.3 20010315 (release) [FreeBSD]', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='cc', ldflags ='-Wl,-E -L/usr/local/lib'
libpth=/usr/lib /usr/local/lib
libs=-lm -lc -lcrypt -lutil
perllibs=-lm -lc -lcrypt -lutil
libc=, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
cccdlflags='-DPIC -fpic', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: USE_LARGE_FILES
Built under freebsd
Compiled at Oct 23 2002 11:00:00
@INC:
/usr/local/lib/perl5/5.8.0/i386-freebsd
/usr/local/lib/perl5/5.8.0
/usr/local/lib/perl5/site_perl/5.8.0/i386-freebsd
/usr/local/lib/perl5/site_perl/5.8.0
/usr/local/lib/perl5/site_perl
Backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x80711c5 in poolCopyString ()
(gdb) bt
#0 0x80711c5 in poolCopyString ()
#1 0x806cf71 in XML_SetBase ()
#2 0x28cfcc92 in XS_XML__Parser__Expat_SetBase ()
from
/usr/local/lib/perl5/site_perl/5.8.0/i386-freebsd/auto/XML/Parser/Expat/Expat.so
#3 0x28c398fb in Perl_pp_entersub () from
/usr/local/libexec/apache/libperl.so
#4 0x28c33c28 in Perl_runops_standard ()
from /usr/local/libexec/apache/libperl.so
#5 0x28bf2f36 in S_call_body () from /usr/local/libexec/apache/libperl.so
#6 0x28bf2d16 in Perl_call_sv () from
/usr/local/libexec/apache/libperl.so
#7 0x28bd3d56 in perl_call_handler ()
from /usr/local/libexec/apache/libperl.so
#8 0x28bd359e in perl_run_stacked_handlers ()
from /usr/local/libexec/apache/libperl.so
#9 0x28bd1d64 in perl_handler () from
/usr/local/libexec/apache/libperl.so
#10 0x8052595 in ap_invoke_handler ()
#11 0x806225c in process_request_internal ()
#12 0x80622bd in ap_process_request ()
#13 0x805b52e in child_main ()
#14 0x805b6a0 in make_child ()
#15 0x805b7bd in startup_children ()
#16 0x805bcb4 in standalone_main ()
#17 0x805c397 in main ()
#18 0x804ebe1 in _start ()
Any help would be good.
Ruslan.
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 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 - 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.
Segmentation fault - is Error.pm the culprit?
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.
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
Running with my debug httpd gives me a backtrace of,
Program received signal SIGSEGV, Segmentation fault.
0x810839d in Perl_sv_setsv ()
(gdb) bt
#0 0x810839d in Perl_sv_setsv ()
#1 0x80ff194 in Perl_pp_sassign ()
#2 0x80fedf6 in Perl_runops_standard ()
#3 0x80c1cd6 in S_call_body ()
#4 0x80c1aba in perl_call_sv ()
#5 0x80c1725 in perl_call_method ()
#6 0x807d458 in perl_call_handler (sv=0x978809c, r=0x97db034, args=0x0) at
mod_perl.c:1655
#7 0x807cbf5 in perl_run_stacked_handlers (hook=0x8147199 PerlHandler,
r=0x97db034, handlers=0x97a4f30) at mod_perl.c:1371
#8 0x807afab in perl_handler (r=0x97db034) at mod_perl.c:897
#9 0x809a841 in ap_invoke_handler (r=0x97db034) at http_config.c:518
#10 0x80afed0 in process_request_internal (r=0x97db034) at
http_request.c:1308
#11 0x80aff3a in ap_process_request (r=0x97db034) at http_request.c:1324
#12 0x80a68ab in child_main (child_num_arg=0) at http_main.c:4603
#13 0x80a6a6d in make_child (s=0x817f034, slot=0, now=1049069980) at
http_main.c:4718
#14 0x80a6be6 in startup_children (number_to_start=50) at http_main.c:4800
#15 0x80a7214 in standalone_main (argc=2, argv=0xbfbffb74) at
http_main.c:5108
#16 0x80a7a74 in main (argc=2, argv=0xbfbffb74) at http_main.c:5456
#17 0x8061f21 in _start ()
For the time being I can use die instead of throw since they are both caught
by my try{} block... this isn't ideal however since I can't identify the
type of exception like this.
Is this likely to be related to Error.pm? Could something else be causing
this? Any advice at all?
This is on,
mod_perl 1.27, apache 1.3.27, fbsd 4.7-release.
Richard.
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
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
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 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 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
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
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
segmentation fault using a startup file
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:
--- snip ---
mailgate:/home/www/[...]/shop/engine # /etc/init.d/apache start
Starting httpd [ Mailman PERL PHP4 Nagios ]/etc/init.d/apache: line 202:
14959 Segmentation fault $HTTPD_BIN $INET6 -t -f
/etc/httpd/httpd.conf $MODULES /var/log/httpd/rcapache.log 21
Syntax
OK
failed
mailgate:/home/www/[...]/shop/engine #
--- snap ---
In the startup file I just load some libraries as my book tells me that
the time to run the scripts will be shorter this way. (Later I want to
add Apache::DBI for a persistante database connection.)
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;
use CGI;
use URI::Escape;
use File::Basename;
use Digest::MD5;
use IO::Scalar;
use XML::Parser;
use Storable;
use XML::Simple;
use XML::Writer;
use Crypt::GeneratePassword;
use MIME::QuotedPrint;
use Mail::Sendmail;
use Text::Iconv;
# use these own Perl modules
use eqcore;
# use eqtools;
# use eqdbtools;
# use eqdebug;
# use eqtemplate;
# use pago;
return 1;
--- snap ---
Here are the versions of the installed software:
# rpm -q apache
apache-1.3.23-142
# rpm -q mod_perl
mod_perl-1.26-347
# rpm -q perl
perl-5.6.1-159
(Perl 5.6.x is needed for some other modules which have nothing to do
with this shop.)
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
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
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
/usr/sbin/apachectl: line 198: 12577 Segmentation fault $HTTPD -t
I'm trying to use some modules I wrote through PerlModule in httpd.conf The modules are tested and correct. They appear to work when they're auto-loaded. However, I wish to load them on startup of the web server. When I add the following line to my httpd.conf: PerlModule Bounce::Handler and attempt to apachectl configtest I get: /usr/sbin/apachectl: line 198: 12577 Segmentation fault $HTTPD -t Any suggestions about what I might have done wrong? Thanks, Drew
Re: /usr/sbin/apachectl: line 198: 12577 Segmentation fault $HTTPD -t
Andrew G. Hammond [EMAIL PROTECTED] writes: I'm trying to use some modules I wrote through PerlModule in httpd.conf The modules are tested and correct. They appear to work when they're auto-loaded. However, I wish to load them on startup of the web server. When I add the following line to my httpd.conf: PerlModule Bounce::Handler and attempt to apachectl configtest I get: /usr/sbin/apachectl: line 198: 12577 Segmentation fault $HTTPD -t Any suggestions about what I might have done wrong? Modules loaded in startup.pl are initialized once in the parent process instead of being initialized in each of the child processess... The question is: which modules do you use. -- ( Marcin Kasperski | You have the right to peace, fun, and productive ) ( http://www.mk.w.pl |and enjoyable work. (Beck) ) () ( Sztuczki i kruczki w C++: http://www.mk.w.pl/porady/porady_cplusplus )
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
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
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
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
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
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
Segmentation Fault with mod_php and mod_perl
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 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 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
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
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
RES: Segmentation fault
Hello Stas, I will look for those information. Anyway, it does not works under pure mod_perl too. Regards, Vitor -Mensagem original- De: Stas Bekman [mailto:[EMAIL PROTECTED]] Enviada em: terca-feira, 30 de julho de 2002 06:04 Para: Vitor Cc: [EMAIL PROTECTED] Assunto: 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
Reproductable Segmentation Fault
Hello. First, my configuration (i snipped as much as possible). DocumentRoot /home/nikratio/Projekte/www-testing Perl use lib '/home/nikratio/Projekte/www-testing/lib'; /Perl #PerlRequire debug.pl PerlModule CGI PerlModule Apache::Registry PerlModule SSIChainNG Directory /home/nikratio/Projekte/www-testing Options Includes Indexes ExecCGI Files *.pl SetHandler perl-script PerlSendHeader On PerlHandler SSIChainNG Apache::Registry /Files Files minitest.pl # PerlFixupHandler Apache::DB /Files AddHandler server-parsed .shtml Order deny,allow Allow from all AllowOverride None /Directory msg28533/pl0.pl Description: Test script msg28533/pl1.pl Description: support file 1 Include File 2 msg28533/pl2.pl Description: Custom module 1 msg28533/pl3.pl Description: Custom module 2 So far so good. Here are the versions: Apache/1.3.24 (Unix) Debian GNU/Linux mod_perl/1.26 PHP/4.2.1 mod_fastcgi/2.2.10 mod_ssl/2.8.7 OpenSSL/0.9.6c mod_jk/1.1.0 Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration: Platform: osname=linux, osvers=2.4.13, archname=i386-linux uname='linux duende 2.4.13 #1 wed oct 31 19:18:07 est 2001 i686 unknown ' config_args='-Dccflags=-DDEBIAN -Dcccdlflags=-fPIC -Darchname=i386-linux -Dprefix=/usr -Dprivlib=/usr/share/perl/5.6.1 -Darchlib=/usr/lib/perl/5.6.1 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.6.1 -Dsitearch=/usr/local/lib/perl/5.6.1 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Uusesfio -Duseshrplib -Dlibperl=libperl.so.5.6.1 -Dd_dosuid -des' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef Compiler: cc='cc', ccflags ='-DDEBIAN -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2', cppflags='-DDEBIAN -fno-strict-aliasing -I/usr/local/include' ccversion='', gccversion='2.95.4 (Debian prerelease)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, usemymalloc=n, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lgdbm -ldb -ldl -lm -lc -lcrypt perllibs=-ldl -lm -lc -lcrypt libc=/lib/libc-2.2.4.so, so=so, useshrplib=true, libperl=libperl.so.5.6.1 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): Compile-time options: USE_LARGE_FILES Built under linux Compiled at Jan 11 2002 04:09:18 INC: /usr/local/lib/perl/5.6.1 /usr/local/share/perl/5.6.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.6.1 /usr/share/perl/5.6.1 /usr/local/lib/site_perl . Basically, SSIParser is a Subclass of Apache::SSI. It parses text for SSI commands and executes them. It waqs modified to call a special method instead of printing to STDOUT, which would cause loops. SSIChainNG is a Subclass of Apache::OutputChain. It ties STDOUT to itself and searches all received data for SSI tags using SSI parser. minitest.pl causes a segfault on execution: , | [Mon Jun 24 19:35:09 2002] [notice] child pid 4575 exit signal | Segmentation fault (11) ` I couldn't solve this problem. But here are my various attempts to track the bug: 1. Joining the two print commands into one avoids the segfault: , | print(header(), | start_html(), | '!--#include virtual=t1.pl--', | h1(Main file). | '!--#include virtual=t2.html--', | end_html); ` (painless execution). 2. tied *STDOUT refers to an other object after the first print commmand. 3. Debugging session 4. Ah, the sub-request invoiced by Apache::SSI ties *STDOUT also. Therefore it is tied to the wrong request object after execution of the sub request. But protecting STDOUT with local(*STDOUT) during the sub request doesn't help. Any ideas to fix the problem? Thanks, --Nikolaus
Re: DBI modperl_2 Segmentation fault
On Fri, 24 May 2002, Udlei Nattis wrote: hi i updating modperl-2.0-cvs and problem persist now i change DynaLoader in DBI.pm to XSLoader but problem persist :( you shouldn't need to change DBI.pm the output of perl build/config.pl (normally should use t/REPORT) might help. and your DBI version.
Re: DBI modperl_2 Segmentation fault
hi i updating modperl-2.0-cvs and problem persist now i change DynaLoader in DBI.pm to XSLoader but problem persist :( can you give me one idea? thanks nattis Doug MacEachern wrote: sounds like the XSLoader vs. DynaLoader issue which only exists in 5.6.x. try updating modperl-2.0-cvs, there is a better workaround in there for the issue now.
DBI modperl_2 Segmentation fault
hi sorry, my english dont is good ;) i have one big problem, i using apache2, modperl2 and perl 5.6.1 Apache/2.0.37-dev (Unix) mod_perl/1.99_02-dev Perl/v5.6.1 when i add this line in httpd.conf PerlModule DBI or Perlrequire startup.conf startup.conf: use DBI; 1; if i use it, httpd don't start, i receive this error: /usr/local/apache-2.0/bin/apachectl: line 192: 32646 Segmentation fault (core dumped) $HTTPD /usr/local/apache-2.0/bin/apachectl start: httpd could not be started :// i test in perl 5.7.3 and other versions of modperl 2 and httpd 2 if i try use DBI; in any file.pl and request via http i dont receve any problem :/ problem is, why DBI crash apache ? thanks nattis
Re: DBI modperl_2 Segmentation fault
sounds like the XSLoader vs. DynaLoader issue which only exists in 5.6.x. try updating modperl-2.0-cvs, there is a better workaround in there for the issue now.
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
Segmentation fault 11 (php/mod_perl)
Hi, 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. Here is what I did. 1) Modified php build to NOT use its own mysql module: make clean rm config.cache ./configure --with-apxs=/web/httpd/bin/apxs --enable-track-vars --with-mysql=/usr/local/mysql make make install 2) Build mod_perl perl Makefile.PL APACHE_SRC=/usr/local/src/apache_1.3.19/src DO_HTTPD=1 USE_APACI=1 PREP_HTTPD=1 EVERYTHING=1 -Ubincompat5005 USE_DSO=1 make make install 3) Build apache env LIBS=/usr/lib/libC.so.5 CFLAGS=-fPIC ./configure --prefix=/web/httpd --enable-shared=max --enable-module=so --activate-module=src/modules/perl/libperl.a make make install Server version: Apache/1.3.19 (Unix) Server built: Mar 27 2002 22:22:11 /web/httpd/bin/httpd -l Compiled-in modules: http_core.c mod_so.c mod_perl.c suexec: disabled; invalid wrapper /web/httpd/bin/suexec # http -L output follows the perl -V output. BTW: I did redo perl to remove the malloc problem. # perl -V Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration: Platform: osname=solaris, osvers=2.8, archname=sun4-solaris uname='sunos home.primechoice.com 5.8 generic_108528-03 sun4u sparc sunw,ultra-5_10 ' config_args='-Ubincompat5005' hint=previous, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef Compiler: cc='gcc', ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O', cppflags='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64' ccversion='', gccversion='2.95.3 20010315 (release)', gccosandvers='solaris2.8' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, usemymalloc=n, prototype=define Linker and Libraries: ld='gcc', ldflags =' -L/usr/local/lib ' libpth=/usr/local/lib /usr/lib /usr/ccs/lib libs=-lsocket -lnsl -lgdbm -ldl -lm -lc perllibs=-lsocket -lnsl -ldl -lm -lc libc=/lib/libc.so, so=so, useshrplib=true, libperl=libperl.a Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' -R /usr/local/lib/perl5/5.6.1/sun4-solaris/CORE' cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under solaris Compiled at Mar 27 2002 17:45:01 INC: /usr/local/lib/perl5/5.6.1/sun4-solaris /usr/local/lib/perl5/5.6.1 /usr/local/lib/perl5/site_perl/5.6.1/sun4-solaris /usr/local/lib/perl5/site_perl/5.6.1 /usr/local/lib/perl5/site_perl . httpd -L /web/httpd/bin/httpd -L Directory (http_core.c) Container for directives affecting resources located in the specified directories Allowed in *.conf only outside Directory, Files or Location /Directory (http_core.c) Marks end of Directory Allowed in *.conf only inside Directory, Files or Location Location (http_core.c) Container for directives affecting resources accessed through the specified URL paths Allowed in *.conf only outside Directory, Files or Location /Location (http_core.c) Marks end of Location Allowed in *.conf only inside Directory, Files or Location VirtualHost (http_core.c) Container to map directives to a particular virtual host, takes one or more host addresses Allowed in *.conf only outside Directory, Files or Location /VirtualHost (http_core.c) Marks end of VirtualHost Allowed in *.conf only outside Directory, Files or Location Files (http_core.c) Container for directives affecting files matching specified patterns Allowed in *.conf anywhere and in .htaccess when AllowOverride isn't None /Files (http_core.c) Marks end of Files Allowed in *.conf anywhere and in .htaccess when AllowOverride isn't None Limit (http_core.c) Container for authentication directives when accessed using specified HTTP methods Allowed in *.conf anywhere and in .htaccess when AllowOverride isn't None /Limit (http_core.c) Marks end of Limit Allowed in *.conf anywhere and in .htaccess when AllowOverride isn't None LimitExcept (http_core.c) Container for authentication directives to be applied when any HTTP method other than those specified is used to
Re: RegistryLoader Segmentation fault
Fran Fabrizio wrote: Hello, I'm trying to follow the script in section 214 of the book mod_perl Developer's Cookbook in order to pre-load my Apache::registry scripts using Apache::RegistryLoader I'm getting a seg fault when I attempt to start apache This was the problem I was having last Friday Just wanted to post the results - the upgrade to Perl 561 solved the problem PERL_DEBUG=1 on mod_perl compilation was also very helpful Thanks to everyone for their help! -Fran
RegistryLoader Segmentation fault
Hello,
I'm trying to follow the script in section 214 of the book mod_perl
Developer's Cookbook in order to pre-load my Apache::registry scripts
using Apache::RegistryLoader I'm getting a seg fault when I attempt to
start apache
My startuppl is as follows:
#!/usr/local/bin/perl
use lib qw(/usr/local/apache/lib/perl);
use Apache::DBI;
use Apache::Registry;
use Apache::RegistryLoader;
use DBI;
use DBD::Pg;
use strict;
use CGI qw(-compile :all);
use DirHandle;
my $rl = Apache::RegistryLoader-new;
my $dh = DirHandle-new(/usr/local/apache/cgi-bin/chimpkit/) or die $!;
foreach my $file ($dh-read) {
next unless $file =~ m/\pl$/;
print STDOUT Pre-loading $file\n;
$rl-handler(/cgi-bin/chimpkit/$file,/usr/local/apache/cgi-bin/chimpkit/$file);
}
1;
When I attempt to start apache, I get the following messages on STDOUT:
[root@castle bin]# /apachectl start
Pre-loading chimpworkspl
Apache::Debug: [level 1]
Compiled package Apache::ROOT::cgi_2dbin::chimpkit::chimpworks_2epl
for process 27233 at
/usr/lib/perl5/site_perl/560/i386-linux/Apache/RegistryLoaderpm line 76
/apachectl: line 171: 27233 Segmentation fault (core dumped) $HTTPD
/apachectl start: httpd could not be started
[root@castle bin]#
Nothing has been written to the error log The format of my
$rl-handler() call seems ok to me I perused the archives for a while
and tried a couple of things that fixed other people's RegistryLoader
problems, to no avail Everything works fine if I comment out the call
to handler() except of course now each child has a copy of the compiled
code Any thoughts?
Thanks,
Fran
Re: RegistryLoader Segmentation fault
Hi there, On Fri, 1 Mar 2002, Fran Fabrizio wrote: using Apache::RegistryLoader I'm getting a seg fault when I attempt to start apache Read mod_perl/SUPPORT Did you compile your own Perl, mod_perl and Apache? You might be better off with Perl version 561 instead Are you using DSO? 73, Ged
Re: RegistryLoader Segmentation fault
Ged, using Apache::RegistryLoader I'm getting a seg fault when I attempt to start apache Read mod_perl/SUPPORT Ok I've looked through it I've tried some of the quicker suggestions gdb -core core and gdb httpd core tell me: Core was generated by `/usr/local/apache/bin/httpd' Program terminated with signal 11, Segmentation fault #0 0x80ca6b6 in Perl_gv_init () I'll try some of the more involved stuff here in a moment Did you compile your own Perl, mod_perl and Apache? Yes Perl 560, mod_perl 125, apache 1319 You might be better off with Perl version 561 instead I will upgrade and see what happens Are you using DSO? No Thanks for the pointers thus far! -Fran
Re: RegistryLoader Segmentation fault
whoops, forgot to CC the list, but it seems Ged stepped in with the same info Fran Fabrizio wrote: Hello, I'm trying to follow the script in section 214 of the book mod_perl Developer's Cookbook in order to pre-load my Apache::registry scripts using Apache::RegistryLoader I'm getting a seg fault when I attempt to start apache I've never seen a segfault with RegistryLoader, but there are a few avenues that might help see Recipe 919 for a general introduction into using gbd and getting a backtrace, as well as the SUPPORT document in the mod_perl sources maybe someone else has seen this before and can offer more help --Geoff
Re: RegistryLoader Segmentation fault
see Recipe 919 for a general introduction into using gbd and getting a backtrace, as well as the SUPPORT document in the mod_perl sources Here is the backtrace for now I'm going to try Perl 561 and then try to see what the backtrace looks like with a PERL_DEBUG=1 enabled mod_perl Thanks for the help thus far -Fran (gdb) bt #0 0x80ca6b6 in Perl_gv_init () #1 0x80cb9d5 in Perl_gv_fetchpv () #2 0x80810dd in perl_section_hash_init () #3 0x8081403 in perl_section () #4 0x809aa40 in ap_clear_module_list () #5 0x809b598 in ap_handle_command () #6 0x809b635 in ap_srm_command_loop () #7 0x809ef2a in ap_limit_section () #8 0x809aa40 in ap_clear_module_list () #9 0x809b598 in ap_handle_command () #10 0x809b635 in ap_srm_command_loop () #11 0x809bd52 in ap_process_resource_config () #12 0x80a0cc7 in ap_exists_config_define () #13 0x809aadc in ap_clear_module_list () #14 0x809b598 in ap_handle_command () #15 0x809b635 in ap_srm_command_loop () #16 0x809bd52 in ap_process_resource_config () #17 0x809c695 in ap_read_config () #18 0x80a6e9f in main () #19 0x400a1b65 in __libc_start_main (main=0x80a6bb8 main, argc=1, ubp_av=0xbaf4, init=0x80621d4 _init, fini=0x814a26c _fini, rtld_fini=0x4000df24 _dl_fini, stack_end=0xbaec) at /sysdeps/generic/libc-startc:111
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.
Segmentation fault
Just found that Apache::Util::unescape_uri when gets undefined value as parameter not returns undefined value, but make SUBJ! Why that's happens? And one more question. We have well-known-2-apaches-config and when the power one gets SF, the simple returns and logs 502 Proxy error to the _virtual host_ error_log. And mod_perl-powered server logs SF to the _server_ log. Comparing time of two errors we can get request, that leads to this error. And the question is: if we have to use one mod_perl-powered Apache - how we can find request, that breaks server? (we have more than 100 virtual hosts of our customers and that will be PITA - found the error request) Gregory Belenky WebZavod (http://www.webzavod.ru) programmer
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: Problems with mod_perl and mod_dir (Segmentation fault)
I found my problem. The mod_perl module needed to be compiled with the same version of gcc as the perl executable. I recompiled and reinstalled perl and rebuilt mod_perl and apache. Everything is working fine now. -- Bill -- On Thu, Jan 03, 2002 at 02:52:02PM -0500, William T. Martin wrote: I am having problems getting mod_dir to work with mod_perl. When mod_perl is loaded, mod_dir does not work. In particular, I want to specify DirectoryIndex index.html in my httpd.conf file to set the default file to be accessed. When mod_perl is loaded, http://somehost/~someuser does not work, but http://somehost/~someuser/index.html does. The error message I get is Document contains no data. The error log shows: [Thu Jan 3 14:48:19 2002] [notice] child pid 2934 exit signal Segmentation Fault (11) If mod_perl is not loaded, then both forms of the address work and there is no Segmentation Fault. I saw this problem posted somewhere, but do not know if it was answered. As an alternative, I tried loading the mod_perl version of AutoIndex (http://www.dmi.usherb.ca/laboratoires/documentations-logiciels/Perl/lib/Apache/ AutoIndex.html), but I get a perl compilation error at runtime. Here is my Apache configuration: # ./httpd -v Server version: Apache/1.3.22 (Unix) Server built: Jan 3 2002 13:44:35 # ./httpd -l Compiled-in modules: http_core.c mod_env.c mod_log_config.c mod_mime.c mod_negotiation.c mod_status.c mod_info.c mod_include.c mod_autoindex.c mod_dir.c mod_cgi.c mod_asis.c mod_imap.c mod_actions.c mod_userdir.c mod_alias.c mod_rewrite.c mod_access.c mod_auth.c mod_cern_meta.c mod_expires.c mod_headers.c mod_so.c mod_setenvif.c mod_ssl.c mod_php4.c mod_auth_kerb.c mod_auth_mysql.c mod_perl.c mod_autoindex.c # /usr/local/bin/perl -v This is perl, v5.6.1 built for sun4-solaris I am using mod_perl-1.26 Please help me. Thank you, -- Bill -- -- === William T. Martin email: [EMAIL PROTECTED] Cornell University/ORIE Fax:(607) 255-9129 257 Rhodes Hall Phone: (607) 255-9134 Ithaca, NY 14853 Public Key: http://www.orie.cornell.edu/~martin/public_key.html === -- === William T. Martin email: [EMAIL PROTECTED] Cornell University/ORIE Fax:(607) 255-9129 257 Rhodes Hall Phone: (607) 255-9134 Ithaca, NY 14853 Public Key: http://www.orie.cornell.edu/~martin/public_key.html ===
Problems with mod_perl and mod_dir (Segmentation fault)
I am having problems getting mod_dir to work with mod_perl. When mod_perl is loaded, mod_dir does not work. In particular, I want to specify DirectoryIndex index.html in my httpd.conf file to set the default file to be accessed. When mod_perl is loaded, http://somehost/~someuser does not work, but http://somehost/~someuser/index.html does. The error message I get is Document contains no data. The error log shows: [Thu Jan 3 14:48:19 2002] [notice] child pid 2934 exit signal Segmentation Fault (11) If mod_perl is not loaded, then both forms of the address work and there is no Segmentation Fault. I saw this problem posted somewhere, but do not know if it was answered. As an alternative, I tried loading the mod_perl version of AutoIndex (http://www.dmi.usherb.ca/laboratoires/documentations-logiciels/Perl/lib/Apache/ AutoIndex.html), but I get a perl compilation error at runtime. Here is my Apache configuration: # ./httpd -v Server version: Apache/1.3.22 (Unix) Server built: Jan 3 2002 13:44:35 # ./httpd -l Compiled-in modules: http_core.c mod_env.c mod_log_config.c mod_mime.c mod_negotiation.c mod_status.c mod_info.c mod_include.c mod_autoindex.c mod_dir.c mod_cgi.c mod_asis.c mod_imap.c mod_actions.c mod_userdir.c mod_alias.c mod_rewrite.c mod_access.c mod_auth.c mod_cern_meta.c mod_expires.c mod_headers.c mod_so.c mod_setenvif.c mod_ssl.c mod_php4.c mod_auth_kerb.c mod_auth_mysql.c mod_perl.c mod_autoindex.c # /usr/local/bin/perl -v This is perl, v5.6.1 built for sun4-solaris I am using mod_perl-1.26 Please help me. Thank you, -- Bill -- -- === William T. Martin email: [EMAIL PROTECTED] Cornell University/ORIE Fax:(607) 255-9129 257 Rhodes Hall Phone: (607) 255-9134 Ithaca, NY 14853 Public Key: http://www.orie.cornell.edu/~martin/public_key.html ===
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.
segmentation fault child pid exit
I know this maybe a known problem, but I do not seem to find any solution. 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 mod_perl is the new element that I bring in to this combination. And I always get [notice] child pid 5645 exit signal Segmentation Fault (11) in the error log file. I maynot have provide enough information. But if anybody can kindly help and let me know what information I need to provide.
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 main, 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 main, argc=3, ubp_av=0xbb3c, init=0x804fa50 _init, fini=0x808a570 _fini, rtld_fini=0x4000e184
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 main, 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
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/
Segmentation Fault
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. Thanx Uday Billawa
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/
Segmentation Fault problems
I posted this earlier and have received no replies. Am I missing
crucial information?
-
I've been getting this error...
[Thu Aug 30 17:32:54 2001] [notice] child pid 24891 exit signal
Segmentation Fault (11)
on just about any request. Not consistently though. I ran Apache in
single server mode using Apache::DB and here is what is happening...
Carp::longmess_heavy(/usr/local/lib/perl5/5.6.1/Carp/Heavy.pm:30):
30: return @_ if ref $_[0];
Carp::longmess_heavy(/usr/local/lib/perl5/5.6.1/Carp/Heavy.pm:31):
31: my $error = join '', @_;
Carp::longmess_heavy(/usr/local/lib/perl5/5.6.1/Carp/Heavy.pm:32):
32: my $mess = ;
Carp::longmess_heavy(/usr/local/lib/perl5/5.6.1/Carp/Heavy.pm:33):
33: my $i = 1 + $CarpLevel;
Carp::longmess_heavy(/usr/local/lib/perl5/5.6.1/Carp/Heavy.pm:34):
34: my ($pack,$file,$line,$sub,$hargs,$eval,$require);
Carp::longmess_heavy(/usr/local/lib/perl5/5.6.1/Carp/Heavy.pm:35):
35: my (@a);
Carp::longmess_heavy(/usr/local/lib/perl5/5.6.1/Carp/Heavy.pm:39):
39: while (do { { package DB; @a = caller($i++) } } ) {
Carp::longmess_heavy(/usr/local/lib/perl5/5.6.1/Carp/Heavy.pm:39):
39: while (do { { package DB; @a = caller($i++) } } ) {
Carp::longmess_heavy(/usr/local/lib/perl5/5.6.1/Carp/Heavy.pm:124):
124:$mess || $error;
Signal SEGV: No such file or directory
Abort
I saw a similar thing in the mailing list archives. There was a patch
posted in response for perl 5.6.0 but I'm running 5.6.1
Any help would be appreciated! Thanks.
Here is some info:
Solaris 8 (SunOS 5.8)
Apache/1.3.12 (Unix) mod_perl/1.24_01 mod_ssl/2.6.5 OpenSSL/0.9.4
Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration:
Platform:
osname=solaris, osvers=2.8, archname=sun4-solaris
uname='sunos dev1 5.8 generic_108528-02 sun4u sparc sunw,ultra-2 '
config_args='-ds -e -Uuselargefiles'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=undef
useperlio=undef d_sfio=undef uselargefiles=undef usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
Compiler:
cc='cc', ccflags ='-fno-strict-aliasing -I/usr/local/include',
optimize='-O',
cppflags='-fno-strict-aliasing -I/usr/local/include'
ccversion='', gccversion='2.95.2 19991024 (release)',
gccosandvers='solaris2.8'
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=4
alignbytes=8, usemymalloc=y, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /usr/lib /usr/ccs/lib
libs=-lsocket -lnsl -ldl -lm -lc
perllibs=-lsocket -lnsl -ldl -lm -lc
libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options:
Built under solaris
Compiled at Aug 30 2001 17:04:47
@INC:
/usr/local/lib/perl5/5.6.1/sun4-solaris
/usr/local/lib/perl5/5.6.1
/usr/local/lib/perl5/site_perl/5.6.1/sun4-solaris
/usr/local/lib/perl5/site_perl/5.6.1
/usr/local/lib/perl5/site_perl/5.6.0/sun4-solaris
/usr/local/lib/perl5/site_perl/5.6.0
/usr/local/lib/perl5/site_perl/5.005/sun4-solaris
/usr/local/lib/perl5/site_perl/5.005
/usr/local/lib/perl5/site_perl
.
--
Brian Cocks
Senior Software Architect
Multi-Ad Services, Inc.
[EMAIL PROTECTED]
(309)690-5834
Apache::DBI Segmentation fault
I am getting a segmentation fault on configtest when using Apache::DBI (using the startup.pl example in Apache::DBI Distribution). When trying to start the server I get no error messages but the server isn't running afterwards: root@ganja:/home/www/server/conf ../bin/apachectl start ../bin/apachectl start: httpd started root@ganja:/home/www/server/conf ps -ef | grep httpd lengerke 5787 27877 0 12:11 pts/500:00:00 vi httpd.conf root 6434 5760 0 12:57 pts/11 00:00:00 grep httpd root@ganja:/home/www/server/conf ../bin/apachectl configtest Syntax OK ../bin/apachectl: line 184: 6436 Segmentation fault $HTTPD -t root@ganja:/home/www/server/conf When I comment out the 'use Apache::DBI' in startup.pl all works fine. Setting $Apache::DBI::DEBUG = 2 makes no difference even in verbosity of the error_log - the server will die without any warning or error. The setup is: SuSE Linux 6.3 (i386) Apache/1.3.20 (Unix) # (enabled proxy, rewrite, so, ssl) PHP/4.0.6 # apxs-built DSO mod_perl/1.26 # apxs-built DSO mod_jk # apxs-built DSO mod_ssl/2.8.4 OpenSSL/0.9.4 Perl 5.005_03 Apache::DBI 0.88 DBI 1.14 # works fine without Apache::DBI Any help or pointers are appreciated. Hans
Re: Apache::DBI Segmentation fault
Uh, sorry forgot to post Database and perl -V... Database is Informix. Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration: Platform: osname=linux, osvers=2.2.13, archname=i586-linux uname='linux benjy 2.2.13 #4 mon aug 16 11:18:11 mest 1999 i686 unknown ' hint=recommended, useposix=true, d_sigaction=define usethreads=undef useperlio=undef d_sfio=undef Compiler: cc='cc', optimize='-O2 -pipe', 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 -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 Nov 6 1999 15:47:59 @INC: /usr/lib/perl5/5.00503/i586-linux /usr/lib/perl5/5.00503 /usr/lib/perl5/site_perl/5.005/i586-linux /usr/lib/perl5/site_perl/5.005 . Hans Juergen von Lengerke: I am getting a segmentation fault on configtest when using Apache::DBI (using the startup.pl example in Apache::DBI Distribution). When trying to start the server I get no error messages but the server isn't running afterwards: root@ganja:/home/www/server/conf ../bin/apachectl start ../bin/apachectl start: httpd started root@ganja:/home/www/server/conf ps -ef | grep httpd lengerke 5787 27877 0 12:11 pts/500:00:00 vi httpd.conf root 6434 5760 0 12:57 pts/11 00:00:00 grep httpd root@ganja:/home/www/server/conf ../bin/apachectl configtest Syntax OK ../bin/apachectl: line 184: 6436 Segmentation fault $HTTPD -t root@ganja:/home/www/server/conf When I comment out the 'use Apache::DBI' in startup.pl all works fine. Setting $Apache::DBI::DEBUG = 2 makes no difference even in verbosity of the error_log - the server will die without any warning or error. The setup is: SuSE Linux 6.3 (i386) Apache/1.3.20 (Unix) # (enabled proxy, rewrite, so, ssl) PHP/4.0.6 # apxs-built DSO mod_perl/1.26 # apxs-built DSO mod_jk # apxs-built DSO mod_ssl/2.8.4 OpenSSL/0.9.4 Perl 5.005_03 Apache::DBI 0.88 DBI 1.14 # works fine without Apache::DBI Any help or pointers are appreciated. Hans
Re: Apache::DBI Segmentation fault
I am getting a segmentation fault on configtest when using Apache::DBI (using the startup.pl example in Apache::DBI Distribution). When trying to start the server I get no error messages but the server isn't running afterwards Do you know that your DBI works without Apache::DBI? It would be helpful if you could post the relevant parts of your httpd.conf and startup.pl too. - Perrin
Re: Apache::DBI Segmentation fault
Hi,
I actually got this to work now. The segfault happens when I load
Apache::Registry before Apache::DBI. However, I have used the
eg/startup.pl from the Apache::DBI distribution and that has
Apache::Registry loaded before Apache::DBI... Maybe this is a bug?
My httpd.conf Perl* relevant parts:
LoadModule perl_module libexec/libperl.so
[...]
PerlRequire /home/www/server/conf/startup.pl
PerlFreshRestart on
[...]
PerlModule Apache::Registry
DirectoryMatch /home/www/hosts/[^/]*/cgi-perl
Options FollowSymLinks ExecCGI
SetHandler perl-script
PerlHandler Apache::Registry
PerlSendHeader On
AllowOverride None
Order allow,deny
Allow from all
/DirectoryMatch
[...]
Location /perl-status
SetHandler perl-script
PerlSetVar StatusOptionsAll On
PerlHandler Apache::Status
/Location
and the (fixed) startup.pl:
#!/usr/local/bin/perl -w
$ENV{GATEWAY_INTERFACE} =~ /^CGI-Perl/ or die GATEWAY_INTERFACE not Perl!;
use Apache::DBI;
use Apache::Registry;
use strict;
$Apache::DBI::DEBUG = 2;
Now if Apache::Registry is loaded before Apache::DBI in startup.pl I get
the segfault. Also, If I don't use startup.pl and put a 'PerlModule
Apache::DBI' _after_ the 'PerlModule Apache::Registry' in my httpd.conf
I also get the segfault. I am aware that any modules that use DBI must
be loaded _after_ Apache::DBI but I didn't think Apache::Registry uses
DBI, or does it?
Hans
Perrin Harkins:
I am getting a segmentation fault on configtest when using Apache::DBI
(using the startup.pl example in Apache::DBI Distribution). When trying
to start the server I get no error messages but the server isn't
running afterwards
Do you know that your DBI works without Apache::DBI? It would be helpful if
you could post the relevant parts of your httpd.conf and startup.pl too.
- Perrin
Children exiting with Segmentation Fault
I've been getting this error...
[Thu Aug 30 17:32:54 2001] [notice] child pid 24891 exit signal
Segmentation Fault (11)
on just about any request. Not consistently though. I ran Apache in
single server mode using Apache::DB and here is what is happening...
Carp::longmess_heavy(/usr/local/lib/perl5/5.6.1/Carp/Heavy.pm:30):
30: return @_ if ref $_[0];
Carp::longmess_heavy(/usr/local/lib/perl5/5.6.1/Carp/Heavy.pm:31):
31: my $error = join '', @_;
Carp::longmess_heavy(/usr/local/lib/perl5/5.6.1/Carp/Heavy.pm:32):
32: my $mess = ;
Carp::longmess_heavy(/usr/local/lib/perl5/5.6.1/Carp/Heavy.pm:33):
33: my $i = 1 + $CarpLevel;
Carp::longmess_heavy(/usr/local/lib/perl5/5.6.1/Carp/Heavy.pm:34):
34: my ($pack,$file,$line,$sub,$hargs,$eval,$require);
Carp::longmess_heavy(/usr/local/lib/perl5/5.6.1/Carp/Heavy.pm:35):
35: my (@a);
Carp::longmess_heavy(/usr/local/lib/perl5/5.6.1/Carp/Heavy.pm:39):
39: while (do { { package DB; @a = caller($i++) } } ) {
Carp::longmess_heavy(/usr/local/lib/perl5/5.6.1/Carp/Heavy.pm:39):
39: while (do { { package DB; @a = caller($i++) } } ) {
Carp::longmess_heavy(/usr/local/lib/perl5/5.6.1/Carp/Heavy.pm:124):
124:$mess || $error;
Signal SEGV: No such file or directory
Abort
I saw a similar thing in the mailing list archives. There was a patch
posted in response for perl 5.6.0 but I'm running 5.6.1
Any help would be appreciated! Thanks.
Here is some info:
Solaris 8 (SunOS 5.8)
Apache/1.3.12 (Unix) mod_perl/1.24_01 mod_ssl/2.6.5 OpenSSL/0.9.4
Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration:
Platform:
osname=solaris, osvers=2.8, archname=sun4-solaris
uname='sunos dev1 5.8 generic_108528-02 sun4u sparc sunw,ultra-2 '
config_args='-ds -e -Uuselargefiles'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=undef
useperlio=undef d_sfio=undef uselargefiles=undef usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
Compiler:
cc='cc', ccflags ='-fno-strict-aliasing -I/usr/local/include',
optimize='-O',
cppflags='-fno-strict-aliasing -I/usr/local/include'
ccversion='', gccversion='2.95.2 19991024 (release)',
gccosandvers='solaris2.8'
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=4
alignbytes=8, usemymalloc=y, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /usr/lib /usr/ccs/lib
libs=-lsocket -lnsl -ldl -lm -lc
perllibs=-lsocket -lnsl -ldl -lm -lc
libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options:
Built under solaris
Compiled at Aug 30 2001 17:04:47
@INC:
/usr/local/lib/perl5/5.6.1/sun4-solaris
/usr/local/lib/perl5/5.6.1
/usr/local/lib/perl5/site_perl/5.6.1/sun4-solaris
/usr/local/lib/perl5/site_perl/5.6.1
/usr/local/lib/perl5/site_perl/5.6.0/sun4-solaris
/usr/local/lib/perl5/site_perl/5.6.0
/usr/local/lib/perl5/site_perl/5.005/sun4-solaris
/usr/local/lib/perl5/site_perl/5.005
/usr/local/lib/perl5/site_perl
.
--
Brian Cocks
Senior Software Architect
Multi-Ad Services, Inc.
[EMAIL PROTECTED]
(309)690-5834
Segmentation Fault (11)
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? Thanks!
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/
Apache::Session::Postgres Segmentation Fault
I'm using Apache::Session::Postgres with Apache::ASP. I'm getting a Segmentation Fault whenever I do a $dbh-disconnect at the end of the script. When I comment out the the $dbh-disconnect however, I don't get any errors. Having a script without a $dbh-disconnect at the end is wrong isn't it. Anyone encountered this before? Thanks. -- Mike
Apache::Session::Postgres Segmentation Fault Addendum
I'm using Apache::Session::Postgres with Apache::ASP. I'm getting a Segmentation Fault whenever I do a $dbh-disconnect at the end of the script. When I comment out the the $dbh-disconnect however, I don't get any errors. Having a script without a $dbh-disconnect at the end is wrong isn't it. Anyone encountered this before? I just tested it as a simple perl script on the command line. I'm still getting a core dumped Segmentation Fault whenever I do a disconnect at the end of the script.
Re: Apache::Session::Postgres Segmentation Fault Addendum
On Thu, 29 Mar 2001, Victor Michael Blancas wrote: I'm using Apache::Session::Postgres with Apache::ASP. I'm getting a Segmentation Fault whenever I do a $dbh-disconnect at the end of the script. When I comment out the the $dbh-disconnect however, I don't get any errors. Having a script without a $dbh-disconnect at the end is wrong isn't it. Anyone encountered this before? I just tested it as a simple perl script on the command line. I'm still getting a core dumped Segmentation Fault whenever I do a disconnect at the end of the script. Sounds like a Postgres bug. Can you hook up GDB and get a stack trace? -jwb
Re: Apache::Session::Postgres Segmentation Fault Addendum
Victor Michael Blancas wrote: I'm using Apache::Session::Postgres with Apache::ASP. I'm getting a Segmentation Fault whenever I do a $dbh-disconnect at the end of the script. When I comment out the the $dbh-disconnect however, I don't get any errors. Having a script without a $dbh-disconnect at the end is wrong isn't it. Anyone encountered this before? I just tested it as a simple perl script on the command line. I'm still getting a core dumped Segmentation Fault whenever I do a disconnect at the end of the script. If you are using Apache::DBI, then dbh-disconnect should not do anything, so this might get around the problem you are having? -- Josh _ Joshua Chamas Chamas Enterprises Inc. NodeWorks free web link monitoring Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
Re: Apache::Session::Postgres Segmentation Fault Addendum
On Thu, 29 Mar 2001, Victor Michael Blancas wrote: I'm using Apache::Session::Postgres with Apache::ASP. I'm getting a Segmentation Fault whenever I do a $dbh-disconnect at the end of the script. When I comment out the the $dbh-disconnect however, I don't get any errors. Having a script without a $dbh-disconnect at the end is wrong isn't it. Anyone encountered this before? I just tested it as a simple perl script on the command line. I'm still getting a core dumped Segmentation Fault whenever I do a disconnect at the end of the script. I've seen segfaults with DBD::Pg if I do a disconnect() and then try and execute something on that disconnected handle. Try doing DBI-trace(2) in your command line script to see if something odd is happening. -- Matt/ /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
Re: Apache::Session::Postgres Segmentation Fault Addendum
On Thu, 29 Mar 2001, Victor Michael Blancas wrote:
I'm using Apache::Session::Postgres with Apache::ASP.
I'm getting a Segmentation Fault whenever I do a $dbh-disconnect at the
end of the script. When I comment out the the $dbh-disconnect however, I
don't get any errors. Having a script without a $dbh-disconnect at the
end is wrong isn't it. Anyone encountered this before?
I just tested it as a simple perl script on the command line. I'm still
getting a core dumped Segmentation Fault whenever I do a disconnect at the
end of the script.
I have had this happen to me as well. You have to make sure that your
session is untied, before the database is disconnected.
What I found was that after pulling some data out of the session, it was
still TIE'ed to the session object.
ie I with the following
my $userid = $session-{userid};
$userid is pointing into the tied hash, so if the database disappears, and
you try to access $userid, you will get a segfault.
The following program demonstrates this on my system
use strict;
use Apache::Session::Postgres ();
use DBI ();
my $dbh = DBI-connect('DBI:Pg:dbname=testdb', undef, undef,
{ RaiseError = 1, AutoCommit = 0 })
or die "connect: Can't connect to database: $DBI::errstr";
tie my %s, 'Apache::Session::Postgres', undef,
{ 'Handle' = $dbh, 'Commit' = 1 };
# Put something in the session and then take it out again
$s{'testing'} = 'Something to put in the session';
my $test = $s{'testing'};
# disconnect from database
$dbh-disconnect;
# Accessing $test again will cause a segfault
print $test, "\n";
I realize that this is bad programming style, since I should untie %s
before I disconnect $dbh, and doing that stops the segfault (it also means
that $test will be blank if it is accessed after the untie). But I don't
think that this should cause a segfault in the first place.
It sounds like there is a problem in Apache::Session::Postgres but I
haven't had time to search for it...
Cees Hek
Re: [Mason] Segmentation Fault
I found the solution. I had been using "Apache::Cookie-fetch", both from an authen handler and from a request handler. I switched to using "Apache::Cookie-parse" instead, and the segv went away. The Apache::Cookie monster ought to scare that bug out of the code though; no matter what, it should not segv. -- mailto: (Karl M. Hegbloom) [EMAIL PROTECTED] http://www.microsharp.com phone://USA/WA/360-260-2066
segmentation fault 11
Hello, my last post has been solved. After searching through google most of the morning I decided to upgrade mysql to version 3.23.33 and rebuild absolutely everything. And hey presto, everything works. It may have been something to do with the earlier mysql version but more likely the incremental sequence in which I am rebuilding apache. = Mr. Michael Turley Gracious winner, Generous lover, All round great guy. __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
Segmentation fault in apache child when calling DBI::connect
Hi, I use apache1.3.12 with mod_perl 1.24 and I've been using it in several programs with DBI (version 1.13). This is the first time I get an error like this, other programs that uses DBI are still working. In command line everything is working ok, but when I run my program under mod_perl, I get no data (not even headers), and the only message in the error log (with LogLevel debug) is this: [Tue Jan 9 09:40:54 2001] [notice] child pid 28932 exit signal Segmentation fault (11) I've debugged everything and discovered that the error occurs when I call DBI-connect. I debbuged DBI.pm and DBD/mysql.pm and found that the error happens in the following line, in DBD::mysql (version 2.0402): DBD::mysql::db::_login($this, $dsn, $username, $password) or $this = undef I've tried also to connect to different databases in different servers, but the error persists. Does anyone have any idea of how to solve this? Thanks a lot. []s Luis
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
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
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
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
"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/
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
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
DBI segmentation fault only in mod_perl
Hi,
I've been working with HTML::Mason and have been unable to connect
to mysql with DBI. There is a problem with the configuration on my
machine
such that perl won't check
/usr/local/lib/perl5/site_perl/5.6.0/i586-linux/ for
modules unless it's explicitly asked to. I don't really know why that
is or how
I would fix it.
In any case, if I make a file startup.pl like:
#
use lib "/usr/local/lib/perl5/site_perl/5.6.0/i586-linux";
# this is a test
use DBI;
unless ( $dbh =
DBI-connect("DBI:mysql:adatabase","test","",{PrintError=0})) {
print STDERR "unable to get dbi connection: $DBI::errstr\n";
}
print STDERR "successfully created dbh $dbh\n";
$dbh-disconnect;
1;
#
and run it from the command line, it works. If I PerlRequire it in my
httpd.conf
I get a segmentation fault when I run "apachectl configtest". The last
frame of
the stack in the core dump is as follows:
###
#0 0x402125aa in mysql_real_connect (mysql=0x0, host=0x0,
user=0x82caf60 "test", passwd=0x0,
db=0x82c8c58 "adatabase", port=0, unix_socket=0x0, client_flag=0) at
libmysql.c:1125
1125libmysql.c: No such file or directory.
What's going on? Any help would be much appreciated!
- Noam
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
segmentation fault when using custom config module
Relevant info:
Apache: 1.3.12
mod_perl: 1.24
Perl: 5.00503
gcc 2.95.1 on Linus 2.2.18pre19
I created a module that contains custom configs with the following code:
package HTML::Mason::Dispatcher;
use ExtUtils::MakeMaker;
use Apache::ExtUtils;
use Apache::src;
my @directives = ( { name = 'MasonCompRoot',
errmsg = 'The directory that is the Mason component
root',
args_how = 'TAKE1',
req_override = 'RSRC_CONF',
},
{ name = 'MasonDataDir',
errmsg = 'The Mason data directory',
args_how = 'TAKE1',
req_override = 'RSRC_CONF',
},
{ name = 'MasonArgsMethod',
errmsg = 'The method used to process arguments (CGI.pm or
mod_perl)',
args_how = 'TAKE1',
req_override = 'RSRC_CONF',
},
);
local $^W;
Apache::ExtUtils::command_table(\@directives);
WriteMakefile( NAME= 'HTML::Mason::Dispatcher',
VERSION_FROM = 'Dispatcher.pm',
INC = Apache::src-new-inc,
);
The Dispatcher.pm files contains the following code:
package HTML::Mason::Dispatcher;
use strict;
use Apache::ModuleConfig ();
use DynaLoader ();
use HTML::Mason;
use vars qw($VERSION $AH @ISA);
$VERSION = '0.01';
@ISA = qw(DynaLoader);
use constant DEBUG = 1;
__PACKAGE__-bootstrap($VERSION) if $ENV{MOD_PERL};
sub MasonCompRoot ($$$)
{
my ($cfg, $params, $comp_root) = @_;
$cfg-{Mason}{comp_root} = $comp_root;
}
sub MasonDataDir ($$$)
{
my ($cfg, $params, $data_dir) = @_;
$cfg-{Mason}{data_dir} = $data_dir;
}
sub MasonArgsMethod ($$$)
{
my ($cfg, $params, $method) = @_;
unless ( $method eq 'CGI' || $method eq 'mod_perl' )
{
die "Invalid MasonArgsMethod param: $method\n";
}
eval "use HTML::Mason::ApacheHandler ( args_method = '$method' )";
die $@ if $@;
}
sub handler
{
eval "use HTML::Mason::ApacheHandler;" unless $HTML::Mason::ApacheHandler::VERSION;
my $r = shift;
unless ($AH)
{
my $cfg = Apache::ModuleConfig-get($r);
my $interp = HTML::Mason::Interp-new( parser = HTML::Mason::Parser-new,
comp_root = $cfg-{Mason}{comp_root},
data_dir = $cfg-{Mason}{data_dir} );
$AH = HTML::Mason::ApacheHandler( interp = $interp );
}
return $AH-handle_request($r);
}
--
My config file contains the following:
Perl
use lib '/home/autarch/mason-CVS/mason/dist/lib';
/Perl
PerlModule HTML::Mason::Dispatcher
MasonCompRoot /usr/local/apache/htdocs
MasonDataDir /usr/local/apache_mp/mason
MasonArgsMethod mod_perl
FilesMatch "\.mhtml$"
SetHandler perl-script
PerlHandler HTML::Mason::Dispatcher
/FilesMatch
---
Anyway, the configuration directives piece works fine. I added warn
statements in the relevant functions and it confirmed that were indeed
being called with the correct values.
However, when I make a request to a URL that would call the handler
method, I get a segmentation fault.
I recompiled mod_perl with tracing and set MOD_PERL_TRACE=all. The trace
was pretty uninteresting. Here's what I got when starting the server:
perl_parse args: '-w' '/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: /Files
perl_section: /Directory
perl_section: /Files
perl_section: /Directory
perl_section: /VirtualHost
perl_section: /Location
perl_section: /Location
loading perl module 'Apache'...ok
PerlModule: arg='HTML::Mason::Dispatcher'
loading perl module 'HTML::Mason::Dispatcher'...ok
bootstrapping Perl sections: arg=HTML::Mason::Dispatcher, keys=10
loading perl module 'Apache'...ok
loading perl module 'Tie::IxHash'...ok
perl_section: /Files
perl_section: /Directory
perl_section: /Files
perl_section: /Directory
perl_section: /VirtualHost
perl_section: /Location
perl_section: /Location
mod_perl: delete $INC{'HTML/Mason/Dispatcher.pm'} (klen=24)
blessing cmd_parms=(0xbab4)
blessing cmd_parms=(0xbab4)
blessing cmd_parms=(0xbab4)
init `PerlHandler' stack
perl_cmd_push_handlers: @PerlHandler, 'HTML::Mason::Dispatcher'
pushing `HTML::Mason::Dispatcher' into `PerlHandler' handlers
And here's what's in the error_log file:
`PerlRestartHandler' push_handlers() stack is empty
PerlRestartHandler handlers returned -1
[Wed Nov 29 02:40:08 2000] [notice] Apach
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__); -- Matt/ /||** 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 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]
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/
Location /ads
SetHandler perl-script
PerlHandler Apache::Registry
Options ExecCGI
allow from all
PerlSendHeader On
/Location
*
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
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/
Location /ads
SetHandler perl-script
PerlHandler Apache::Registry
Options ExecCGI
allow from all
PerlSendHeader On
/Location
*
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 (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/
| Location /ads
|SetHandler perl-script
|PerlHandler Apache::Registry
|Options ExecCGI
|allow from all
|PerlSendHeader On
| /Location
|
|
| *
|
| 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: :Parse segmentation fault
On Tue, 10 Oct 2000, Matt Sergeant wrote: On Mon, 9 Oct 2000, Herrington, Jack wrote: This allows for XML parsing with no change to the Perl code. I'm just not sure what I am losing in Apache (which is where I make the change). What does losing EXPAT do to Apache? You lose mod_dav, and maybe future modules that use the built in expat support. But nothing serious. All of hte problems that you are seeing are essentially due to the fact that XML::Parser uses its own version of expat that has been patched. So the expat code from XML::Parser conflicts with the expat code from apache if you built with RULE_EXPAT=yes. Things get further complicated if you use php, which also pulls in a customized version of expat, causing more conflicts. There is work to fix this going on by maintaining expat so that it contains all of hte patches from these projects. This is on sourceforge at http://expat.sourceforge.net/ They have a preliminary release that I have built as a shared library and it works fine on our system. We use it this way: Compile apache with: RULE_EXPAT=no Build expat from sourceforge as a shared library fiddle with XML::Parser makefiles to cause it to link against libexpat.so instead of bulding its customized version. build mod_dav by linking with libexpat.so So XML::Parser and mod_dav can co-exist happily in this situation. I have .rpms and .src.rpm files of expat, XML::Parser, mod_dav which include the patches. If anyone is interested, please let me know and I will be happy to forward them to you (the rpms, or the patches). Mike
Re: XML::Parse segmentation fault
On Mon, 9 Oct 2000, Herrington, Jack wrote: Is there some inherint problem with XML::Parser and mod_perl? Yes. You need to recompile Apache with RULE_EXPAT=no. I'm hoping that now that expat has a standard distribution that the Apache team will be proactive in fixing this bug. -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\
RE: :Parse segmentation fault
On Mon, 9 Oct 2000, Herrington, Jack wrote: This allows for XML parsing with no change to the Perl code. I'm just not sure what I am losing in Apache (which is where I make the change). What does losing EXPAT do to Apache? You lose mod_dav, and maybe future modules that use the built in expat support. But nothing serious. -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\
RE: XML::Parse segmentation fault
-Original Message- From: Matt Sergeant [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 10, 2000 3:20 AM To: Herrington, Jack Cc: '[EMAIL PROTECTED]' Subject: Re: XML::Parse segmentation fault On Mon, 9 Oct 2000, Herrington, Jack wrote: Is there some inherint problem with XML::Parser and mod_perl? Yes. You need to recompile Apache with RULE_EXPAT=no. according to Changes, this should be automatic as of 1.23... are you using an older version or are the conflicts still aparent in 1.23 or 1.24? --Geoff I'm hoping that now that expat has a standard distribution that the Apache team will be proactive in fixing this bug. -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\
RE: XML::Parse segmentation fault
On Tue, 10 Oct 2000, Geoffrey Young wrote: On Mon, 9 Oct 2000, Herrington, Jack wrote: Is there some inherint problem with XML::Parser and mod_perl? Yes. You need to recompile Apache with RULE_EXPAT=no. according to Changes, this should be automatic as of 1.23... Of course only if you compile Apache from mod_perl's Makefile.PL. From what I've heard, Greg Stein is now aware of the problem and willing to work it out for the next Apache release. But whether that happens remains to be seen... -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\
XML::Parse segmentation fault
This code works as a perl script executed off the command line:
use XML::Parser;
my $parser = new XML::Parser();
$parser-parse( "form/form" );
This code fails with a segmentation fault when called from mod_perl:
package CBL::mod_perl::test1;
use strict;
use XML::Parser;
sub handler
{
my $r = shift;
my $parser = new XML::Parser();
$parser-parse( "form/form" );
$r-content_type( 'text/html' );
$r-send_http_header;
$r-print( "htmlbody" );
$r-print( "Testing" );
$r-print( "/body/html" );
return OK;
}
1;
Is there some inherint problem with XML::Parser and mod_perl?
Jack Herrington
Engineering Manager
Certive - Building the world's first broadband B2B network
(650) 701-8809
RE: :Parse segmentation fault
Title: RE: :Parse segmentation fault
Yes. We found a problem in Expat.pm line 451 (in sub parse). The following chunk of code (latest version from cpan)
sub parse {
my $self = shift;
my $arg = shift;
croak Parse already in progress (Expat) if $self-{_State_};
$self-{_State_} = 1;
my $parser = $self-{Parser};
my $ioref;
my $result = 0;
if (defined $arg) {
if (ref($arg) and UNIVERSAL::isa($arg, 'IO::Handler')) {
$ioref = $arg;
} else {
eval {
$ioref = *{$arg}{IO}; ### Problem code
};
undef $@;
}
}
## Rest snipped
As you can see it's trying to oddly reference what you passs in to parse as some screwed up typeglof reference. In your example (and indeed in our code) we where simply passing a scalar. This generated coredumps. We got around the problem by just commenting out the eval and $ioref code, So The above became
if (ref($arg) and UNIVERSAL::isa($arg, 'IO::Handler')) {
$ioref = $arg;
} else {
##eval {
## $ioref = *{$arg}{IO}; ### Problem code
##};
undef $@;
}
Clean fix? No, but we are always dealing with scalars, not some other sort of odd input stream and just punted on the problem. Core dumps disappeared.
-Original Message-
From: Herrington, Jack [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 09, 2000 3:03 PM
To: '[EMAIL PROTECTED]'
Subject: XML::Parse segmentation fault
This code works as a perl script executed off the command line:
use XML::Parser;
my $parser = new XML::Parser();
$parser-parse( form/form );
This code fails with a segmentation fault when called from mod_perl:
package CBL::mod_perl::test1;
use strict;
use XML::Parser;
sub handler
{
my $r = shift;
my $parser = new XML::Parser();
$parser-parse( form/form );
$r-content_type( 'text/html' );
$r-send_http_header;
$r-print( htmlbody );
$r-print( Testing );
$r-print( /body/html );
return OK;
}
1;
Is there some inherint problem with XML::Parser and mod_perl?
Jack Herrington
Engineering Manager
Certive - Building the world's first broadband B2B network
(650) 701-8809
RE: :Parse segmentation fault
Title: RE: :Parse segmentation fault
I did a
little more digging around and found that you could also avoid the problem by
turning off EXPAT in apache with:
Rule
EXPAT=no
Which fix is
more preferable?
-Original Message-From: Shane Adams
[mailto:[EMAIL PROTECTED]]Sent: Monday, October 09, 2000 3:43
PMTo: Herrington, Jack; '[EMAIL PROTECTED]'Subject: RE:
:Parse segmentation fault
Yes. We found a problem in Expat.pm line 451 (in sub
parse). The following chunk of code (latest version from cpan)
sub parse { my $self =
shift; my $arg = shift; croak "Parse already in progress (Expat)" if
$self-{_State_}; $self-{_State_} =
1; my $parser = $self-{Parser};
my $ioref; my $result =
0;
if (defined $arg) { if (ref($arg) and UNIVERSAL::isa($arg,
'IO::Handler')) {
$ioref = $arg; } else {
eval { $ioref =
*{$arg}{IO}; ### Problem code }; undef $@; } } ## Rest snipped
As you can see it's trying to oddly reference what you passs
in to parse as some screwed up typeglof reference. In your example (and
indeed in our code) we where simply passing a scalar. This generated
coredumps. We got around the problem by just commenting out the eval and
$ioref code, So The above became
if (ref($arg) and UNIVERSAL::isa($arg,
'IO::Handler')) {
$ioref = $arg; } else {
##eval { ## $ioref =
*{$arg}{IO}; ### Problem code ##}; undef $@; }
Clean fix? No, but we are always dealing with scalars,
not some other sort of odd input stream and just punted on the problem.
Core dumps disappeared.
-Original Message- From:
Herrington, Jack [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 09, 2000 3:03 PM To: '[EMAIL PROTECTED]' Subject: XML::Parse
segmentation fault
This code works as a perl script executed off the command
line:
use
XML::Parser; my $parser = new XML::Parser();
$parser-parse(
"form/form" );
This code fails with a segmentation fault when called from
mod_perl:
package
CBL::mod_perl::test1;
use strict;
use
XML::Parser;
sub handler
{
my $r = shift;
my $parser = new
XML::Parser(); $parser-parse(
"form/form" );
$r-content_type(
'text/html' );
$r-send_http_header;
$r-print(
"htmlbody" );
$r-print( "Testing"
); $r-print(
"/body/html" );
return OK;
}
1;
Is there some inherint problem with XML::Parser and
mod_perl?
Jack Herrington
Engineering
Manager Certive - Building the world's first broadband B2B network
(650)
701-8809
RE: :Parse segmentation fault
Title: RE: :Parse segmentation fault
Hmmm
well I *have* to have Xml parsing. Not sure if what you are suggesting totally
turns it off or just does something else?
-Original Message-From: Herrington, Jack
[mailto:[EMAIL PROTECTED]]Sent: Monday, October 09, 2000
3:49 PMTo: Shane Adams; '[EMAIL PROTECTED]'Subject: RE:
:Parse segmentation fault
I did a
little more digging around and found that you could also avoid the problem by
turning off EXPAT in apache with:
Rule
EXPAT=no
Which fix
is more preferable?
-Original Message-From: Shane Adams
[mailto:[EMAIL PROTECTED]]Sent: Monday, October 09, 2000 3:43
PMTo: Herrington, Jack; '[EMAIL PROTECTED]'Subject:
RE: :Parse segmentation fault
Yes. We found a problem in Expat.pm line 451 (in sub
parse). The following chunk of code (latest version from cpan)
sub parse { my $self =
shift; my $arg = shift; croak "Parse already in progress (Expat)" if
$self-{_State_}; $self-{_State_} =
1; my $parser = $self-{Parser};
my $ioref; my $result
= 0;
if (defined $arg) { if (ref($arg) and UNIVERSAL::isa($arg,
'IO::Handler')) {
$ioref = $arg; } else {
eval { $ioref =
*{$arg}{IO}; ### Problem code }; undef $@; } }
## Rest snipped
As you can see it's trying to oddly reference what you passs
in to parse as some screwed up typeglof reference. In your example
(and indeed in our code) we where simply passing a scalar. This
generated coredumps. We got around the problem by just commenting out
the eval and $ioref code, So The above became
if (ref($arg) and UNIVERSAL::isa($arg,
'IO::Handler')) {
$ioref = $arg; } else {
##eval { ## $ioref =
*{$arg}{IO}; ### Problem code ##}; undef $@; }
Clean fix? No, but we are always dealing with scalars,
not some other sort of odd input stream and just punted on the
problem. Core dumps disappeared.
-Original Message- From:
Herrington, Jack [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 09, 2000 3:03 PM To: '[EMAIL PROTECTED]' Subject: XML::Parse
segmentation fault
This code works as a perl script executed off the command
line:
use
XML::Parser; my $parser = new XML::Parser();
$parser-parse( "form/form" );
This code fails with a segmentation fault when called from
mod_perl:
package
CBL::mod_perl::test1;
use
strict; use XML::Parser;
sub
handler { my $r = shift;
my $parser = new
XML::Parser(); $parser-parse(
"form/form" );
$r-content_type(
'text/html' );
$r-send_http_header;
$r-print(
"htmlbody" );
$r-print( "Testing"
); $r-print(
"/body/html" );
return OK;
}
1;
Is there some inherint problem with XML::Parser and
mod_perl?
Jack Herrington
Engineering
Manager Certive - Building the world's first broadband B2B network
(650)
701-8809
