mod_perl and GD.pm segfault
Embedded Perl version v5.8.0 for Apache/1.3.27 (Unix) PHP/4.3.2 mod_perl/1.28 mod_ssl/2.8.14 OpenSSL/0.9.6b I am trying to use a simple script that will display an jpeg or png image using GD.pm (readily available from CPAN) I am getting [Wed Sep 3 10:41:37 2003] [notice] child pid 832 exit signal Segmentation fault (11) This happens only when the script is loaded in mod_perl... In normal perl/apache it works without the segfault Any Ideas as to why? I have traced the segfault down to the line print $img-png(); I have simplified my script to this, and it segfaults on the img-png command #!/usr/bin/perl use strict; use GD; my $img = GD::Image-new(11,12); my $white = $img-colorAllocate(255,255,255); my $black = $img-colorAllocate(0,0,0); $img-rectangle(1,1,4,5,$black); $| = 1; print Content-type: image/png\n\n; my $tmp = $img-png(); print $tmp; exit; -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: mod_perl and GD.pm segfault
Jason wrote: Embedded Perl version v5.8.0 for Apache/1.3.27 (Unix) PHP/4.3.2 mod_perl/1.28 mod_ssl/2.8.14 OpenSSL/0.9.6b I am trying to use a simple script that will display an jpeg or png image using GD.pm (readily available from CPAN) I am getting [Wed Sep 3 10:41:37 2003] [notice] child pid 832 exit signal Segmentation fault (11) This happens only when the script is loaded in mod_perl... In normal perl/apache it works without the segfault Any Ideas as to why? Not before you show us the segfault backtrace, unless someone can reproduce your problem with the sample script. See: http://perl.apache.org/bugs/ __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp2] segfault when connect to database
Danil Pismenny wrote: httpd2 2.0.47, mod_perl 1.99_09 -- httpd does segfault when I try to connect to the database (mysql or interbase). It faults somewhere in libnss_db.so. It works well if I remove libnss_db* from the system. Here is the part of programm stack from core: #0 0x in ?? () #1 0x4075de1e in db_open () from /lib/libnss_db.so.2 #2 0x4075ded0 in internal_setent () from /lib/libnss_db.so.2 #3 0x4075d62e in _nss_db_endservent () from /lib/libnss_db.so.2 #4 0x4075d8c3 in _nss_db_getservbyname_r () from /lib/libnss_db.so.2 #5 0x40358733 in __getservbyname_r (name=0x405a42f7 mysql, proto=0x405a42f3 tcp, resbuf=0x4038bb7c, buffer=0x86a8a70 , buflen=1024, result=0xb148) at ../nss/getXXbyYY_r.c:200 #6 0x403585e1 in getservbyname (name=0x405a42f7 mysql, proto=0x405a42f3 tcp) at ../nss/getXXbyYY.c:145 #7 0x405949fb in mysql_once_init () from /usr/lib/perl5/site_perl/i386-linux/auto/DBD/mysql/mysql.so #8 0x4059711b in mysql_init () from /usr/lib/perl5/site_perl/i386-linux/auto/DBD/mysql/mysql.so #9 0x4058bf4a in mysql_dr_connect () Can you try reproducing the problem with an external program and then mod_cgi? I don't see where mod_perl is involved here. Thanks! __ 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: [mp2] segfault when connect to database
Marc M. Adkins wrote: httpd2 2.0.47, mod_perl 1.99_09 -- httpd does segfault when I try to connect to the database (mysql or interbase). It faults somewhere in libnss_db.so. It works well if I remove libnss_db* from the system. I noticed a while back that when I use PostgreSQL/W2K/2.0.46/mp1.99_10 I get a segfault _when Apache shuts down_. I don't have it compiled such that I can do a backtrace. So it can't be fixed until we can see the backtrace and be able to reproduce it. __ 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
[mp2] segfault when connect to database
httpd2 2.0.47, mod_perl 1.99_09 -- httpd does segfault when I try to connect to the database (mysql or interbase). It faults somewhere in libnss_db.so. It works well if I remove libnss_db* from the system. Here is the part of programm stack from core: #0 0x in ?? () #1 0x4075de1e in db_open () from /lib/libnss_db.so.2 #2 0x4075ded0 in internal_setent () from /lib/libnss_db.so.2 #3 0x4075d62e in _nss_db_endservent () from /lib/libnss_db.so.2 #4 0x4075d8c3 in _nss_db_getservbyname_r () from /lib/libnss_db.so.2 #5 0x40358733 in __getservbyname_r (name=0x405a42f7 mysql, proto=0x405a42f3 tcp, resbuf=0x4038bb7c, buffer=0x86a8a70 , buflen=1024, result=0xb148) at ../nss/getXXbyYY_r.c:200 #6 0x403585e1 in getservbyname (name=0x405a42f7 mysql, proto=0x405a42f3 tcp) at ../nss/getXXbyYY.c:145 #7 0x405949fb in mysql_once_init () from /usr/lib/perl5/site_perl/i386-linux/auto/DBD/mysql/mysql.so #8 0x4059711b in mysql_init () from /usr/lib/perl5/site_perl/i386-linux/auto/DBD/mysql/mysql.so #9 0x4058bf4a in mysql_dr_connect () -- Danil Pismenny http://www.orionet.ru/
RE: [mp2] segfault when connect to database
httpd2 2.0.47, mod_perl 1.99_09 -- httpd does segfault when I try to connect to the database (mysql or interbase). It faults somewhere in libnss_db.so. It works well if I remove libnss_db* from the system. I noticed a while back that when I use PostgreSQL/W2K/2.0.46/mp1.99_10 I get a segfault _when Apache shuts down_. I don't have it compiled such that I can do a backtrace. mma
Re: modperl segfault with threaded Perl 5.8
Ok, here is a complete backtrace (after a nice couple of hours
observing the compilation progress... :)
Can you please share the details of what you have changed, that
allowed you to get the args and line numbers/file names? Why didn't you
have them in the original report (I want this to be documented).
I did it easily, but I'm not sure, it is a way for everyone... I just
built Perl form the source with CFLAGS='-O0 -g' (-O0 is not necessary, I
guess, it just usually makes debugger more precise on line tracking).
What I exactly did was:
sh Configure -des -Dprefix='/home/pavel/perl-5.8' -Duseshrplib
-Doptimize='-O0 -g' -Uinstallusrbinperl -Dusethreads
I compiled mod_perl for debugging too:
env CFLAGS='-O0 -g' perl Makefile.PL
I'm telling it just to be complete, but having more perl installations
and calling the appropriate perl executable to generate mod_perl
Makefile puts everything nicely together in right directory structures.
#0 0x4003e32d in Perl_gv_fetchpv (my_perl=0x0,
nambeg=0x80c68a7 Apache::Server::AutoPreLoad, add=0, sv_type=4)
at gv.c:646
#1 0x4003726b in Perl_get_sv (my_perl=0x0,
name=0x80c68a7 Apache::Server::AutoPreLoad, create=0) at
perl.c:1712
#2 0x08058c40 in mp_preload_module (name=0xbfff93e8) at
perl_config.c:428
The key here is my_perl=0x0, an attempt to call into perl was made
before it was started. Since you didn't provide the details requested
at:
http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems
(in particular build arguments) I'm doing a wild guesswork, assuming
that you have built without PERL_STACKED_HANDLERS=1 (or
EVERYTHING=1). So if my guess was correct, does the following patch
fixes the problem with the threaded perl?
Mea culpa, but I didn't tell you, bacause I did nothing particular - no
swithes to Makefile.PL at all, so your wild guess was correct. Sorry for
this omission.
... and the good message at last.. your patch works great. Thank you
very much!
Have you got a clue, when (and whether) some maintenance release will go
out? Meanwhile I'll prefer the workaround and I'll build modperl with
stacked handlers. May it have some impact to the performance? (...ok not
so critical for me, indeed).
Many thanks, and thaks for modperl.
Pavel
Index: src/modules/perl/perl_config.c
===
RCS file: /home/cvs/modperl/src/modules/perl/perl_config.c,v
retrieving revision 1.114
diff -u -r1.114 perl_config.c
--- src/modules/perl/perl_config.c 24 Mar 2002 22:51:04 -
1.114
+++ src/modules/perl/perl_config.c 18 Feb 2003 03:20:52 -
@@ -466,6 +466,11 @@
#else
#define PERL_CMD_PUSH_HANDLERS(hook, cmd) \
+if(!PERL_RUNNING()) { \
+perl_startup(parms-server, parms-pool); \
+require_Apache(parms-server); \
+MP_TRACE_g(fprintf(stderr, mod_perl: calling perl_startup()\n)); \
+} \
mp_preload_module(arg); \
cmd = arg; \
return NULL
__
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
--
Pavel Hlavnicka
Ginger Alliance
www.gingerall.com
Re: modperl segfault with threaded Perl 5.8
Pavel Hlavnicka wrote: Ok, here is a complete backtrace (after a nice couple of hours observing the compilation progress... :) Can you please share the details of what you have changed, that allowed you to get the args and line numbers/file names? Why didn't you have them in the original report (I want this to be documented). I did it easily, but I'm not sure, it is a way for everyone... I just built Perl form the source with CFLAGS='-O0 -g' (-O0 is not necessary, I guess, it just usually makes debugger more precise on line tracking). What I exactly did was: sh Configure -des -Dprefix='/home/pavel/perl-5.8' -Duseshrplib -Doptimize='-O0 -g' -Uinstallusrbinperl -Dusethreads I compiled mod_perl for debugging too: env CFLAGS='-O0 -g' perl Makefile.PL I'm telling it just to be complete, but having more perl installations and calling the appropriate perl executable to generate mod_perl Makefile puts everything nicely together in right directory structures. Thanks Pavel, I was always building with -g, that's why my args were always complete. I suppose different levels of -O[0..3] strip different amount of information. At least on my system (linux/gcc3.2) providing -g is enough (as it sets -O0). #0 0x4003e32d in Perl_gv_fetchpv (my_perl=0x0, nambeg=0x80c68a7 Apache::Server::AutoPreLoad, add=0, sv_type=4) at gv.c:646 #1 0x4003726b in Perl_get_sv (my_perl=0x0, name=0x80c68a7 Apache::Server::AutoPreLoad, create=0) at perl.c:1712 #2 0x08058c40 in mp_preload_module (name=0xbfff93e8) at perl_config.c:428 The key here is my_perl=0x0, an attempt to call into perl was made before it was started. Since you didn't provide the details requested at: http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems (in particular build arguments) I'm doing a wild guesswork, assuming that you have built without PERL_STACKED_HANDLERS=1 (or EVERYTHING=1). So if my guess was correct, does the following patch fixes the problem with the threaded perl? Mea culpa, but I didn't tell you, bacause I did nothing particular - no swithes to Makefile.PL at all, so your wild guess was correct. Sorry for this omission. ... and the good message at last.. your patch works great. Thank you very much! Great, I'll commit a proper patch. (the one I've posted was duplicating a chunk of code) Have you got a clue, when (and whether) some maintenance release will go out? I don't know. But probably not very soon. Meanwhile I'll prefer the workaround and I'll build modperl with stacked handlers. May it have some impact to the performance? (...ok not so critical for me, indeed). I doubt so, you should be fine with stacked handlers. If performance is critical and you don't need the threads functionality, you are better off with non-threaded perl. Many thanks, and thaks for modperl. ;) __ 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: modperl segfault with threaded Perl 5.8
Ok, here is a complete backtrace (after a nice couple of hours observing
the compilation progress... :)
#0 0x4003e32d in Perl_gv_fetchpv (my_perl=0x0,
nambeg=0x80c68a7 Apache::Server::AutoPreLoad, add=0, sv_type=4)
at gv.c:646
#1 0x4003726b in Perl_get_sv (my_perl=0x0,
name=0x80c68a7 Apache::Server::AutoPreLoad, create=0) at perl.c:1712
#2 0x08058c40 in mp_preload_module (name=0xbfff93e8) at perl_config.c:428
#3 0x08058efa in perl_cmd_handler_handlers (parms=0xb7a0,
rec=0x80f468c,
arg=0x80f4834 Apache::Registry) at perl_config.c:554
#4 0x0809c649 in invoke_cmd (cmd=0x80db2a0, parms=0xb7a0,
mconfig=0x80f468c, args=0xbfff94cc ) at http_config.c:918
#5 0x0809ca4f in ap_handle_command (parms=0xb7a0, config=0x80f4364,
l=0xbfff94b0 PerlHandler Apache::Registry) at http_config.c:1030
#6 0x0809cad6 in ap_srm_command_loop (parms=0xb7a0, config=0x80f4364)
at http_config.c:1044
#7 0x080a02bc in urlsection (cmd=0xb7a0, dummy=0x80f3a14,
arg=0xbfffb5ef ) at http_core.c:1655
#8 0x0809c003 in invoke_cmd (cmd=0x80d3250, parms=0xb7a0,
mconfig=0x80f3a14, args=0xbfffb5ea /perl) at http_config.c:810
#9 0x0809ca4f in ap_handle_command (parms=0xb7a0, config=0x80f3894,
l=0xbfffb5e0 Location /perl) at http_config.c:1030
#10 0x0809cad6 in ap_srm_command_loop (parms=0xb7a0, config=0x80f3894)
at http_config.c:1044
#11 0x080a0ac7 in virtualhost_section (cmd=0xb7a0, dummy=0x80e6d7c,
arg=0xbfffd70d 212.24.153.10) at http_core.c:1913
#12 0x0809c003 in invoke_cmd (cmd=0x80d3280, parms=0xb7a0,
mconfig=0x80e6d7c, args=0xbfffd70d 212.24.153.10) at
http_config.c:810
#13 0x0809ca4f in ap_handle_command (parms=0xb7a0, config=0x80e61ec,
l=0xbfffd700 VirtualHost 212.24.153.10) at http_config.c:1030
#14 0x0809cad6 in ap_srm_command_loop (parms=0xb7a0, config=0x80e61ec)
at http_config.c:1044
#15 0x0809d265 in ap_process_resource_config (s=0x80e57a4,
fname=0x80e6e14 /usr/local/apache/conf/httpd.conf, p=0x80e577c,
ptemp=0x80e979c) at http_config.c:1332
#16 0x0809db43 in ap_read_config (p=0x80e577c, ptemp=0x80e979c,
confname=0x80ddf20 conf/httpd.conf) at http_config.c:1616
#17 0x080a8280 in main (argc=2, argv=0xb8e4) at http_main.c:5433
#18 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6
The line in the Perl_gv_fetchpv is as follows:
for (namend = name; *namend; namend++) {
if ((*namend == ':' namend[1] == ':')
|| (*namend == '\'' namend[1]))
{
if (!stash)
stash = PL_defstash; /* --- THIS ONE
if (!stash || !SvREFCNT(stash))
return Nullgv;
stash is NULL, what the hell is the chance the PL_defstash macro makes
the trouble?
Have you got some clue?
Anyway, I'll continue my investigations.
Thank in advance
Pavel
Stas Bekman wrote:
Pavel Hlavnicka wrote:
Hi all,
recently I upgraded to RH 8.0 with threaded Perl 5.8. I compiled
Apache 1.3.27 with mod_perl 1.27 from source.
Now if I run Apache is works until I configure some location with
mod_perl and PerlHandler like this:
Location /perl
SetHandler perl-script
PerlHandler Apache::Registry
Options ExecCGI
allow from all
/Location
If PerlHandler line is commented out, the server starts fine.
--
Pavel Hlavnicka
Ginger Alliance
www.gingerall.com
Re: modperl segfault with threaded Perl 5.8
One more info (seems be useful) if I build NON-threaded version of Perl, all seems be ok (at least, there is no crash during the startup. Threaded version of perl crashes regardless on the compiler optimization level (just if you wanted to know) Is it possible we have found a bug in Perl? Pavel Stas Bekman wrote: Pavel Hlavnicka wrote: Hi all, recently I upgraded to RH 8.0 with threaded Perl 5.8. I compiled Apache 1.3.27 with mod_perl 1.27 from source. Now if I run Apache is works until I configure some location with mod_perl and PerlHandler like this: Location /perl SetHandler perl-script PerlHandler Apache::Registry Options ExecCGI allow from all /Location If PerlHandler line is commented out, the server starts fine. Here is the backtrace of 'httpd -X' #0 0x4003cfa0 in Perl_gv_fetchpv () from /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/libperl.so #1 0x40035635 in Perl_get_sv () from /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/libperl.so #2 0x08056b78 in mp_preload_module () #3 0x08056e32 in perl_cmd_handler_handlers () #4 0x08078a35 in invoke_cmd () #5 0x08078e3b in ap_handle_command () #6 0x08078ec2 in ap_srm_command_loop () #7 0x0807c6a8 in urlsection () #8 0x080783ef in invoke_cmd () #9 0x08078e3b in ap_handle_command () #10 0x08078ec2 in ap_srm_command_loop () #11 0x0807ceb3 in virtualhost_section () #12 0x080783ef in invoke_cmd () #13 0x08078e3b in ap_handle_command () #14 0x08078ec2 in ap_srm_command_loop () #15 0x08079651 in ap_process_resource_config () #16 0x08079f2f in ap_read_config () #17 0x0808466c in main () #18 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6 Has anyone seen it before? and... here is what my perl says: This is perl, v5.8.0 built for i386-linux-thread-multi Many thanks in advance, and sorry if I overlooked something basic. Your trace is not as useful as it could be, because it neither shows the arguments nor the line numbers in the source code. I suggest to debug it with gdb, set breakpoint in perl_cmd_handler_handlers and step through to see what's wrong. If you don't know how to debug see: http://perl.apache.org/docs/1.0/guide/debug.html#Debugging_when_Server_Crashes_on_Startup_before_Writing_to_Log_File_ and previous sections as well, though you don't need Apache::DB since the problem doesn't happen during the request. p.s. What app did you get this trace with? It'd be helpful to update the bug reporting section to explain how to get a more useful trace. The one that includes symbols, arguments and line numbers. __ 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 -- Pavel Hlavnicka Ginger Alliance www.gingerall.com
Re: modperl segfault with threaded Perl 5.8
Pavel Hlavnicka wrote:
Ok, here is a complete backtrace (after a nice couple of hours observing
the compilation progress... :)
Can you please share the details of what you have changed, that allowed you to
get the args and line numbers/file names? Why didn't you have them in the
original report (I want this to be documented).
#0 0x4003e32d in Perl_gv_fetchpv (my_perl=0x0,
nambeg=0x80c68a7 Apache::Server::AutoPreLoad, add=0, sv_type=4)
at gv.c:646
#1 0x4003726b in Perl_get_sv (my_perl=0x0,
name=0x80c68a7 Apache::Server::AutoPreLoad, create=0) at perl.c:1712
#2 0x08058c40 in mp_preload_module (name=0xbfff93e8) at perl_config.c:428
The key here is my_perl=0x0, an attempt to call into perl was made
before it was started. Since you didn't provide the details requested
at:
http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems
(in particular build arguments) I'm doing a wild guesswork, assuming
that you have built without PERL_STACKED_HANDLERS=1 (or
EVERYTHING=1). So if my guess was correct, does the following patch
fixes the problem with the threaded perl?
Index: src/modules/perl/perl_config.c
===
RCS file: /home/cvs/modperl/src/modules/perl/perl_config.c,v
retrieving revision 1.114
diff -u -r1.114 perl_config.c
--- src/modules/perl/perl_config.c 24 Mar 2002 22:51:04 - 1.114
+++ src/modules/perl/perl_config.c 18 Feb 2003 03:20:52 -
@@ -466,6 +466,11 @@
#else
#define PERL_CMD_PUSH_HANDLERS(hook, cmd) \
+if(!PERL_RUNNING()) { \
+perl_startup(parms-server, parms-pool); \
+require_Apache(parms-server); \
+MP_TRACE_g(fprintf(stderr, mod_perl: calling perl_startup()\n)); \
+} \
mp_preload_module(arg); \
cmd = arg; \
return NULL
__
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: modperl segfault with threaded Perl 5.8
Actually, I've used gdb to produce the stack trace. Although it seems, that installed version of libperl.so is not stripped, the output was as you could see it. I'll try to investigate a bit more and let you know. Thanks so far. Pavel Stas Bekman wrote: Pavel Hlavnicka wrote: Hi all, recently I upgraded to RH 8.0 with threaded Perl 5.8. I compiled Apache 1.3.27 with mod_perl 1.27 from source. Now if I run Apache is works until I configure some location with mod_perl and PerlHandler like this: Location /perl SetHandler perl-script PerlHandler Apache::Registry Options ExecCGI allow from all /Location If PerlHandler line is commented out, the server starts fine. Here is the backtrace of 'httpd -X' #0 0x4003cfa0 in Perl_gv_fetchpv () from /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/libperl.so #1 0x40035635 in Perl_get_sv () from /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/libperl.so #2 0x08056b78 in mp_preload_module () #3 0x08056e32 in perl_cmd_handler_handlers () #4 0x08078a35 in invoke_cmd () #5 0x08078e3b in ap_handle_command () #6 0x08078ec2 in ap_srm_command_loop () #7 0x0807c6a8 in urlsection () #8 0x080783ef in invoke_cmd () #9 0x08078e3b in ap_handle_command () #10 0x08078ec2 in ap_srm_command_loop () #11 0x0807ceb3 in virtualhost_section () #12 0x080783ef in invoke_cmd () #13 0x08078e3b in ap_handle_command () #14 0x08078ec2 in ap_srm_command_loop () #15 0x08079651 in ap_process_resource_config () #16 0x08079f2f in ap_read_config () #17 0x0808466c in main () #18 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6 Has anyone seen it before? and... here is what my perl says: This is perl, v5.8.0 built for i386-linux-thread-multi Many thanks in advance, and sorry if I overlooked something basic. Your trace is not as useful as it could be, because it neither shows the arguments nor the line numbers in the source code. I suggest to debug it with gdb, set breakpoint in perl_cmd_handler_handlers and step through to see what's wrong. If you don't know how to debug see: http://perl.apache.org/docs/1.0/guide/debug.html#Debugging_when_Server_Crashes_on_Startup_before_Writing_to_Log_File_ and previous sections as well, though you don't need Apache::DB since the problem doesn't happen during the request. p.s. What app did you get this trace with? It'd be helpful to update the bug reporting section to explain how to get a more useful trace. The one that includes symbols, arguments and line numbers. __ 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 -- Pavel Hlavnicka Ginger Alliance www.gingerall.com
modperl segfault with threaded Perl 5.8
Hi all, recently I upgraded to RH 8.0 with threaded Perl 5.8. I compiled Apache 1.3.27 with mod_perl 1.27 from source. Now if I run Apache is works until I configure some location with mod_perl and PerlHandler like this: Location /perl SetHandler perl-script PerlHandler Apache::Registry Options ExecCGI allow from all /Location If PerlHandler line is commented out, the server starts fine. Here is the backtrace of 'httpd -X' #0 0x4003cfa0 in Perl_gv_fetchpv () from /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/libperl.so #1 0x40035635 in Perl_get_sv () from /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/libperl.so #2 0x08056b78 in mp_preload_module () #3 0x08056e32 in perl_cmd_handler_handlers () #4 0x08078a35 in invoke_cmd () #5 0x08078e3b in ap_handle_command () #6 0x08078ec2 in ap_srm_command_loop () #7 0x0807c6a8 in urlsection () #8 0x080783ef in invoke_cmd () #9 0x08078e3b in ap_handle_command () #10 0x08078ec2 in ap_srm_command_loop () #11 0x0807ceb3 in virtualhost_section () #12 0x080783ef in invoke_cmd () #13 0x08078e3b in ap_handle_command () #14 0x08078ec2 in ap_srm_command_loop () #15 0x08079651 in ap_process_resource_config () #16 0x08079f2f in ap_read_config () #17 0x0808466c in main () #18 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6 Has anyone seen it before? and... here is what my perl says: This is perl, v5.8.0 built for i386-linux-thread-multi Many thanks in advance, and sorry if I overlooked something basic. Pavel -- Pavel Hlavnicka Ginger Alliance www.gingerall.com
Re: modperl segfault with threaded Perl 5.8
Pavel Hlavnicka wrote: Hi all, recently I upgraded to RH 8.0 with threaded Perl 5.8. I compiled Apache 1.3.27 with mod_perl 1.27 from source. Now if I run Apache is works until I configure some location with mod_perl and PerlHandler like this: Location /perl SetHandler perl-script PerlHandler Apache::Registry Options ExecCGI allow from all /Location If PerlHandler line is commented out, the server starts fine. Here is the backtrace of 'httpd -X' #0 0x4003cfa0 in Perl_gv_fetchpv () from /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/libperl.so #1 0x40035635 in Perl_get_sv () from /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/libperl.so #2 0x08056b78 in mp_preload_module () #3 0x08056e32 in perl_cmd_handler_handlers () #4 0x08078a35 in invoke_cmd () #5 0x08078e3b in ap_handle_command () #6 0x08078ec2 in ap_srm_command_loop () #7 0x0807c6a8 in urlsection () #8 0x080783ef in invoke_cmd () #9 0x08078e3b in ap_handle_command () #10 0x08078ec2 in ap_srm_command_loop () #11 0x0807ceb3 in virtualhost_section () #12 0x080783ef in invoke_cmd () #13 0x08078e3b in ap_handle_command () #14 0x08078ec2 in ap_srm_command_loop () #15 0x08079651 in ap_process_resource_config () #16 0x08079f2f in ap_read_config () #17 0x0808466c in main () #18 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6 Has anyone seen it before? and... here is what my perl says: This is perl, v5.8.0 built for i386-linux-thread-multi Many thanks in advance, and sorry if I overlooked something basic. Your trace is not as useful as it could be, because it neither shows the arguments nor the line numbers in the source code. I suggest to debug it with gdb, set breakpoint in perl_cmd_handler_handlers and step through to see what's wrong. If you don't know how to debug see: http://perl.apache.org/docs/1.0/guide/debug.html#Debugging_when_Server_Crashes_on_Startup_before_Writing_to_Log_File_ and previous sections as well, though you don't need Apache::DB since the problem doesn't happen during the request. p.s. What app did you get this trace with? It'd be helpful to update the bug reporting section to explain how to get a more useful trace. The one that includes symbols, arguments and line numbers. __ 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: mod_perl 2.0 and print/send_http_header method SEGFAULT
On Thu, Jan 16, 2003 at 10:27:38AM +1100, Stas Bekman wrote:
Cool. Now can you please send the shortest possible example that you still
get the SEGFAULT with, so I can reproduce it and fix? Thanks.
I finally got a working apache2+mod_perl working in my $HOME dir (I
could not find the core files of the RedHat httpd, problems with uid
permission i guess)
So here are the backtraces.
I included two backtraces :
- the first one is for the crash with $r-send_http_header()
- the second one is for the crash with $r-print() when I remove the
send_http_header() statement
The config in httpd.conf :
# mod_perl
LoadModule perl_module modules/mod_perl.so
PerlModule Apache2
PerlTransHandler Apache::SegFault
# proxy
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_ftp_module modules/mod_proxy_ftp.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so
ProxyRequests On
Proxy *
Order deny,allow
Deny from all
Allow from localhost
/Proxy
Then I issue a simple request with :
echo -ne GET http://perl.apache.org HTTP/1.0\n\n | nc localhost 8081
-8-- Start Bug Report 8--
1. Problem Description:
BEGIN
package Apache::SegFault;
use strict;
use Apache::compat;
use Apache::RequestRec;
use Apache::RequestIO;
use Apache::RequestUtil;
use Apache::Const;
use Apache::ServerUtil;
use Apache::Response;
use Apache::URI;
use APR::Table;
sub handler {
my $r = shift;
return Apache::DECLINED unless( $r-proxyreq );
print STDERR Good, this is a proxyreq ...\n;
return Apache::DECLINED unless( $r-method eq GET );
print STDERR Good, this is a GET method ...\n;
my $content = htmlbodyplop/body/html;
my %headers_out;
$headers_out{ 'Content-length' } = length( $content );
$headers_out{ 'Content-type' } = 'text/html';
foreach (keys %headers_out) {
$r-headers_out-{$_} = $headers_out{$_};
}
$r-content_type( $headers_out{ 'Content-type' } );
print STDERR -- send/print --\n;
# -- SEGFAULT here
$r-send_http_header();
# -- or here, when removing the send_http_header() line above
$r-print( $content );
print STDERR -- end --\n;
return Apache::OK;
}
1;
END
2. Used Components and their Configuration:
*** using lib/Apache/BuildConfig.pm
*** Makefile.PL options:
MP_APXS= /home/jauge/httpd/bin/apxs
MP_DEBUG = 1
MP_GENERATE_XS = 1
MP_LIBNAME = mod_perl
MP_MAINTAINER = 1
MP_TRACE = 1
MP_USE_DSO = 1
MP_USE_STATIC = 1
*** /home/jauge/httpd/bin/httpd -V
Server version: Apache/2.0.43
Server built: Jan 16 2003 15:38:17
Server's Module Magic Number: 20020903:0
Architecture: 32-bit
Server compiled with
-D APACHE_MPM_DIR=server/mpm/prefork
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D HTTPD_ROOT=/home/jauge/httpd
-D SUEXEC_BIN=/home/jauge/httpd/bin/suexec
-D DEFAULT_PIDLOG=logs/httpd.pid
-D DEFAULT_SCOREBOARD=logs/apache_runtime_status
-D DEFAULT_LOCKFILE=logs/accept.lock
-D DEFAULT_ERRORLOG=logs/error_log
-D AP_TYPES_CONFIG_FILE=conf/mime.types
-D SERVER_CONFIG_FILE=conf/httpd.conf
*** /usr/bin/perl -V
Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
Platform:
osname=linux, osvers=2.4.18-11smp, archname=i386-linux-thread-multi
uname='linux daffy.perf.redhat.com 2.4.18-11smp #1 smp thu aug 15 06:41:59 edt
2002 i686 i686 i386 gnulinux '
config_args='-des -Doptimize=-O2 -march=i386 -mcpu=i686 -Dmyhostname=localhost
-Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dinstallprefix=/usr
-Dprefix=/usr -Darchname=i386-linux -Dvendorprefix=/usr -Dsiteprefix=/usr -Duseshrplib
-Dusethreads -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm
-Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl
-Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
optimize='-O2 -march=i386 -mcpu=i686',
cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -I/usr/include/gdbm'
ccversion='', gccversion='3.2 20020822 (Red Hat Linux Rawhide 3.2-5)',
gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong
Re: mod_perl 2.0 and print/send_http_header method SEGFAULT
Jérôme Augé wrote: On Thu, Jan 16, 2003 at 10:27:38AM +1100, Stas Bekman wrote: Cool. Now can you please send the shortest possible example that you still get the SEGFAULT with, so I can reproduce it and fix? Thanks. I finally got a working apache2+mod_perl working in my $HOME dir (I could not find the core files of the RedHat httpd, problems with uid permission i guess) So here are the backtraces. I included two backtraces : - the first one is for the crash with $r-send_http_header() - the second one is for the crash with $r-print() when I remove the send_http_header() statement The problem is that you were calling these functions before the response phase (PerlTransHandler in your case), hence triggered the segfaults. I've fixed those in cvs. Now if you call any of these functions too early mod_perl will croak. Please verify with the latest cvs. To solve your particular case, you need to use: $r-set_handlers(PerlResponseHandler = \response); inside the PerlTransHandler handler, and move all the code that generates the response there. __ 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: mod_perl 2.0 and print/send_http_header method SEGFAULT
On Wed, Jan 15, 2003 at 09:09:37AM +1100, Stas Bekman wrote: I've applied a fix that hopefully cures this thing in cvs. Please try again with the latest cvs version. http://perl.apache.org/download/source.html#2_0_Development_Source_Distribution I installed the CVS version (1.9909) and I still get a SEGFAULT when using $r-send_http_header() or $r-print() ... - I fetched the mod_perl CVS sources then launched : $ perl Makefile.PL MP_APXS=/usr/sbin/apxs $ make $ make install - modified the /etc/httpd/conf.d/perl.conf file - restarted httpd I also tested with the Apache::ProxyPassThru module (from http://perl.apache.org/dist/contrib/ProxyPassThru.pm) I added a use Apache::compat statement, removed the $r-handler()/$r-push_handlers() part and I also get a SEGFAULT when it reach the http_send_header() statement ... --
Re: mod_perl 2.0 and print/send_http_header method SEGFAULT
I grep'ed into the mod_perl sources and found in
examples/lib/Apache/HelloWorld.pm that send_http_header does not exists
in mod_perl 2.0 and print is not yet implemented. Is this right ? so
this could easily explain my problems :)
in examples/lib/Apache/HelloWorld.pm :
[...]
sub handler {
my $r = shift;
$r-content_type('text/plain');
#send_http_header API function does not exist in 2.0
$r-puts(__PACKAGE__); #print not yet implemented
return Apache::OK;
}
[...]
--
Re: mod_perl 2.0 and print/send_http_header method SEGFAULT
Jérôme Augé wrote:
On Wed, Jan 15, 2003 at 09:09:37AM +1100, Stas Bekman wrote:
I've applied a fix that hopefully cures this thing in cvs. Please try
again with the latest cvs version.
http://perl.apache.org/download/source.html#2_0_Development_Source_Distribution
Since you've never sent the backtrace of SEGFAULT, as explained here:
http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems
there can be more than one problem. I've fixed one, but there can be more
lurking behind the first one. So if you can send the backtrace, that will
help a lot.
I installed the CVS version (1.9909) and I still get a SEGFAULT when
using $r-send_http_header() or $r-print() ...
- I fetched the mod_perl CVS sources then launched :
$ perl Makefile.PL MP_APXS=/usr/sbin/apxs
$ make
$ make install
- modified the /etc/httpd/conf.d/perl.conf file
- restarted httpd
Cool. Now can you please send the shortest possible example that you still
get the SEGFAULT with, so I can reproduce it and fix? Thanks.
I also tested with the Apache::ProxyPassThru module (from
http://perl.apache.org/dist/contrib/ProxyPassThru.pm)
I added a use Apache::compat statement, removed the
$r-handler()/$r-push_handlers() part and I also get a SEGFAULT when it
reach the http_send_header() statement ...
send_http_header is indeed doesn't exist in 2.0, but implemented in
Apache::compat and should work just fine, as it's exercised in many tests:
grep -Ir send_http_header t
t/compat/request_body.t:# $r-send_http_header('text/plain');
t/compat/request_body.t:q{$r-send_http_header('text/plain')}
t/response/TestCompat/request_body.pm:$r-send_http_header('text/plain');
t/response/TestCompat/apache.pm:$r-send_http_header('text/plain');
t/response/TestCompat/apache_file.pm:$r-send_http_header('text/plain');
t/response/TestCompat/apache_table.pm:$r-send_http_header('text/plain');
t/response/TestCompat/apache_util.pm:$r-send_http_header('text/plain');
t/response/TestCompat/request.pm:$r-send_http_header('text/plain');
__
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: mod_perl 2.0 and print/send_http_header method SEGFAULT
Jérôme Augé wrote:
I grep'ed into the mod_perl sources and found in
examples/lib/Apache/HelloWorld.pm that send_http_header does not exists
in mod_perl 2.0 and print is not yet implemented. Is this right ? so
this could easily explain my problems :)
It's an old example, I've removed it.
in examples/lib/Apache/HelloWorld.pm :
[...]
sub handler {
my $r = shift;
$r-content_type('text/plain');
#send_http_header API function does not exist in 2.0
$r-puts(__PACKAGE__); #print not yet implemented
return Apache::OK;
}
[...]
--
__
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: mod_perl 2.0 and print/send_http_header method SEGFAULT
On Tue, Jan 14, 2003 at 12:32:29PM +1100, Stas Bekman wrote:
Location /plop/
SetHandler perl-script
PerlHeaderParserHandler Apache::Plop
/Location
Well, this is not really what I want to do ...
I would like to catch all the proxy request and apply modifications to
the requested document before forwarding the answer back to the client.
That's why I used the PerlTransHandler which is global and not tied
to a particular directory.
Now to your code:
1. You can't push_handlers when you are inside a response handler.
Use PerlHeaderParserHandler instead
2. $r-headers_in-do() expects a return value and will abort on 0; see
the attached code
also it should be:
$request-header( $_[0] = $_[1] );
instead of:
$request-header( {$_[0]} = $_[1] );
have you looked at error_log? You'd have seen that error reported.
3. This is not good:
my $request = HTTP::Request-new( $r-method, $r-uri);
since you don't the whole url. Use this instead:
my $request = HTTP::Request-new( $r-method, $r-construct_url);
this requires 'use Apache::URI'
4. Finally I've used a special header: (which can be anything)
$request-header( GetReal = 1 );
to know that now I'm inside the real request.
Thanks for your remarks.
I installed modperl-1.99_08 and I keep getting SEGFAULT with my original
code ... I think I'll try to get it working first on mod_perl 1.x then
get back to modperl 2
--
Re: mod_perl 2.0 and print/send_http_header method SEGFAULT
Jérôme Augé wrote:
Hi,
I'm beginning with mod_perl (mod_perl-1.99_05 + Apache 2.0.40 from
RedHat 8.0) and I want to write a module for rewriting the documents
that passes through the Apache proxy. So, I looked at the
Apache::AdBlocker
(http://perl.apache.org/docs/tutorials/tips/mod_perl_tricks/mod_perl_tricks.html#A_Banner_Ad_Blocker)
module and I'm facing some problems for writing the content of the
documents back to the client.
My main problem is that I get a SEGFAULT when calling the $r-print()
or $r-send_http_header() method.
I get the request, copy the headers from headers_in, make my own
request with LWP, copy the headers to headers_out, then it SEGFAULT
when writing the document ... Are this methods deprecated/not fully
implemented ? what is the correct way to write data to the client ?
The other problem is that if I use the $r-push_handlers(PerlHandler =
\proxy_handler) mechanism, my proxy_handler() function is never
called, so I do the work directly into the handler sub, is this ok ?
I attached my test module below (I register it with a PerlTransHandler
Apache::Plop statement in httpd.conf)
After making your example work, I don't see any segfaults. Please try
again with modperl-1.99_08 which was released a few days ago.
I've attached Plop.pm that apparently works. Hope that this is what you
wanted to accomplish. I've used the following config:
Location /plop/
SetHandler perl-script
PerlHeaderParserHandler Apache::Plop
/Location
Now to your code:
1. You can't push_handlers when you are inside a response handler.
Use PerlHeaderParserHandler instead
2. $r-headers_in-do() expects a return value and will abort on 0; see
the attached code
also it should be:
$request-header( $_[0] = $_[1] );
instead of:
$request-header( {$_[0]} = $_[1] );
have you looked at error_log? You'd have seen that error reported.
3. This is not good:
my $request = HTTP::Request-new( $r-method, $r-uri);
since you don't the whole url. Use this instead:
my $request = HTTP::Request-new( $r-method, $r-construct_url);
this requires 'use Apache::URI'
4. Finally I've used a special header: (which can be anything)
$request-header( GetReal = 1 );
to know that now I'm inside the real request.
Hope that this helps.
Also you might want to use a sub-request rather than a heavy weighted LWP
to accomplish what you do.
__
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
package Apache::Plop;
use strict;
use Apache::RequestRec;
use Apache::RequestIO;
use Apache::RequestUtil;
use Apache::Const;
use Apache::ServerUtil;
use Apache::Response;
use Apache::URI;
use APR::Table;
use LWP::UserAgent;
my $ua = LWP::UserAgent-new();
sub handler {
my $r = shift;
if( $r-proxyreq ) {
return Apache::DECLINED;
}
print STDERR Good, this is a proxyreq ...\n;
$r-handler(perl-script); #ok, let's do it
$r-push_handlers(PerlResponseHandler = \proxy_handler);
return Apache::OK;
}
sub proxy_handler {
my $r = shift;
if( $r-method ne GET ) {
return Apache::DECLINED;
}
print STDERR Good, this is a GET method ...\n;
if ( ($r-headers_in-get('GetReal')||0) == 1) {
$r-content_type('text/plain');
print hey;
return Apache::OK;
}
# prepare the real request
my $request = HTTP::Request-new( $r-method, $r-construct_url);
# copy headers from client request
my %headers_in;
print STDERR -- client headers --\n;
$r-headers_in()-do(
sub {
warn $_[0]: $_[1]\n;
$headers_in{ $_[0] } = $_[1];
$request-header( $_[0] = $_[1] );
return 1;
}
);
print STDERR -- end --\n;
# make the real request myself
$ua-agent( $headers_in{ 'User-Agent' } );
$request-header( GetReal = 1 );
warn $request-as_string;
my $response = $ua-request( $request );
if ( ! $response-is_success() ) {
print STDERR == ERROR ==\n;
return Apache::DECLINED;
}
print STDERR -- server headers --\n;
my %headers_out;
$response-headers()-scan(
sub {
print STDERR $_[0]: $_[1]\n;
$headers_out{$_[0]} = $_[1];
}
);
print STDERR -- end --\n;
# simply override the content
my $content = $response-content;
$content = htmlbodyplop/body/html;
# adjust the headers for the new content
$headers_out{ 'Content-length' } = length( $content );
$headers_out{ 'Content-type' } = 'text/html';
# copy the modified response headers back to Apache
foreach (keys %headers_out) {
$r-headers_out-{$_} = $headers_out
Re: mod_perl 2.0 and print/send_http_header method SEGFAULT
Stas Bekman wrote: Jérôme Augé wrote: [...] After making your example work, I don't see any segfaults. Please try again with modperl-1.99_08 which was released a few days ago. [...] 1. You can't push_handlers when you are inside a response handler. Use PerlHeaderParserHandler instead I've played some more with your original code and did find the segfault you were talking about. Though it happens when you use push_handlers in the same phase to which you push to. Hence I didn't see it in the code that I've fixed. So most likely your _05 version will work just fine with the version that I've posted in my original reply. Meanwhile I'm looking at how it's the best to prevent from the segfault to happen and push_handlers() be used in a wrong place. __ 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
segfault after HTTP_MOVED_* and set_handlers()
Hello,
This is a question about the correct use of set_handlers request
method.
I have some handlers stacked by the first one content handler;
one of them processing the request needs to redirect and then close
the HTTP response with a HTTP_MOVED_PERMANENTLY;
so I thought that the following stacked handlers have to be removed
from the stack with a $r-set_handlers('PerlHandler' = undef) in a way
such:
$r-content_type('text/html') ;
$r-header_out('Location', '/go/there') ;
$r-set_handlers('PerlHandler' = undef) ;
return HTTP_MOVED_PERMANENTLY ;
What I see is a couple of side effects:
- Apache exit correctly, but the following request it serves arises a
segfault at an unpredictable execution point
- Apache faults immediately, child dies
I've traced childs with strace and Apache::DB and using the latter one
childs segfault also trying to print a value from the debugging shell:
DB p $var
So I removed all the undefining calls and everithing returns to work.
Does that mess up the apache child pool used by mod_perl ?
What I'm asking is
a) when is a good idea use set_handlers(PerlHandler = undef)
b) is the segfault I've obtained a bug in mod_perl ?
Thanks,
Stefano di Sandro
Re: segfault after HTTP_MOVED_* and set_handlers()
Stefano wrote:
Hello,
This is a question about the correct use of set_handlers request
method.
I have some handlers stacked by the first one content handler;
one of them processing the request needs to redirect and then close
the HTTP response with a HTTP_MOVED_PERMANENTLY;
so I thought that the following stacked handlers have to be removed
from the stack with a $r-set_handlers('PerlHandler' = undef) in a way
such:
$r-content_type('text/html') ;
$r-header_out('Location', '/go/there') ;
$r-set_handlers('PerlHandler' = undef) ;
you can't currently set_handlers() for the current phase. sorry. there was a patch
floating around to do this, but it was never integrated.
return HTTP_MOVED_PERMANENTLY ;
that should terminate the phase entirely and keep the other handlers from running - no
need to explicitly undef the stack anyway.
HTH
--Geoff
segfault after HTTP_MOVED_* and set_handlers()
Hello,
This is a question about the correct use of set_handlers request
method.
I have some handlers stacked by the first one content handler;
one of them processing the request needs to redirect and then close
the HTTP response with a HTTP_MOVED_PERMANENTLY;
so I thought that the following stacked handlers have to be removed
from the stack with a $r-set_handlers('PerlHandler' = undef) in a way
such:
$r-content_type('text/html') ;
$r-header_out('Location', '/go/there') ;
$r-set_handlers('PerlHandler' = undef) ;
return HTTP_MOVED_PERMANENTLY ;
What I see is a couple of side effects:
- Apache exit correctly, but the following request it serves arises a
segfault at an unpredictable execution point
- Apache faults immediately, child dies
I've traced childs with strace and Apache::DB and using the latter one
childs segfault also trying to print a value from the debugging shell:
DB p $var
So I removed all the undefining calls and everithing returns to work.
Does that mess up the apache child pool used by mod_perl ?
What I'm asking is
a) when is a good idea use set_handlers(PerlHandler = undef)
b) is the segfault I've obtained a bug in mod_perl ?
Thanks,
Stefano di Sandro
segfault after HTTP_MOVED_* and set_handlers()
Hello,
This is a question about the correct use of set_handlers request
method.
I have some handlers stacked by the first one content handler;
one of them processing the request needs to redirect and then close
the HTTP response with a HTTP_MOVED_PERMANENTLY;
so I thought that the following stacked handlers have to be removed
from the stack with a $r-set_handlers('PerlHandler' = undef) in a way
such:
$r-content_type('text/html') ;
$r-header_out('Location', '/go/there') ;
$r-set_handlers('PerlHandler' = undef) ;
return HTTP_MOVED_PERMANENTLY ;
What I see is a couple of side effects:
- Apache exit correctly, but the following request it serves arises a
segfault at an unpredictable execution point
- Apache faults immediately, child dies
I've traced childs with strace and Apache::DB and using the latter one
childs segfault also trying to print a value from the debugging shell:
DB p $var
So I removed all the undefining calls and everithing returns to work.
Does that mess up the apache child pool used by mod_perl ?
What I'm asking is
a) when is a good idea use set_handlers(PerlHandler = undef)
b) is the segfault I've obtained a bug in mod_perl ?
Thanks,
Stefano di Sandro
AB Segfault on mod_perl Handler
List, Does anyone know why apache ab might segfault when accessing one particular mod_perl handler on my site? Is this something I could be doing wrong in my handler (I can't think what.. the page works find in all browsers). Richard.
Re: AB Segfault on mod_perl Handler
Richard Clarke wrote: List, Does anyone know why apache ab might segfault when accessing one particular mod_perl handler on my site? Is this something I could be doing wrong in my handler (I can't think what.. the page works find in all browsers). Richard, this has nothing to do with mod_perl, other than triggering a bug in ab. Which is not a *mod_perl* problem. You want to post a proper bug report including a core stack backtrace to the httpd-dev list. See: http://httpd.apache.org/lists.html#http-dev __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:stas;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
[mp2] segfault deleting ENV variable
The following one line script will cause apache/mod_perl2 to segfault:
delete ::ENV{'PATH'};
I've tried this with both apache-2.0.40/mod_perl-1.99_05/perl-5.8.0 (ie
stock RH8), and apache-2.0.43/mod_perl-1.99_07/perl-5.8.0
A backtrace from the later combination gives:
#0 0x4024b447 in Perl_mg_clear ()
from /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/libperl.so
#1 0x40253989 in Perl_hv_delete_ent ()
from /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/libperl.so
#2 0x4027ff27 in Perl_pp_delete ()
from /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/libperl.so
#3 0x40258059 in Perl_runops_standard ()
from /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/libperl.so
#4 0x40200139 in S_call_body ()
from /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/libperl.so
#5 0x401ffeb6 in Perl_call_sv ()
from /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/libperl.so
#6 0x401c85f2 in modperl_callback ()
from /usr/local/apache2/modules/mod_perl.so
#7 0x401c8abe in modperl_callback_run_handlers ()
from /usr/local/apache2/modules/mod_perl.so
#8 0x401c8d05 in modperl_callback_per_dir ()
from /usr/local/apache2/modules/mod_perl.so
#9 0x401c4a55 in modperl_response_handler_run ()
from /usr/local/apache2/modules/mod_perl.so
#10 0x401c4c75 in modperl_response_handler_cgi ()
from /usr/local/apache2/modules/mod_perl.so
#11 0x0807c4f0 in ap_run_handler (r=0x8160178) at config.c:195
#12 0x0807cad6 in ap_invoke_handler (r=0x8160178) at config.c:401
#13 0x0806afc7 in ap_process_request (r=0x8160178) at http_request.c:288
#14 0x08066be1 in ap_process_http_connection (c=0x815bd10) at
http_core.c:293
#15 0x08086268 in ap_run_process_connection (c=0x815bd10) at
connection.c:85
#16 0x08086555 in ap_process_connection (c=0x815bd10, csd=0x815bc40)
at connection.c:207
#17 0x0807ae0d in child_main (child_num_arg=1651076143) at prefork.c:696
#18 0x0807afd4 in make_child (s=0x80b9358, slot=0) at prefork.c:736
#19 0x0807b041 in startup_children (number_to_start=5) at prefork.c:808
#20 0x0807b7bf in ap_mpm_run (_pconf=0x80ab53c, plog=0x80eed30,
s=0x80b9358)
at prefork.c:1024
#21 0x08080d8e in main (argc=2, argv=0xb924) at main.c:643
#22 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6
I built apache with debug info, but forgot to build mod_perl that way. The
above one liner script should be enough to reproduce this, though.
This happens in PerlRun or Registry mode. It isn't restricted to the PATH
variable; deleting any existing ENV var causes the crash.
Thanks,
Bradley
ap_kill_timeout(0) apache-1.3.26 mod_perl-1.27 caused segfault on HPUX 11?
Hi,
I've been troubleshooting a problem with:
perl-5.6.1 (no-threads)
apache-1.3.26
mod_perl-1.27
HPUX 11
Compiler: cc/ansic (HP92453-01 A.11.01.00 HP C Compiler)
Please let me know if there is additional info that I can provide that
might help tracking down this problem!
Problem:
Apache child process dies with SIGSEGV, error logged in apache's
error_log(Program received signal SIGSEGV, Segmentation fault.):
[Tue Sep 10 03:00:33 2002] [notice] child pid 14985 exit signal
Segmentation fault (11)
This seems to happen with mod_perl at random intervals and the problem
seems to typically come back to SIGALRM handling from what I can tell.
The place that gdb says it blows up is at http_main.c:4302 which says:
ap_kill_timeout(0); /* Cancel any outstanding alarms. */
Here is the stack trace (full):
(gdb) where full
#0 0xe67e0 in child_main (child_num_arg=0) at http_main.c:4302
conn_io = (struct buff_struct *) 0x40070968
r = (struct request_rec *) 0x0
clen = 16
sa_server = {sa_family = 2,
sa_data = \037\232\f\236\215$\000\000\000\000\000\000\000}
sa_client = {sa_family = 2,
sa_data = \320\205\f\236\215$\000\000\000\000\000\000\000}
lr = (struct listen_rec *) 0x0
#1 0xe778c in make_child (s=0x400640b8, slot=0, now=1031620784)
at http_main.c:4765
pid = 0
#2 0xe78b8 in startup_children (number_to_start=1) at
http_main.c:4792
i = 0
now = 1031620784
#3 0xe84d0 in standalone_main (argc=1, argv=0x7f7f03d4) at
http_main.c:5100
remaining_children_to_start = 1
#4 0xe984c in main (argc=1, argv=0x7f7f03d4) at http_main.c:5448
c = -1
sock_in = 0
sock_out = 0
s = 0x7f7f0018 httpd
In the Apache 2.0 porting guide I found this comment:
If the C part of the module in 1.0 includes ap_soft_timeout(),
ap_reset_timeout(), ap_hard_timeout() and ap_kill_timeout() functions
simply remove these in 2.0. There is no replacement for these
functions because Apache 2.0 uses non-blocking I/O. As a side-effect
of this change, Apache 2.0 no longer uses SIGALRM, which has caused
conflicts in mod_perl 1.0.
Does anyone have any ideas?
I'm not aware of that specific problems SIGALRM is known to cause can
anyone elaborate on this? Is there anything I can do to help track
down this problem and possible fix it? I can try to reproduce and
give more details if anyone has a specific request for information
that I have not included, please ask!
Thanks,
Phil
Re: [mp-1.99_05] segfault modperl_pcw.c:52 ap_pcw_walk_files_config dconf-sec_file is NULL
Hi Doug,
You asked:
which one is NULL dconf or dconf-sec_file? if dconf-sec_file
should never be NULL. i'm not sure if it is possible for dconf
itself to be NULL. do you have some example configuration that
causes the problem?
Well, dconf was NOT NULL, but sec_file was NULL:
(gdb) print *dconf
$6 = {d = 0x0, d_components = 0, opts = 31 '\037', opts_add = 0 '\000',
opts_remove = 0 '\000', override = 63 '?', ap_default_type = 0x0,
satisfy = 2, ap_auth_type = 0x0, ap_auth_name = 0x0, ap_requires = 0x0,
response_code_strings = 0x0, hostname_lookups = 0, do_rfc1413 = -2,
content_md5 = -2, use_canonical_name = 3, d_is_fnmatch = 0,
add_default_charset = 2, add_default_charset_name = 0x4000c848 iso-8859-1,
limit_cpu = 0x0, limit_mem = 0x0, limit_req_body = -4294967296,
limit_xml_body = 0, server_signature = 1074161768, loglevel = 0,
sec_file = 0x0, r = 0x0, mime_type = 0x0, handler = 0x0,
output_filters = 0x3 , input_filters = 0x0, accept_path_info = 0,
ct_output_filters = 0x0, etag_bits = 0, etag_add = 2, etag_remove = 0,
enable_mmap = 1073910448}
How did this happen, you ask? I was just running 'make test'...
I've got to say that for some reason I've had nothing but trouble with
HP... is the recommended path to use gcc or to use HP's ansic compiler
or ? I wish I knew...
I've got a custom perl module built on top of a threaded library that
seems to choke under apache 1, mod_perl and it seems to be related to
signals (from my best guesses). I'm out on a mini vacation right now
but I'll provide details next week.
If you have any recommendations for things to try please let me know
I'm willing to try any combination:
* apache 1 or 2
* perl 5.6.1 or 5.8.0
Phil
Stack trace For your reference...
gdb /opt/apache2/2.0.40_debug/bin/httpd -core ... (wd:
~/sw/src/apache/mod_perl-1.99_05)
where
#0 0xda26ffa8 in ap_pcw_walk_files_config (pconf=0x400292b0, s=0x4002c020,
dconf=0x400667f0, modp=0x7f68b7e8,
dir_cb=0x7f685122 modperl_hash_handlers_dir, data=0x0)
at modperl_pcw.c:52
#1 0xda2703ec in ap_pcw_walk_config (pconf=0x400292b0, s=0x4002c020,
modp=0x7f68b7e8, data=0x0, dir_cb=0x7f685122 modperl_hash_handlers_dir,
srv_cb=0x7f68512a modperl_hash_handlers_srv) at modperl_pcw.c:106
#2 0xda26f514 in modperl_mgv_hash_handlers (p=0x400292b0, s=0x4002c020)
at modperl_mgv.c:470
#3 0xda259948 in modperl_hook_post_config (pconf=0x400292b0, plog=0x40061470,
ptemp=0x40063480, s=0x4002c020) at mod_perl.c:415
#4 0x60874 in ap_run_post_config (pconf=0x400292b0, plog=0x40061470,
ptemp=0x40063480, s=0x4002c020) at config.c:130
#5 0x67cd0 in main (argc=6, argv=0x7f7f05a4) at main.c:592
Hi,
I just recently joined the mail list and did a quick check but didn't
seen any report of this problem:
Versions: perl-5.6.1 (non-threaded)
apache-2.0.40(mpm-prefork)
mod_perl-1.99_05
OS: HPUX 11
Compiler: gcc version 3.2 20020708 (experimental)
I don't know the code well enough to know what data/values are
expected to be found in dconf, but here is a possible work around
(most likely less than ideal solution) in the affected portion of C
code (src/modules/perl/modperl_pcw.c):
+if( (! dconf) || (! dconf-sec_file) )
+return;
ap_conf_vector_t **dirs = (ap_conf_vector_t **)dconf-sec_file-elts;
[ ... question/text moved to top ...]
Re: [mp-1.99_05] segfault modperl_pcw.c:52 ap_pcw_walk_files_configdconf-sec_file is NULL
On Tue, 27 Aug 2002, Phil Lobbes wrote: Hi, I just recently joined the mail list and did a quick check but didn't seen any report of this problem: Versions: perl-5.6.1 (non-threaded) apache-2.0.40(mpm-prefork) mod_perl-1.99_05 OS: HPUX 11 Compiler: gcc version 3.2 20020708 (experimental) I don't know the code well enough to know what data/values are expected to be found in dconf, but here is a possible work around (most likely less than ideal solution) in the affected portion of C code (src/modules/perl/modperl_pcw.c): +if( (! dconf) || (! dconf-sec_file) ) +return; ap_conf_vector_t **dirs = (ap_conf_vector_t **)dconf-sec_file-elts; which one is NULL dconf or dconf-sec_file? if dconf-sec_file should never be NULL. i'm not sure if it is possible for dconf itself to be NULL. do you have some example configuration that causes the problem?
[mp-1.99_05] segfault modperl_pcw.c:52 ap_pcw_walk_files_config dconf-sec_file is NULL
Hi,
I just recently joined the mail list and did a quick check but didn't
seen any report of this problem:
Versions: perl-5.6.1 (non-threaded)
apache-2.0.40(mpm-prefork)
mod_perl-1.99_05
OS: HPUX 11
Compiler: gcc version 3.2 20020708 (experimental)
I don't know the code well enough to know what data/values are
expected to be found in dconf, but here is a possible work around
(most likely less than ideal solution) in the affected portion of C
code (src/modules/perl/modperl_pcw.c):
+if( (! dconf) || (! dconf-sec_file) )
+return;
ap_conf_vector_t **dirs = (ap_conf_vector_t **)dconf-sec_file-elts;
However after doing that, I get problems in other places... back to
the drawing board I guess.
For your reference, here is how I built mod_perl:
/opt/perl/bin/perl Makefile.PL MP_INST_APACHE2=1 \
MP_AP_PREFIX=/opt/apache2/2.0.40_debug \
MP_DEBUG=1 MP_TRACE=1
gdb /opt/apache2/2.0.40_debug/bin/httpd -core ... (wd:
~/sw/src/apache/mod_perl-1.99_05)
where
#0 0xda26ffa8 in ap_pcw_walk_files_config (pconf=0x400292b0, s=0x4002c020,
dconf=0x400667f0, modp=0x7f68b7e8,
dir_cb=0x7f685122 modperl_hash_handlers_dir, data=0x0)
at modperl_pcw.c:52
#1 0xda2703ec in ap_pcw_walk_config (pconf=0x400292b0, s=0x4002c020,
modp=0x7f68b7e8, data=0x0, dir_cb=0x7f685122 modperl_hash_handlers_dir,
srv_cb=0x7f68512a modperl_hash_handlers_srv) at modperl_pcw.c:106
#2 0xda26f514 in modperl_mgv_hash_handlers (p=0x400292b0, s=0x4002c020)
at modperl_mgv.c:470
#3 0xda259948 in modperl_hook_post_config (pconf=0x400292b0, plog=0x40061470,
ptemp=0x40063480, s=0x4002c020) at mod_perl.c:415
#4 0x60874 in ap_run_post_config (pconf=0x400292b0, plog=0x40061470,
ptemp=0x40063480, s=0x4002c020) at config.c:130
#5 0x67cd0 in main (argc=6, argv=0x7f7f05a4) at main.c:592
(gdb) print *pconf
$5 = {parent = 0x400272a0, child = 0x400cfcc8, sibling = 0x0,
ref = 0x4005f468, cleanups = 0x400a2578, allocator = 0x400231f0,
subprocesses = 0x0, abort_fn = 0, user_data = 0x0, tag = 0x4000a6b0 pconf,
active = 0x400a1b40, self = 0x40029298,
self_first_avail = 0x400292e8 @\002\222\260}
(gdb) print *dconf
$6 = {d = 0x0, d_components = 0, opts = 31 '\037', opts_add = 0 '\000',
opts_remove = 0 '\000', override = 63 '?', ap_default_type = 0x0,
satisfy = 2, ap_auth_type = 0x0, ap_auth_name = 0x0, ap_requires = 0x0,
response_code_strings = 0x0, hostname_lookups = 0, do_rfc1413 = -2,
content_md5 = -2, use_canonical_name = 3, d_is_fnmatch = 0,
add_default_charset = 2, add_default_charset_name = 0x4000c848 iso-8859-1,
limit_cpu = 0x0, limit_mem = 0x0, limit_req_body = -4294967296,
limit_xml_body = 0, server_signature = 1074161768, loglevel = 0,
sec_file = 0x0, r = 0x0, mime_type = 0x0, handler = 0x0,
output_filters = 0x3 , input_filters = 0x0, accept_path_info = 0,
ct_output_filters = 0x0, etag_bits = 0, etag_add = 2, etag_remove = 0,
enable_mmap = 1073910448}
(gdb)
Perl version info (perl -V):
[apr/include] perk@hpmx5(2203) /opt/perl/bin/perl -V
Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration:
Platform:
osname=hpux, osvers=11.00, archname=PA-RISC2.0
uname='hp-ux hpmx5 b.11.00 a 9000800 1534710528 two-user license '
config_args='-Dcf_by=Openwave [EMAIL PROTECTED] -Dcc=gcc
-Dprefix=/opt/perl -Uusethreads -Ubincompat5005 -Uinstallusrbinperl -Uusemymalloc
-Duselargefiles -A prepend:libswanted=cl pthread $a -A ccflags=-fPIC
-D_POSIX_C_SOURCE=199506L -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Doptimize=-g -de'
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='gcc', ccflags ='-D_HPUX_SOURCE -L/lib/pa1.1 -DUINT32_MAX_BROKEN -fPIC
-D_POSIX_C_SOURCE=199506L -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DDEBUGGING
-fno-strict-aliasing -I/usr/local/include',
optimize='-g',
cppflags='-D_HPUX_SOURCE -L/lib/pa1.1 -DUINT32_MAX_BROKEN -fPIC
-D_POSIX_C_SOURCE=199506L -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DDEBUGGING
-fno-strict-aliasing -I/usr/local/include'
ccversion='', gccversion='3.2 20020708 (experimental)', gccosandvers='hpux11.00'
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='ld', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib /usr/ccs/lib
libs=-lcl -lpthread -lnsl -lnm -lndbm -lmalloc -ldld -lm -lc -lndir -lcrypt -lsec
perllibs=-lcl -lpthread -lnsl -lnm -lmalloc -ldld -lm -lc -lndir -lcrypt -lsec
libc=/lib/libc.sl, so=sl, useshrplib=false, libperl=libperl.a
Dynamic
Re: Fascinating segfault at Apache startup
Come to think of it, this is exactly what I did on my RedHat 7.2 system -- grabbed a Perl 5.6.1 RPM without noticing that it was for RedHat 7.3. It installed fine, and Perl worked okay, so why not? Thanks for straightening this up, Eric -- as Chip said, everything should have worked fine with the Perl RPM if I had done it correctly. Thanks. :) Jeremy Weatherford [EMAIL PROTECTED] http://xidus.net On Fri, 21 Jun 2002, E Kolve wrote: I got this error and spent a bit of time trying to figure it out. The reason I was getting it was that I had started with a RedHat 7.2 system which comes with Perl 5.6.0 and upgraded to 5.6.1 using RH 7.3 RPMS. I then compiled mod_perl against 5.6.1. Each time I started up I got the absurdfork error. I found 5.6.1 RPMS for RH 7.2 and everything worked fine. --eric
Re: Fascinating segfault at Apache startup
Zac Morris [EMAIL PROTECTED] writes:
Honestly though Chip I have to pipe up here.
I was a gung ho RedHat supporter when I first got involved in the
linux world, and I still believe with it's RPMs and GUI tools it's
still the best for both new users and corporate environments, but
man, if you wanna do something that not the EXACT OS version-RPM
based software version, (hmmm, like DEVELOPMENT) you are SERIOUSLY
screwed with RPM more times than not.
It depends. Usually it isn't RPM that is the problem, it's the
-other- software you've installed with RPM. Dependencies tend to be
an all-or-nothing affair, though, which makes the situation more
complicated.
So I have spent the last FIVE full days about 10 hours a day setting
up redhat 7.3 (sans as many of the RPMs as I could possible get away
with). Now granted perl 5.6.1 was one of the RPMs I *did* install,
as was sendmail (since Redhat has REALLY whacked that one up with
the assumed workstation mode, but I at least know how to FIX
that), but my apache, mod_perl, java, tomcat, etc I built entirely
from source utilizing my /opt/{appname} everything all together
strategy.
I now have a pretty swank lil server setup here. I just
successfully tested my perl/DBD::Pg connections and i'll confirm
jdbc to Pg tomorrow and I'll be set for some major develpment
efforts.
I'm not familiar with tomcat, so I can't really comment on it
specifically. But, before I came to Red Hat, I was a compile from
source guy, even on production servers. Lots of reasons, but one was
that I didn't know RPM. It seemed like a hassle to deal with it for
little things, etc... so I didn't.
My personal suggestion would be to try to work with the default OS
instead of against it. Sometimes this is impossible, but sometimes it
isn't so bad. For instance, instead of compiling straight from
source, you could take our RPMs, modify them (such as making apache
live in /opt), maybe throw in a more recent version, and see how it
works. Likewise, building tomcat, java, etc, as RPMs may save you
time later when you need to rebuild a box, or clone the system, or
should disaster strike. Recompiling, checking dependencies by hand,
etc, really is time consuming. But, of course, so is learning RPM :)
It definitely is a difficult road. Having travelled it myself,
though, I find it to be tremendously better than how I used to do
things. It depends on your own personal preferences, though, as well
as company policies, your peers' skillsets, etc. No one answer fits
everything, but I really do think that package management of some kind
(RPMs, debian, etc) offers many superiorities over recompiling from
source. YMMV :) There's no one single answer (too much context), but
in general, whatever OS you use, it usually is easier to work with it
and the tools it provides than against it.
When it comes to perl and mod_perl, we've been working to try to make
sure it works reliably from RPMs. RH 7.3 should work well out of the
box, as should 7.2, once all errata applied. The rest of this thread
points out a few issues, though, but I think that tends to be issues
with other perl modules that have shared library components. If you
(or anyone else!) have specific failures or test cases you've seen,
though, I'll look into it and see if it is something we can fix.
Cheers,
Chip
--
Chip Turner [EMAIL PROTECTED]
Red Hat, Inc.
Re: Fascinating segfault at Apache startup
I got this error and spent a bit of time trying to figure it out. The reason I was getting it was that I had started with a RedHat 7.2 system which comes with Perl 5.6.0 and upgraded to 5.6.1 using RH 7.3 RPMS. I then compiled mod_perl against 5.6.1. Each time I started up I got the absurdfork error. I found 5.6.1 RPMS for RH 7.2 and everything worked fine. --eric Jeremy Weatherford wrote: Hello, I'm trying to build a minimal Apache+mod_perl, sort of a 'Perl-Server', as mentioned in the mod_perl guide. Here's the end result: [root@omics root]# cd /usr/local/apache-perl/bin [root@omics bin]# ./httpd () gets absurdforkSegmentation fault [root@omics bin]# I'll start trying to debug this, but I'm not too confident in my ability to gather any more useful information, so I thought I'd ask if anybody has seen this before. I can't find any references to this message on the web (always scary), but maybe someone knows what's going on here. My configuration so far: perl-5.6.1-34.99.6 RPM from RedHat 7.2 # perl -V Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration: Platform: osname=linux, osvers=2.4.17-0.13smp, archname=i386-linux uname='linux daffy.perf.redhat.com 2.4.17-0.13smp #1 smp fri feb 1 10:30:48 est 2002 i686 unknown ' config_args='-des -Doptimize=-O2 -march=i386 -mcpu=i686 -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dcccdlflags=-fPIC -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux -Dvendorprefix=/usr -Dsiteprefix=/usr -Uusethreads -Uuseithreads -Uuselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Di_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm' 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='gcc', ccflags ='-fno-strict-aliasing -I/usr/local/include', optimize='-O2 -march=i386 -mcpu=i686', cppflags='-fno-strict-aliasing -I/usr/local/include' ccversion='', gccversion='2.96 2731 (Red Hat Linux 7.2 2.96-109)', 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=4 alignbytes=4, usemymalloc=n, prototype=define Linker and Libraries: ld='gcc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -ldl -lm -lc -lcrypt -lutil perllibs=-lnsl -ldl -lm -lc -lcrypt -lutil libc=/lib/libc-2.2.5.so, 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): Compile-time options: Built under linux Compiled at Apr 1 2002 12:23:22 @INC: /usr/lib/perl5/5.6.1/i386-linux /usr/lib/perl5/5.6.1 /usr/lib/perl5/site_perl/5.6.1/i386-linux /usr/lib/perl5/site_perl/5.6.1 /usr/lib/perl5/site_perl/5.6.0/i386-linux /usr/lib/perl5/site_perl/5.6.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.6.1/i386-linux /usr/lib/perl5/vendor_perl/5.6.1 /usr/lib/perl5/vendor_perl . apache-1.3.24, mod_perl-1.27 cd /usr/src/mod_perl-1.27 perl Makefile.PL \ APACHE_SRC=../apache-perl-1.3.24/src \ NO_HTTPD=1 USE_APACI=1 PREP_HTTPD=1 \ EVERYTHING=1 make make install cd ../apache-perl-1.3.24 ./configure --prefix=/usr/local/apache-perl \ --disable-module=autoindex \ --disable-module=imap \ --disable-module=include \ --disable-module=log_config \ --disable-module=alias \ --disable-module=auth \ --disable-module=cgi \ --disable-module=env \ --disable-module=userdir \ --activate-module=src/modules/perl/libperl.a make make install src/httpd -l http_core.c mod_mime.c mod_negotiation.c mod_status.c mod_dir.c mod_asis.c mod_actions.c mod_access.c mod_setenvif.c mod_perl.c Any help would be appreciated... Thanks, Jeremy Weatherford [EMAIL PROTECTED] http://xidus.net
[BUG | ANNOUNCE] Apache::Status segfault | EnglishSave
Trying to use the 'Memory Usage' feature of Apache::Status, I came across the English module. Using it in a mod_perl Module causes Apache::Status to segfault. It turned out, that when omitting some vars, the segfault was gone. So I put up a little changed version of English - EnglishSave. For the more enlightened perl people I also put two strace logs on this page: http://www.virtualitas.net/perl/englishsave/ Please download the module for testing. The ZIP file includes a test module and a raw startup.pl. I don't plan to upload it to CPAN, because the problem might not be in English.pm but in Apache::Status - or in the darkness beclouding my head ;-)) Ernest -- * * VIRTUALITAS Inc. * * ** * * European Consultant Office * http://www.virtualitas.net * * Internationales Handelszentrum * contact:Ernest Lergon * * Friedrichstraße 95 *mailto:[EMAIL PROTECTED] * * 10117 Berlin / Germany * ums:+49180528132130266 * * PGP-Key http://www.virtualitas.net/Ernest_Lergon.asc
Re: Help Requested: Segfault 11 7 MONTHS after compilation on multiple servers all compiled the same running different code and different Redhat Released all on the same day [BUG]
Stas, I'm much closer thanks to your document*. I now at least I feel like I'm moving forward for the first time in months. OK, so I'm pretty sure short of recompiling Perl, that I have all the correct debug things turned on though the user permission problem still plague me a bit. I just chgrp'd the whole dir to httpd and did a chmod g+w -R so I think that should fix any permission problems for a core file to be created. Here's some notes abour your document and the problems I had as I'm pretty sure it's a work in progress. 1st, I had a little trouble following the Bad Segv stuff because I had to install Parser and then Inline. That was no big deal but then your code was written for a much older version of Inline and no longer works, yada, yada, yada. The version of Bad::Segv that I developed VERY quickly to get around this is up at http://www.peregrinehw.com/downloads/apache/mod_perl 2nd, The segv.cgi at the same location as the Bad:Segv above, segfaults on the command line and through normal CGI but not with mod_perl. Here's the error I get trying to run this script with mod_perl (1.26): [Tue Apr 9 09:53:16 2002] [error] [Tue Apr 9 09:53:16 2002] PerlHandler subroutine `Apache::Registry::handler': Undefined subroutine Bad::Segv::segv called at /htdocs/peregrinehw.com/html/segv.cgim line 12. [Tue Apr 9 09:53:16 2002] END block subroutine `Inline::END': One or moreDATA sections were not processed by Inline. [Tue Apr 9 09:53:16 2002] END block subroutine `Inline::END': Thoughts? Something special with mod_perl? I didn't add the Bad::Segv to the startup.pl or anything at all. Regards, Kevin A. McGrail * http://perl.apache.org/preview/modperl-docs/dst_html/docs/2.0/devel/debug_c/ debug_c.html#Getting_the_core_File_Dumped Bad-Segv-0.20.tar.gz Description: GNU Zip compressed data
Re: Help Requested: Segfault 11 7 MONTHS after compilation on multiple servers all compiled the same running different code and different Redhat Released all on the same day [BUG]
Kevin A. McGrail wrote: 2nd, The segv.cgi at the same location as the Bad:Segv above, segfaults on the command line and through normal CGI but not with mod_perl. Here's the error I get trying to run this script with mod_perl (1.26): [Tue Apr 9 09:53:16 2002] [error] [Tue Apr 9 09:53:16 2002] PerlHandler subroutine `Apache::Registry::handler': Undefined subroutine Bad::Segv::segv called at /htdocs/peregrinehw.com/html/segv.cgim line 12. [Tue Apr 9 09:53:16 2002] END block subroutine `Inline::END': One or moreDATA sections were not processed by Inline. [Tue Apr 9 09:53:16 2002] END block subroutine `Inline::END': Thoughts? Something special with mod_perl? I didn't add the Bad::Segv to the startup.pl or anything at all. I haven't been following this thread, but it appears to me from the error message that the DATA section might be causing the problem in conjunction with Apache::Registry, which explicitly states: Your scripts cannot contain the __END__ or __DATA__ token to terminate compilation. in the CAVEATS section. Ignore this if I'm offbase. (darren) -- The knowledge that makes us cherish innocence makes innocence unattainable. -- Irving Howe
Re: Help Requested: Segfault 11 7 MONTHS after compilation on multipleservers all compiled the same running different code and different RedhatReleased all on the same day [BUG]
darren chamberlain wrote: Kevin A. McGrail wrote: 2nd, The segv.cgi at the same location as the Bad:Segv above, segfaults on the command line and through normal CGI but not with mod_perl. Here's the error I get trying to run this script with mod_perl (1.26): [Tue Apr 9 09:53:16 2002] [error] [Tue Apr 9 09:53:16 2002] PerlHandler subroutine `Apache::Registry::handler': Undefined subroutine Bad::Segv::segv called at /htdocs/peregrinehw.com/html/segv.cgim line 12. [Tue Apr 9 09:53:16 2002] END block subroutine `Inline::END': One or moreDATA sections were not processed by Inline. [Tue Apr 9 09:53:16 2002] END block subroutine `Inline::END': Thoughts? Something special with mod_perl? I didn't add the Bad::Segv to the startup.pl or anything at all. I haven't been following this thread, but it appears to me from the error message that the DATA section might be causing the problem in conjunction with Apache::Registry, which explicitly states: Your scripts cannot contain the __END__ or __DATA__ token to terminate compilation. in the CAVEATS section. Ignore this if I'm offbase. it's a perl handler, not a registry script. ignore mode is on :) __ 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: Help Requested: Segfault 11 7 MONTHS after compilation on multipleservers all compiled the same running different code and different RedhatReleased all on the same day [BUG]
On Tue, 9 Apr 2002, Stas Bekman wrote:
Looks like you cannot run the Inline code under mod_perl. I remember
Brian told me the secret code to make it work under mod_perl :)
Ah, this might be it. The first time the Inline code is run the ILSM
(Inline Support Module) compiles[1] the code. It then stashes this away
in the .Inline directory, then reads this 'compiled' code back in again
this, and every other time, it's called. If it can't do that then
this could be a problem.
I'd be tempted to run the code as someone who has rights to write in the
directory for the first time after I'd installed it/made any changes.
Make sure your webserver has permissions to read these files. Don't
change the source file (any part of it, even the perl part) without
rerunning the code as that privileged user (to recompile it.)
[ snip lots of code ]
make sure that /tmp/Inline is writable by the webserver.
Hopefully you will figure out how to fix completely Bad::Segv and I'll
have more time to do other things :) Thanks.
Um...if you do this arn't you essentially creating a directory where you
can store executable code that will be read in by your webserver and run
that can be written to by your webserver? Isn't this a little insecure?
Later.
Mark.
[1] Compiles in the looses sense of the word. Very accurate for C, less
true for other languages.
--
s'' Mark Fowler London.pm Bath.pm
http://www.twoshortplanks.com/ [EMAIL PROTECTED]
';use Term'Cap;$t=Tgetent Term'Cap{};print$t-Tputs(cl);for$w(split/ +/
){for(0..30){$|=print$t-Tgoto(cm,$_,$y). $w;select$k,$k,$k,.03}$y+=2}
Re: Help Requested: Segfault 11 7 *snip*
* Stas Bekman [EMAIL PROTECTED] [2002-04-09 12:14]: darren chamberlain wrote: Kevin A. McGrail wrote: 2nd, The segv.cgi at the same location as the Bad:Segv above, segfaults on the command line and through normal CGI but not with mod_perl. Here's the error I get trying to run this script with mod_perl (1.26): [Tue Apr 9 09:53:16 2002] [error] [Tue Apr 9 09:53:16 2002] PerlHandler subroutine `Apache::Registry::handler': Undefined subroutine ^ [-- snip --] it's a perl handler, not a registry script. I'm just reading the error message, that's all. :) (darren) -- I can't understand why a person will take a year or two to write a novel when he can easily buy one for a few dollars. -- Fred Allen
Help Requested: Segfault 11 7 MONTHS after compilation on multiple servers all compiled the same running different code and different Redhat Released all on the same day [BUG]
Synopsis: My servers, installed per instructions at http://www.peregrinehw.com/downloads/apached/devel, were originally compiled in July of Last year. On February 6th of this year, without warning or change, we began segfault 11'ing for the first time in years on multiple servers with enough differences to rule out code bases or hardware. On Mar 26th, we turned off mod_perl by SIMPLY commenting the Apache::Registry line in httpd.conf and NOT recompiling. Our segfaults stopped. After more research I thought it was a bug, exploit or attack caused by a malicious program or user sending a bizarre string. To test this, I enabled a VERY strict .htaccess on our development site denying access to all but our beta tests. The segfaults stopped even with mod_perl enabled again. Now, more than 2 months later, we are still working on why and how to fix the problem. Through the recommendation of many people at the Apache project and the PHP exploit, we have upgraded to Apache 1.3.23. We are now trying Apache 1.3.24 as of 3PM today. We have tried in vain to get a core file (Compiled with the #WITH DEBUG lines in the instructions above and chmod'd 777 core files in /usr/local/apache. However, the child processes don't actually core dump so their is nothing to trace. If anyone can help me get a core file, I think this would help immensely. So, the best I can do is read and try changes one and a time and I am ready to make this crackpot theory ;-) Code Red II (or a variant thereof) starts at octet 63. My servers are at 66 and it has taken till February to get there. Hence, the delay between the compilation in July and the segfaults in Feb and it explains why my servers are bombing and not hundreds of others on different IP ranges. What's odd is I thought a follow-up request for default.ida was part of Code Red but I'm not seeing those errors, just the malformed host header Anyway, I believe we have now correlated a malformed host entry with our segfaults finally. It takes a while but this is what seems to blow it up. It ONLY happens when Apache::Registry is enabled in the httpd.conf (still compiled in and still loading startup.pl, just no scripts are activating it). [Mon Apr 8 14:04:03 2002] [error] [client 195.210.129.26] Client sent malformed Host header [Mon Apr 8 14:12:51 2002] [notice] child pid 11889 exit signal Segmentation fault (11) [Mon Apr 8 15:04:49 2002] [error] [client 218.76.7.137] Client sent malformed Host header [Mon Apr 8 15:42:52 2002] [notice] child pid 13768 exit signal Segmentation fault (11) As you can see, it takes a while to crash the process but blocking access to the server via .htaccess STOPS the segmentation faults as I mentioned before. I would appreciate any comments of similar experiences or help in regards to making a core file. Regards, KAM
Re: Help Requested: Segfault 11 7 MONTHS after compilation on multipleservers all compiled the same running different code and different RedhatReleased all on the same day [BUG]
Hi there, On Mon, 8 Apr 2002, Kevin A. McGrail wrote: help in regards to making a core file. Check the debug section of the Guide: http://perl.apache.org/guide Also see the file .../mod_perl-x.xx/SUPPORT for advice on what information should be posted with a reort such as yours. 73, Ged. PS: That's a VERY long subject line... :)
Re: Segfault when using LWP
DOH! Nevermind, I figured it out. I didn't run ldconfig after upgrading openssl, so httpd was linked to a different version than the ssl perl modules, which aparently caused the segfaults... Like I said earlier I thought it was a library version mismatch so I recompiled *everything*, but for some reason the perl modules seemed to pick up the new libcrypto without me running ldconfig??. Oh well, thanks anyway. Ryan __ .' Ryan Veety [EMAIL PROTECTED] - http://www.ryanspc.com `. | PGP Key: http://www.ryanspc.com/pgp.txt | `--'
Re: QUESTION: how to debug segfault apache1.3.22/mod_perl1.26/HTML::Mason
Hi there, On Wed, 16 Jan 2002, Chris Hutchinson wrote: I've recently built apache 1.3.22/mod_perl 1.26, statically with perl 5.6.1 on linux RH 7.0. [snip] ccversion='', gccversion='2.96 2731 (Red Hat Linux 7.0)', At the risk of sounding like a broken record, have you tried compiling everyhthing with a different compiler? The one supplied with RH7.0 had some problem (I gather:). On a couple of RH6.2 systems I'm still using 2.91.66 with no problems, in fact I've deliberately avoided upgrading gcc because the docs said it wouldn't compile my kernels any more if I did... 73, Ged.
QUESTION: how to debug segfault apache1.3.22/mod_perl1.26/HTML::Mason
I've recently built apache 1.3.22/mod_perl 1.26, statically with perl
5.6.1 on linux RH 7.0.
Am now getting SIGSEGV at various points in a HTML::Mason web
application. These happen usually, but not always, when making
DBD::Pg fetches (happens both with and without Apache::DBI).
This application was working perfectly under perl5.005,
apache1.3.20/mod_perl 1.24!
Is there any clear way to approach solving this? I've tried tracing
with strace (output attached below), and rebuilding everything again.
Any suggestions gratefully received, as it's getting a bit desperate here!
- Chris
strace output for _one_ of the crashing pages:
22372 brk(0x8957000)= 0x8957000
22372 read(7, , 4096) = 0
22372 read(7, , 4096) = 0
22372 close(7) = 0
22372 munmap(0x40019000, 4096) = 0
22372 stat(/tmp/dms_cache/obj/mc/metaform_submit.mc,
{st_mode=S_IFREG|0644, st_size=8385, ...}) = 0
22372 rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_IGN}, 8) = 0
22372 send(4, Q SELECT Name FROM Species WHERE SpeciesID=2 \0, 46,
0) = 46
22372 rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_IGN}, 8) = 0
22372 select(5, [4], [], [4], NULL) = 1 (in [4])
22372 recv(4, Pblank\0T\0\1name\0\0\0\4\23\377\377\0\0\0$D\200\0\0\0
\17E. GlobulusCSELECT\0Z, 16384, 0) = 51
22372 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
22372 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
22372 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
22372 rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_IGN}, 8) = 0
22372 send(4, Q\n\t\t\t\tSELECT
fieldname,label,valuesource,validsource,controltype,displayorder\n\t\t
\t\tFROM MetaForms,Meta
FormFields\n\t\t\t\tWHERE formname=\'add\' AND
tablename=\'locationrefs\' \n\t\t\t\tAND
metaforms.formid=metaformfields.formid
\n\t\t\t\tORDER BY displayorder ASC \0, 245, 0) = 245
22372 rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_IGN}, 8) = 0
22372 select(5, [4], [], [4], NULL) = 1 (in [4])
22372 recv(4, Pblank\0T\0\6fieldname\0\0\0\4\23\377\377\0\0\0hlabel\0
\0\0\4\23\377\377\0\0\0hvaluesource\0\0\0\0\31\377\377\3
77\377\377\377validsource\0\0\0\0\31\377\377\377\377\377
\377controltype\0\0\0\4\23\377\377\0\0\0\30displayorder\0\0\0\0\27\0\4
\377\377\377\377D\374\0\0\0\vbatchid\0\0\0\5.\0\0\0007
$value=Trials::getTrialEditBatch($dbi,$parent_key);\0\0\0\4\0\0\0
\10auto
\0\0\0\0050D\374\0\0\0\20lastmodified\0\0\0\0050\0\0\0\4\0\0\0\4\0\0\0
\fauto_now\0\0\0\0050D\374\0\0\0\22lastmodifiedby\0\0\0\
0050\0\0\0\22$value=$G_UID;\0\0\0\4\0\0\0\10auto\0\0\0\0050D\374\0\0\0
\vtrialid\0\0\0\0050\0\0\0\4\0\0\0\4\0\0\0\17auto_parent
\0\0\0\0050D\374\0\0\0\10name\0\0\0\10Name\0\0\0\4\0\0\0\4\0\0\0
\21text_required\0\0\0\0051D\374\0\0\0\17description\0\0\0\17D
escription\0\0\0\4\0\0\0\f$valid=1\0\0\0\ftextarea\0\0\0\0052D\374\0\0
\0\17mg..., 16384, 0) = 805
22372 --- SIGSEGV (Segmentation fault) ---
22372 +++ killed by SIGSEGV +++
Summary of my perl5 (revision 5.0 version 6 subversion 1)
configuration:
Platform:
osname=linux, osvers=2.2.16-22, archname=i586-linux
uname='linux laptop 2.2.16-22 #1 tue aug 22 16:16:55 edt 2000
i586 unknown '
config_args=''
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 ='-fno-strict-aliasing -I/usr/local/include -
D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-O2',
cppflags='-fno-strict-aliasing -I/usr/local/include'
ccversion='', gccversion='2.96 2731 (Red Hat Linux 7.0)',
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=-lnsl -lgdbm -ldl -lm -lc -lcrypt -lutil
perllibs=-lnsl -ldl -lm -lc -lcrypt -lutil
libc=/lib/libc-2.1.92.so, 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'
segfault when using PerlRequire
I hesitate to post this because I haven't kept up with my reading. I did do several searches of my 28K message modperl mail folder and the list archives. My httpd.conf reads... LoadModule perl_module /opt/apache/libexec/libperl.so #PerlModule Apache::Status PerlRequire /home/stevens.1/apache-perl/conf/startup.pl If I uncomment the PerlModule config, then no core dump. If I downgrade to perl-5.0.3, then no core dump. If I Configure -Uuselargefiles, I still core dump. Solaris bug, Perl bug, modperl bug, Apache bug, or driver error? Thanks, John [EMAIL PROTECTED] gdb /opt/apache/bin/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 i386-pc-solaris2.7... (gdb) run -d /home/stevens.1/apache-perl -X Starting program: /opt/apache/bin/httpd -d /home/stevens.1/apache-perl -X Program received signal SIGSEGV, Segmentation fault. 0xdf7eaf83 in S_new_xpvnv () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/libper l.so (gdb) bt #0 0xdf7eaf83 in S_new_xpvnv () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/li bperl.so #1 0xdf7eb859 in Perl_sv_upgrade () from /opt/perl/lib/5.6.1/i86pc-solaris/COR E/libperl.so #2 0xdf7ba53a in Perl_pad_allocmy () from /opt/perl/lib/5.6.1/i86pc-solaris/CO RE/libperl.so #3 0xdf7a5f29 in Perl_yylex () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/lib perl.so #4 0xdf7b7f4f in Perl_yyparse () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/l ibperl.so #5 0xdf80ce5a in S_doeval () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/libpe rl.so #6 0xdf80e1c8 in Perl_pp_require () from /opt/perl/lib/5.6.1/i86pc-solaris/COR E/libperl.so #7 0xdf7e36cd in Perl_runops_standard () from /opt/perl/lib/5.6.1/i86pc-solari s/CORE/libperl.so #8 0xdf79ba0c in S_call_body () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/li bperl.so #9 0xdf79b772 in Perl_call_sv () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/l ibperl.so #10 0xdf79eacb in S_call_list_body () from /opt/perl/lib/5.6.1/i86pc-solaris/CO RE/libperl.so #11 0xdf79e743 in Perl_call_list () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE /libperl.so #12 0xdf7c37eb in Perl_newATTRSUB () from /opt/perl/lib/5.6.1/i86pc-solaris/COR E/libperl.so #13 0xdf7c0636 in Perl_utilize () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/l ibperl.so #14 0xdf7b8d1a in Perl_yyparse () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/l ibperl.so #15 0xdf80ce5a in S_doeval () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/libpe rl.so #16 0xdf80e1c8 in Perl_pp_require () from /opt/perl/lib/5.6.1/i86pc-solaris/COR E/libperl.so #17 0xdf7e36cd in Perl_runops_standard () from /opt/perl/lib/5.6.1/i86pc-solari s/CORE/libperl.so #18 0xdf79ba0c in S_call_body () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/li bperl.so #19 0xdf79bb92 in Perl_eval_sv () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/l ibperl.so #20 0xdf546147 in perl_do_file () from /opt/apache/libexec/libperl.so #21 0xdf5461f2 in perl_load_startup_script () from /opt/apache/libexec/libperl.so #22 0xdf540f93 in perl_cmd_require () from /opt/apache/libexec/libperl.so #23 0x805e15b in invoke_cmd () #24 0x805e629 in ap_handle_command () #25 0x805e6cb in ap_srm_command_loop () #26 0x805ed93 in ap_process_resource_config () #27 0x805f718 in ap_read_config () #28 0x806a26b in standalone_main () #29 0x806abf0 in main () #30 0x8057bf3 in _start () perl -V Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration: Platform: osname=solaris, osvers=2.7, archname=i86pc-solaris uname='sunos stevens 5.7 generic_106542-18 i86pc i386 i86pc ' config_args='-Dprefix=/opt/perl -Dcc=gcc -Duseshrplib -Uusemymalloc' 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='gcc', ccflags ='-fno-strict-aliasing -I/opt/gnu/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O', cppflags='-fno-strict-aliasing -I/opt/gnu/include' ccversion='', gccversion='2.95.3 20010315 (release)', gccosandvers='solaris2.7' 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='gcc', ldflags ='-L/opt/gnu/lib -R/opt/gnu/lib ' libpth=/opt/gnu/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.so Dynamic Linking:
Re: segfault when using PerlRequire
John D Groenveld wrote: I hesitate to post this because I haven't kept up with my reading. I did do several searches of my 28K message modperl mail folder and the list archives. My httpd.conf reads... LoadModule perl_module /opt/apache/libexec/libperl.so #PerlModule Apache::Status PerlRequire /home/stevens.1/apache-perl/conf/startup.pl If I uncomment the PerlModule config, then no core dump. If I downgrade to perl-5.0.3, then no core dump. If I Configure -Uuselargefiles, I still core dump. Solaris bug, Perl bug, modperl bug, Apache bug, or driver error? I assume that you use Apache DSO. I think that you need to rebuild your perl with -Ubincompat5005. I cannot see the value of bincompat5005 in your 'perl -V' http://perl.apache.org/guide/install.html#When_DSO_can_be_Used Thanks, John [EMAIL PROTECTED] gdb /opt/apache/bin/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 i386-pc-solaris2.7... (gdb) run -d /home/stevens.1/apache-perl -X Starting program: /opt/apache/bin/httpd -d /home/stevens.1/apache-perl -X Program received signal SIGSEGV, Segmentation fault. 0xdf7eaf83 in S_new_xpvnv () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/libper l.so (gdb) bt #0 0xdf7eaf83 in S_new_xpvnv () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/li bperl.so #1 0xdf7eb859 in Perl_sv_upgrade () from /opt/perl/lib/5.6.1/i86pc-solaris/COR E/libperl.so #2 0xdf7ba53a in Perl_pad_allocmy () from /opt/perl/lib/5.6.1/i86pc-solaris/CO RE/libperl.so #3 0xdf7a5f29 in Perl_yylex () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/lib perl.so #4 0xdf7b7f4f in Perl_yyparse () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/l ibperl.so #5 0xdf80ce5a in S_doeval () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/libpe rl.so #6 0xdf80e1c8 in Perl_pp_require () from /opt/perl/lib/5.6.1/i86pc-solaris/COR E/libperl.so #7 0xdf7e36cd in Perl_runops_standard () from /opt/perl/lib/5.6.1/i86pc-solari s/CORE/libperl.so #8 0xdf79ba0c in S_call_body () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/li bperl.so #9 0xdf79b772 in Perl_call_sv () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/l ibperl.so #10 0xdf79eacb in S_call_list_body () from /opt/perl/lib/5.6.1/i86pc-solaris/CO RE/libperl.so #11 0xdf79e743 in Perl_call_list () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE /libperl.so #12 0xdf7c37eb in Perl_newATTRSUB () from /opt/perl/lib/5.6.1/i86pc-solaris/COR E/libperl.so #13 0xdf7c0636 in Perl_utilize () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/l ibperl.so #14 0xdf7b8d1a in Perl_yyparse () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/l ibperl.so #15 0xdf80ce5a in S_doeval () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/libpe rl.so #16 0xdf80e1c8 in Perl_pp_require () from /opt/perl/lib/5.6.1/i86pc-solaris/COR E/libperl.so #17 0xdf7e36cd in Perl_runops_standard () from /opt/perl/lib/5.6.1/i86pc-solari s/CORE/libperl.so #18 0xdf79ba0c in S_call_body () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/li bperl.so #19 0xdf79bb92 in Perl_eval_sv () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/l ibperl.so #20 0xdf546147 in perl_do_file () from /opt/apache/libexec/libperl.so #21 0xdf5461f2 in perl_load_startup_script () from /opt/apache/libexec/libperl.so #22 0xdf540f93 in perl_cmd_require () from /opt/apache/libexec/libperl.so #23 0x805e15b in invoke_cmd () #24 0x805e629 in ap_handle_command () #25 0x805e6cb in ap_srm_command_loop () #26 0x805ed93 in ap_process_resource_config () #27 0x805f718 in ap_read_config () #28 0x806a26b in standalone_main () #29 0x806abf0 in main () #30 0x8057bf3 in _start () perl -V Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration: Platform: osname=solaris, osvers=2.7, archname=i86pc-solaris uname='sunos stevens 5.7 generic_106542-18 i86pc i386 i86pc ' config_args='-Dprefix=/opt/perl -Dcc=gcc -Duseshrplib -Uusemymalloc' 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='gcc', ccflags ='-fno-strict-aliasing -I/opt/gnu/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O', cppflags='-fno-strict-aliasing -I/opt/gnu/include' ccversion='', gccversion='2.95.3 20010315 (release)', gccosandvers='solaris2.7' 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',
Re: segfault when using PerlRequire
I assume that you use Apache DSO. I think that you need to rebuild your perl with -Ubincompat5005. I cannot see the value of bincompat5005 in your 'perl -V' http://perl.apache.org/guide/install.html#When_DSO_can_be_Used Still cores after explicit -Ubincompat5005, I'm fairly certain I answered NO to that question. Thanks for pointing me to the guide, I'm due for a refresher reading from top to bottom. John [EMAIL PROTECTED]
SegFault report with backtrace
Hello! Here is a simple Test.pm handler that causes segfaults in our server. The Test.pm uses XS for creating configuration settings. The purpose is to set 'Testing' flag on or off in .htaccess files. I tried to make the module as simple as possible. The specifications are in the attachments files. sf_install.txt contains the information about the mod_perl compilation and the test module. sf_case1.txt contains the backtrace in Mandrake 8.1 with perl 5.6.1 while the sf_case2.txt contains the backtrace from Debian 2.2 with perl 5.005_3. To sum up the attachments, the error_log gives warnings like: [debug] mod_perl.c(1322): [warning] PerlFixupHandler stack is not an ARRAY! and the backtrace gives information like: ... type=0x81264d4 SERVER_CREATE) at perl_config.c:896 The segfault problems seems to haunt me whenever I try to create new configuration directives. In fact the different and unsolved segfaults have made me test many combinations with different versions of linux, perl, apache and mod_perl during the last year. Maybe better luck with solaris? Too bad that propably the fault lies with me. Of course, I'm more than happy to test/give more info about the segfault problem! Best wishes, -- Kari Nurmela, [EMAIL PROTECTED], (02) 333 8847 / (0400) 786 547 University of Turku, Finland CASE 2 == Debian 2.2 (stable) Linux aura 2.2.19pre17-compact #1 Mon Apr 2 01:35:19 PDT 2001 i586 unknown perl -V: Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration: Platform: osname=linux, osvers=2.2.15pre14, archname=i386-linux uname='linux them 2.2.15pre14 #2 smp mon mar 13 14:29:00 est 2000 i686 unknown ' hint=recommended, useposix=true, d_sigaction=define usethreads=undef useperlio=undef d_sfio=undef Compiler: cc='cc', optimize='-O2 ', gccversion=2.95.2 2313 (Debian GNU/Linux) cppflags='-Dbool=char -DHAS_BOOL -D_REENTRANT -DDEBIAN -I/usr/local/include' ccflags ='-Dbool=char -DHAS_BOOL -D_REENTRANT -DDEBIAN -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 -ldbm -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 Apr 30 2000 12:08:38 %ENV: PERLPREFIX=/usr/local/wm5/perl @INC: /usr/lib/perl5/5.005/i386-linux /usr/lib/perl5/5.005 /usr/local/lib/site_perl/i386-linux /usr/local/lib/site_perl /usr/lib/perl5 . BACKTRACE = [karnurme@sapphire apache]$ gdb /usr/local/wm5/apache/bin/httpd (gdb) run -X -f /usr/local/wm5/apache/conf/httpd.conf -d /usr/local/wm5/apache Starting program: /usr/local/wm5/apache/bin/httpd -X -f /usr/local/wm5/apache/conf/httpd.conf -d /usr/local/wm5/apache (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x807dad2 in perl_get_module_ptr () (gdb) bt #0 0x807dad2 in perl_get_module_ptr () #1 0x807ddb5 in perl_get_module_ptr () #2 0x807e132 in perl_cmd_perl_TAKE123 () #3 0x807da09 in perl_cmd_perl_FLAG () #4 0x8097e84 in ap_clear_module_list () #5 0x8098151 in ap_handle_command () #6 0x80981ed in ap_srm_command_loop () #7 0x8098a92 in ap_parse_htaccess () #8 0x80aa022 in ap_send_error_response () #9 0x80ab457 in ap_some_auth_required () #10 0x80ab916 in ap_process_request () #11 0x80a2880 in ap_child_terminate () #12 0x80a2a41 in ap_child_terminate () #13 0x80a2bbc in ap_child_terminate () #14 0x80a322c in ap_child_terminate () #15 0x80a3a5c in main () #16 0x400d4a42 in __libc_start_main () from /lib/libc.so.6 (gdb) karnurme@aura:~/wm5$ less apache/logs/error_log [Mon Nov 5 17:02:45 2001] [notice] Apache/1.3.20 (Unix) mod_perl/1.26 configured -- resuming normal operations [Mon Nov 5 17:03:22 2001] [notice] child pid 12686 exit signal Segmentation fault (11), possible coredump in /usr/local/wm5/apache BACKTRACE WITH NEW LIBPERL == cd apache_1.3.20/src/modules/perl rm *.[oa] make LIBPERL=libperld.a cp libperl.a /usr/lib/perl5/5.005/i386-linux/ cd mod_perl-1.26/ make install (gdb) run -X -f `pwd`/t/conf/httpd.conf
Re: SegFault report with backtrace
Hi there, On Mon, 5 Nov 2001 [EMAIL PROTECTED] wrote: Here is a simple Test.pm handler that causes segfaults in our server. Last year I had a Test.pm that caused segfaults too, on Solaris boxes. By accident I discovered that the segfaults went away when I renamed the file! At the time I was doing some work for a company in London, on a very tight schedule, so I never got the chance to investigate further. I sent a stack backtrace to Eric but we never got to the bottom of it. 73, Ged.
segfault on start....
I seem to have something boned... I can't even run an apachectl configtest without segfaulting. # ../bin/apachectl start ../bin/apachectl: line 171: 16563 Segmentation fault $HTTPD ../bin/apachectl start: httpd could not be started Removing the Apache::Registry call from my httpd.conf makes the problem go away immediately. This is on apache 1.3.20, mod_perl 1.26, and perl 5.6.1 (-V output at the bottom) Anyone have any thoughts? D # perl -v This is perl, v5.6.1 built for i686-linux-thread-multi Copyright 1987-2001, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using `man perl' or `perldoc perl'. If you have access to the Internet, point your browser at http://www.perl.com/, the Perl Home Page. [root@minbar conf]# perl -V Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration: Platform: osname=linux, osvers=2.2.17, archname=i686-linux-thread-multi uname='linux minbar.megacity.org 2.2.17 #1 mon sep 4 22:42:31 pdt 2000 i686 unknown ' config_args='-Dusethreads' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef Compiler: cc='cc', ccflags ='-D_REENTRANT -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2', cppflags='-D_REENTRANT -fno-strict-aliasing -I/usr/local/include' ccversion='', gccversion='egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)', 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=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lpthread -lc -lposix -lcrypt -lutil perllibs=-lnsl -ldl -lm -lpthread -lc -lposix -lcrypt -lutil libc=/lib/libc-2.1.2.so, 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): Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT Built under linux Compiled at Apr 9 2001 07:56:05 @INC: /usr/local/lib/perl5/5.6.1/i686-linux-thread-multi /usr/local/lib/perl5/5.6.1 /usr/local/lib/perl5/site_perl/5.6.1/i686-linux-thread-multi /usr/local/lib/perl5/site_perl/5.6.1 /usr/local/lib/perl5/site_perl/5.6.0/i686-linux-thread-multi /usr/local/lib/perl5/site_perl/5.6.0 /usr/local/lib/perl5/site_perl . -- +-+-+ | [EMAIL PROTECTED] | Thou art the ruins of the noblest man | | Derek J. Balling | That ever lived in the tide of times. | | | Woe to the hand that shed this costly | | | blood - Julius Caesar Act 3, Scene 1 | +-+-+
Re: segfault on start....
Derek Balling wrote: I seem to have something boned... I can't even run an apachectl configtest without segfaulting. # ../bin/apachectl start ../bin/apachectl: line 171: 16563 Segmentation fault $HTTPD ../bin/apachectl start: httpd could not be started Removing the Apache::Registry call from my httpd.conf makes the problem go away immediately. This is on apache 1.3.20, mod_perl 1.26, and perl 5.6.1 (-V output at the bottom) Anyone have any thoughts? Please follow the instructions in the SUPPORT file in the modperl source distro to report a segfault. thanks. _ 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: segfault on start....
At 1:01 PM +0800 10/3/01, Stas Bekman wrote: Derek Balling wrote: I seem to have something boned... I can't even run an apachectl configtest without segfaulting. # ../bin/apachectl start ../bin/apachectl: line 171: 16563 Segmentation fault $HTTPD ../bin/apachectl start: httpd could not be started Removing the Apache::Registry call from my httpd.conf makes the problem go away immediately. This is on apache 1.3.20, mod_perl 1.26, and perl 5.6.1 (-V output at the bottom) Anyone have any thoughts? Please follow the instructions in the SUPPORT file in the modperl source distro to report a segfault. thanks. Did that. THAT's the output I get, nothing more. Make test, and the test server all check out 100% and run fine, its only when I put it in production that it takes a dump, and leaves absolutely nothing except what you see there. Lots of the segfault stuff in SUPPORT has to do with when it segfaults on a request. It's hard to attach to the running process or send the request that causes the segfault when you can't get that far. ;) D -- +-+-+ | [EMAIL PROTECTED] | Thou art the ruins of the noblest man | | Derek J. Balling | That ever lived in the tide of times. | | | Woe to the hand that shed this costly | | | blood - Julius Caesar Act 3, Scene 1 | +-+-+
Re: segfault on start....
Derek Balling wrote: Did that. THAT's the output I get, nothing more. Make test, and the test server all check out 100% and run fine, its only when I put it in production that it takes a dump, and leaves absolutely nothing except what you see there. Lots of the segfault stuff in SUPPORT has to do with when it segfaults on a request. It's hard to attach to the running process or send the request that causes the segfault when you can't get that far. ;) Run your httpd in -X mode without the help of the apachectl start script. You can get that under gdb. -X mode runs in single process mode, and is most handy for diagnosing problems such as these. --Josh _ Joshua Chamas Chamas Enterprises Inc. NodeWorks Founder Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
Re: segfault on start....
At 10:38 PM -0700 10/2/01, Joshua Chamas wrote: Derek Balling wrote: Did that. THAT's the output I get, nothing more. Make test, and the test server all check out 100% and run fine, its only when I put it in production that it takes a dump, and leaves absolutely nothing except what you see there. Lots of the segfault stuff in SUPPORT has to do with when it segfaults on a request. It's hard to attach to the running process or send the request that causes the segfault when you can't get that far. ;) Run your httpd in -X mode without the help of the apachectl start script. You can get that under gdb. -X mode runs in single process mode, and is most handy for diagnosing problems such as these. I guess I'm dense: # ../bin/httpd -X -f conf/httpd.conf.mod_perl Segmentation fault how is this more helpful? ;) Pretend like I'm NOT some C-code guru, and explain to me what I need to do, because it doesn't seem like doing what the docs say is helping. *chuckle* What can I give you that would be helpful to debug this? :) D -- +-+-+ | [EMAIL PROTECTED] | Thou art the ruins of the noblest man | | Derek J. Balling | That ever lived in the tide of times. | | | Woe to the hand that shed this costly | | | blood - Julius Caesar Act 3, Scene 1 | +-+-+
Re: segfault on start....
On Tue, Oct 02, 2001 at 10:46:45PM -0700, Derek Balling wrote: Run your httpd in -X mode without the help of the apachectl start script. You can get that under gdb. -X mode runs in single process mode, and is most handy for diagnosing problems such as these. I guess I'm dense: # ../bin/httpd -X -f conf/httpd.conf.mod_perl Segmentation fault how is this more helpful? ;) Joshua meant for you to run it in gdb with that option, but it might not be very helpfull if you didn't compile with CFLAGS=-g But you can try it anyay: gdb ../bin/httpd (gdb) run -X likely to give a segmentation fault (gdb) bt and send the information it gives here. Another option would be to: to use strace|truss|whatever your system uses to trace system call strace ../bin/httpd -X Which might give you a lot of information which will very likely be to much to post here. Pretend like I'm NOT some C-code guru, and explain to me what I need to do, because it doesn't seem like doing what the docs say is helping. *chuckle* Isn't there anything about debugging in the documentation? -- Thomas Eibner http://thomas.eibner.dk/ DnsZone http://dnszone.org/ mod_pointer http://stderr.net/mod_pointer
Re: segfault on start....
Derek Balling wrote: Run your httpd in -X mode without the help of the apachectl start script. You can get that under gdb. -X mode runs in single process mode, and is most handy for diagnosing problems such as these. I guess I'm dense: # ../bin/httpd -X -f conf/httpd.conf.mod_perl Segmentation fault how is this more helpful? ;) Pretend like I'm NOT some C-code guru, and explain to me what I need to do, because it doesn't seem like doing what the docs say is helping. *chuckle* unix prompt gdb ../bin/httpd ... gdb header stuff ... (gdb) run -X -f conf/httpd.conf.mod_perl Segfault (gdb) bt !!! UGLY STACK TRACE TO FOLLOW !!! This *MIGHT* give the real gurus on the list something to work with. Its how I have debugged many a segfault in my day. This or something like it. You can also load up a core dump with gdb, but I can't remember the last time I did that, so I have no real directions here, but its probably just prompt gdb core ... (gdb) bt [ find out where it segfaulted ] --Josh _ Joshua Chamas Chamas Enterprises Inc. NodeWorks Founder Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
Re: segfault on start....
Joshua meant for you to run it in gdb with that option, but it might not be very helpfull if you didn't compile with CFLAGS=-g Well, I did PERL_DEBUG=1, which allegedly does that. :) But you can try it anyay: gdb ../bin/httpd (gdb) run -X likely to give a segmentation fault (gdb) bt and send the information it gives here. (gdb) run -X -f conf/httpd.conf.mod_perl Starting program: /web1.3/conf/../bin/httpd -X -f conf/httpd.conf.mod_perl Program received signal SIGSEGV, Segmentation fault. 0x80de49c in Perl_gv_fetchpv () (gdb) bt #0 0x80de49c in Perl_gv_fetchpv () #1 0x80da33f in Perl_get_sv () #2 0x808a461 in perl_create_request_config () #3 0x808a6ac in perl_cmd_handler_handlers () #4 0x80afde6 in ap_clear_module_list () #5 0x80b0223 in ap_handle_command () #6 0x80b02b7 in ap_srm_command_loop () #7 0x80b0910 in ap_process_resource_config () #8 0x80b1182 in ap_read_config () #9 0x80bb0a9 in main () #10 0x400df1eb in __libc_start_main (main=0x80bae1c main, argc=4, argv=0xbc54, init=0x8062748 _init, fini=0x816442c _fini, rtld_fini=0x4000a610 _dl_fini, stack_end=0xbc4c) at ../sysdeps/generic/libc-start.c:90 Pretend like I'm NOT some C-code guru, and explain to me what I need to do, because it doesn't seem like doing what the docs say is helping. *chuckle* Isn't there anything about debugging in the documentation? It all seems centered around, near as I can tell, debugging a server that runs but takes a dump on a particular script/URL/etc. D -- +-+-+ | [EMAIL PROTECTED] | Thou art the ruins of the noblest man | | Derek J. Balling | That ever lived in the tide of times. | | | Woe to the hand that shed this costly | | | blood - Julius Caesar Act 3, Scene 1 | +-+-+
Re: segfault
Thanks for your suggestion. I followed the doc
at the link you specified and got it working.
Bob
Stas Bekman wrote:
On Fri, 7 Sep 2001, Bob Mroczka wrote:
I just compiled and installed
Apache 1.3.20 with mod_perl 1.26
and mod_ssl-2.8.4. Apache
segfaults almost immediately on all requests.
For kicks I compiled Apache
without mod_ssl and the segfaults disappear.
Also interesting is the fact that when
I compile without mod_ssl make test
completes successfully but when I include
mod_ssl the make test fails to start a httpd process
due to a syntax error:
letting apache warm up...\c
Syntax error on line 3 of /usr/src/mod_perl-1.26/t/conf/httpd.conf:
Invalid command '=pod', perhaps mis-spelled or defined by a module not
included in the server configuration
done
/usr/bin/perl t/TEST 0
still waiting for server to warm up...not ok
you have used PREP_HTTPD, of course make test won't work.
You want to follow this scenario while installing mod_ssl+mod_perl
http://perl.apache.org/guide/install.html#mod_perl_and_mod_ssl_openssl_
and you will be all set.
When I run apache under -X and strace here is what
happens when the request comes in:
26480 read(5, GET / HTTP/1.0\r\nConnection: Keep..., 4096) = 277
26480 rt_sigaction(SIGUSR1, {SIG_IGN}, {SIG_IGN}, 8) = 0
26480 time(NULL)= 17985
26480 alarm(300)= 300
26480 alarm(0) = 300
26480 stat64(0x8170710, 0xb17c) = 0
26480 --- SIGSEGV (Segmentation fault) ---
26480 +++ killed by SIGSEGV +++
Does anyone have any suggestions?
You have kindly provided everything but the core trace. See the SUPPORT
file to learn how to do that, but first try to build using the details
from above.
_
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/
segfault
I just compiled and installed
Apache 1.3.20 with mod_perl 1.26
and mod_ssl-2.8.4. Apache
segfaults almost immediately on all requests.
For kicks I compiled Apache
without mod_ssl and the segfaults disappear.
Also interesting is the fact that when
I compile without mod_ssl make test
completes successfully but when I include
mod_ssl the make test fails to start a httpd process
due to a syntax error:
letting apache warm up...\c
Syntax error on line 3 of /usr/src/mod_perl-1.26/t/conf/httpd.conf:
Invalid command '=pod', perhaps mis-spelled or defined by a module not
included in the server configuration
done
/usr/bin/perl t/TEST 0
still waiting for server to warm up...not ok
I could go with two separate web servers
but I would like to know if there is a way
to make one web server with both mod_perl and mod_ssl.
This is the script I used to compile everything:
APACHE_VER=1.3.20
MM_VER=1.1.3
MODSSL_VER=2.8.4
MODPERL_VER=1.26
(cd ../mod_ssl-$MODSSL_VER-$APACHE_VER
./configure \
--with-apache=../apache_$APACHE_VER \
--with-crt=/root/demoCA/newcerts/x.pem \
--with-key=/root/demoCA/csr/x.csr
cd ../mod_perl-$MODPERL_VER
# prep perl side of mod_perl into the perl system
# and prep the apache side of mod_perl
perl Makefile.PL EVERYTHING=1 \
DO_HTTPD=1 \
APACHE_PREFIX=/usr/local/apache \
APACHE_SRC=../apache_$APACHE_VER/src \
USE_APACI=1 \
PREP_HTTPD=1
make
make install
cd ../apache_$APACHE_VER
SSL_BASE=SYSTEM \
EAPI_MM=SYSTEM \
./configure \
--with-layout=Slackware \
--enable-module=ssl \
--enable-shared=ssl \
--disable-rule=SSL_COMPAT \
--enable-module=most \
--activate-module=src/modules/perl/libperl.a
\
--enable-shared=max
make
make install ) 21 | tee install.log
Here is the message that goes into the error log:
[Fri Sep 7 21:25:56 2001] [notice] Apache/1.3.20 (Unix) mod_perl/1.26
configured -- resuming normal operations
[Fri Sep 7 21:26:09 2001] [notice] child pid 26019 exit signal
Segmentation fault (11)
The output of perl -V is:
Summary of my perl5 (revision 5.0 version 6 subversion 1)
configuration:
Platform:
osname=linux, osvers=2.4.2, archname=i386-linux
uname='linux grommet 2.4.2 #1 smp sun feb 25 16:33:33 pst 2001
i686 unknown '
config_args='-de -Dprefix=/usr -Darchname=i386-linux
-Dprivlib=/usr/lib/perl5 -Darchlib=/usr/lib/perl5/i386-linux
-Dsitelib=/usr/lib/perl5/site_perl
-Dsitearch=/usr/lib/perl5/site_perl/i386-linux'
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 ='-fno-strict-aliasing -I/usr/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-O2',
cppflags='-fno-strict-aliasing -I/usr/local/include'
ccversion='', gccversion='2.95.3 20010315 (release)',
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=-lnsl -lndbm -lgdbm -ldl -lm -lc -lcrypt -lutil
perllibs=-lnsl -ldl -lm -lc -lcrypt -lutil
libc=/lib/libc-2.2.2.so, 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):
Compile-time options: USE_LARGE_FILES
Built under linux
Compiled at Apr 11 2001 22:57:30
@INC:
/usr/lib/perl5/i386-linux
/usr/lib/perl5
/usr/lib/perl5/site_perl/i386-linux
/usr/lib/perl5/site_perl
/usr/lib/perl5/site_perl
When I run apache under -X and strace here is what
happens when the request comes in:
26480 read(5, GET / HTTP/1.0\r\nConnection: Keep..., 4096) = 277
26480 rt_sigaction(SIGUSR1, {SIG_IGN}, {SIG_IGN}, 8) = 0
26480 time(NULL)= 17985
26480 alarm(300)= 300
26480 alarm(0) = 300
26480 stat64(0x8170710, 0xb17c) = 0
26480 --- SIGSEGV (Segmentation fault) ---
26480 +++ killed by SIGSEGV +++
Does anyone have any suggestions?
Re: segfault
On Fri, 7 Sep 2001, Bob Mroczka wrote:
I just compiled and installed
Apache 1.3.20 with mod_perl 1.26
and mod_ssl-2.8.4. Apache
segfaults almost immediately on all requests.
For kicks I compiled Apache
without mod_ssl and the segfaults disappear.
Also interesting is the fact that when
I compile without mod_ssl make test
completes successfully but when I include
mod_ssl the make test fails to start a httpd process
due to a syntax error:
letting apache warm up...\c
Syntax error on line 3 of /usr/src/mod_perl-1.26/t/conf/httpd.conf:
Invalid command '=pod', perhaps mis-spelled or defined by a module not
included in the server configuration
done
/usr/bin/perl t/TEST 0
still waiting for server to warm up...not ok
you have used PREP_HTTPD, of course make test won't work.
You want to follow this scenario while installing mod_ssl+mod_perl
http://perl.apache.org/guide/install.html#mod_perl_and_mod_ssl_openssl_
and you will be all set.
When I run apache under -X and strace here is what
happens when the request comes in:
26480 read(5, GET / HTTP/1.0\r\nConnection: Keep..., 4096) = 277
26480 rt_sigaction(SIGUSR1, {SIG_IGN}, {SIG_IGN}, 8) = 0
26480 time(NULL)= 17985
26480 alarm(300)= 300
26480 alarm(0) = 300
26480 stat64(0x8170710, 0xb17c) = 0
26480 --- SIGSEGV (Segmentation fault) ---
26480 +++ killed by SIGSEGV +++
Does anyone have any suggestions?
You have kindly provided everything but the core trace. See the SUPPORT
file to learn how to do that, but first try to build using the details
from above.
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: segfault with mod_perl, Oraperl, XML::Parser
Thanks everyone for their help, I tried all the suggestions with no
luck, and I definitely configured Apache without expat. I finally
ended up parsing the XML in perl instead of using Expat. Since I
already had handlers, it was quite easy, although still needs better
validation and error handling.
When I get a chance I'll see if this works on mod_perl 2.0. If anyone
does get this to work on Solaris 2.8 x86, please let me know.
Thanks, Scott
#!./perl
use DBD::Oracle;
use XML::Parser::Expat;
my $parser = new XML::Parser::Expat;
$parser-parse('foo id=me here emwe/em go /foo');
# perl-5.6.1
# mod_perl-1.26
# apache 1.3.20
# expat-1.95.1
# DBD-Oracle-1.06
# DBI-1.15
# XML-Parser-2.30
# config_args='-Dcc=gcc -Ubincompat5005 -Uuselargefiles -Uusemymalloc -des'
On Tue, July 31 16:37 +0100, Tim Bunce wrote:
On Mon, Jul 30, 2001 at 03:30:48PM -0400, Philip Mak wrote:
On Mon, 30 Jul 2001, Scott Kister wrote:
uselargefiles=define
Have you tried turning off uselargefiles?
I might be off track here, but recently I tried to install mod_perl on
Solaris 5.8. It kept segfaulting until I turned off uselargefiles and
binary compatibility with 5.00503. You could try recompiling perl with
this configure line, then recompiling mod_perl and see what happens:
sh Configure -des -Dcc=gcc -Ubincompat5005 -Uuselargefiles
And -Uusemymalloc
(or something like that) to get perl to use the system's own malloc.
Tim.
Re: segfault with mod_perl, Oraperl, XML::Parser
On 03 Aug 2001 10:26:37 -0700, Scott Kister wrote: Thanks everyone for their help, I tried all the suggestions with no luck, and I definitely configured Apache without expat. I finally ended up parsing the XML in perl instead of using Expat. Since I already had handlers, it was quite easy, although still needs better validation and error handling. Try XML::LibXML. -- 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: segfault w/ Apache 1.3.20, mod_perl 1.26
On Sun, 22 Jul 2001, Richard L. Goerwitz III wrote: I apologize if this problem has already been identified and solved. After upgrading from mod_perl 1.25 to mod_perl 1.26 I fired up an Apache server instance that uses a config file with an extensive set of Perl/Perl sections. I'm using the Perl that came with my Linux (RedHat 7.0) machine, namely 5.6.0. i can't reproduce with 5.6.1. can you post a Perl section the produces the segv?
Re: segfault with mod_perl, Oraperl, XML::Parser
On Mon, Jul 30, 2001 at 03:30:48PM -0400, Philip Mak wrote: On Mon, 30 Jul 2001, Scott Kister wrote: uselargefiles=define Have you tried turning off uselargefiles? I might be off track here, but recently I tried to install mod_perl on Solaris 5.8. It kept segfaulting until I turned off uselargefiles and binary compatibility with 5.00503. You could try recompiling perl with this configure line, then recompiling mod_perl and see what happens: sh Configure -des -Dcc=gcc -Ubincompat5005 -Uuselargefiles And -Uusemymalloc (or something like that) to get perl to use the system's own malloc. Tim.
Re: segfault with mod_perl, Oraperl, XML::Parser
I've been looking into this some more without much progress. Is anyone
on this list successfully using modperl, DBD::Oracle, and XML::Parser
on Solaris 2.8 x86?
Are there any known symbol conflicts with Oracle's libclntsh.so and
Expat? Any good alternative perl XML Parsers to Expat?
Thanks, Scott
On Sun, July 22 13:30 -0700, Scott Kister wrote:
This program core dumps when run under mod_perl on Solaris 2.8 x86.
#!./perl
use Oraperl; # use DBD::Oracle; fails as well
use XML::Parser;
my $parser = new XML::Parser;
$parser-parsestring(''); # fails with valid xml here as well
It runs fine on Linux and Sparc Solaris. It also works fine from the
command line, or if I remove the use Oraperl line. I'm using the
following releases. I had the same problem under apache 1.3.19 and
mod_perl-1.25, and with perl compiled with and without usemymalloc.
I also tried Apache with mod_perl as a DSO and statically linked.
apache 1.3.20
expat-1.95.1
mod_perl-1.26
perl-5.6.1
DBD-Oracle-1.06
DBI-1.15
XML-Parser-2.30
I searched the web and found a known problem with symbol conflict with
apache's expat, but I have --disable-rule=EXPAT. I also saw a
recommendation to use XML-Parser-2.29, which I tried with no success.
Has anyone here seen this problem or have ideas on how to solve it?
The gdb backtrace:
(gdb) bt
#0 0xdefd3f98 in ?? ()
#1 0xdfbd7da9 in ?? ()
#2 0xdfbdeee2 in ?? ()
#3 0xdfbd31a9 in ?? ()
#4 0xdf78c6d1 in Perl_pp_entersub ()
from /server/local/apache/libexec/libperl.so
#5 0xdf786f92 in Perl_runops_standard ()
from /server/local/apache/libexec/libperl.so
#6 0xdf7484d6 in S_call_body () from /server/local/apache/libexec/libperl.so
#7 0xdf74829a in Perl_call_sv () from /server/local/apache/libexec/libperl.so
#8 0xdf729676 in perl_call_handler ()
from /server/local/apache/libexec/libperl.so
#9 0xdf728ef4 in perl_run_stacked_handlers ()
from /server/local/apache/libexec/libperl.so
#10 0xdf727734 in perl_handler () from /server/local/apache/libexec/libperl.so
#11 0x80739a5 in ap_invoke_handler ()
#12 0x8088398 in process_request_internal ()
#13 0x8088402 in ap_process_request ()
#14 0x807f2db in child_main ()
#15 0x807f564 in make_child ()
#16 0x807f8ec in perform_idle_server_maintenance ()
#17 0x807fe21 in standalone_main ()
#18 0x8080460 in main ()
#19 0x8056adf in _start ()
I turned on the nontstop debugging. The output from where it seg faults
is as follows.
entering XML::Parser::Expat::parse
438: my $self = shift;
439: my $arg = shift;
440: croak Parse already in progress (Expat) if $self-{_State_};
441: $self-{_State_} = 1;
442: my $parser = $self-{Parser};
443: my $ioref;
444: my $result = 0;
446: if (defined $arg) {
447: if (ref($arg) and UNIVERSAL::isa($arg, 'IO::Handle')) {
455: eval {
456: $ioref = *{$arg}{IO};
456: $ioref = *{$arg}{IO};
-- end of output, seg fault here
XML/Parser.pm
455 sub Char {
456my $expat = shift;
457my $text = shift;
458my $class = ${$expat}{Pkg}::Characters;
459my $clist = $expat-{Curlist};
perl configure options:
-Dprefix=/server/local -Uusemymalloc -Ubincompat5005 -des
% perl -V
Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration:
Platform:
osname=solaris, osvers=2.8, archname=i86pc-solaris
uname='sunos x86-b 5.8 generic_108529-06 i86pc i386 i86pc '
config_args='-Dprefix=/server/local -Uinstallusrbinperl -Ubincompat5005 -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 ='-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'
ccversion='', gccversion='2.95.2 19991024 (release)', gccosandvers='solaris2.8'
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=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: USE_LARGE_FILES
Built under
Re: segfault with mod_perl, Oraperl, XML::Parser
On Mon, 30 Jul 2001, Scott Kister wrote: uselargefiles=define Have you tried turning off uselargefiles? I might be off track here, but recently I tried to install mod_perl on Solaris 5.8. It kept segfaulting until I turned off uselargefiles and binary compatibility with 5.00503. You could try recompiling perl with this configure line, then recompiling mod_perl and see what happens: sh Configure -des -Dcc=gcc -Ubincompat5005 -Uuselargefiles
segfault w/ Apache 1.3.20, mod_perl 1.26
I apologize if this problem has already been identified and solved. After upgrading from mod_perl 1.25 to mod_perl 1.26 I fired up an Apache server instance that uses a config file with an extensive set of Perl/Perl sections. I'm using the Perl that came with my Linux (RedHat 7.0) machine, namely 5.6.0. I'm just wondering if the following trace looks familiar to anyone: Program received signal SIGSEGV, Segmentation fault. 0x81fc2c2 in Perl_sv_free () (gdb) bt #0 0x81fc2c2 in Perl_sv_free () #1 0x81d3f74 in Perl_cv_undef () #2 0x80ab249 in perl_clear_symtab () #3 0x80ab8cf in perl_section () #4 0x818aee8 in invoke_cmd () #5 0x818b9fe in ap_handle_command () #6 0x818ba91 in ap_srm_command_loop () #7 0x818c0fe in ap_process_resource_config () #8 0x818ca33 in ap_read_config () #9 0x8196760 in standalone_main () #10 0x819709b in main () #11 0x402f4b5c in __libc_start_main (main=0x8196ce8 main, argc=4, ubp_av=0xb9e4, init=0x807d58c _init, fini=0x8233a40 _fini, rtld_fini=0x4000d634 _dl_fini, stack_end=0xb9dc) at ../sysdeps/generic/libc-start.c:129 -- Richard Goerwitz [EMAIL PROTECTED] tel: 401 438 8978
More information on segfault
More information on segfault (apache-1.3.20, mod_perl 1.26_01, perl 5.6.0 [default RedHat 7.0 installation of Perl plus modules]). I've compiled in tracing and now at least pinpoint the command that's causing the problem (yes, I have mod_ssl-2.8.4-1.3.20 compiled in as well): SVt_PV: $SSLPassPhraseDialog = `'exec:/usr/local/sbin/echo-server-privkey-password'' handle_command (SSLPassPhraseDialog 'exec:/usr/local/sbin/echo-server-privkey-password'): OK Program received signal SIGSEGV, Segmentation fault. 0x81fe1d2 in Perl_sv_free () (gdb) bt #0 0x81fe1d2 in Perl_sv_free () #1 0x81d5e84 in Perl_cv_undef () #2 0x80acba9 in perl_clear_symtab () #3 0x80ad38f in perl_section () #4 0x818cdf8 in invoke_cmd () #5 0x818d90e in ap_handle_command () #6 0x818d9a1 in ap_srm_command_loop () #7 0x818e00e in ap_process_resource_config () #8 0x818e943 in ap_read_config () #9 0x8198670 in standalone_main () #10 0x8198fab in main () #11 0x402f4b5c in __libc_start_main (main=0x8198bf8 main, argc=4, ubp_av=0xb9c4, init=0x807d5d8 _init, fini=0x8235950 _fini, rtld_fini=0x4000d634 _dl_fini, stack_end=0xb9bc) at ../sysdeps/generic/libc-start.c:129 All this tells me is that the error is occurring after all the handle_command() calls are finished (SSLPassPhraseDialog is the last one to be executed; if I remove the $SSLPassPhraseDialog = statement it and put it outside a Perl section, then the seg- fault happens anyway - after the last command gets handled). -- Richard Goerwitz [EMAIL PROTECTED] tel: 401 438 8978
segfault with mod_perl, Oraperl, XML::Parser
apologies if this comes through twice, my first try didn't seem to
make it
This program core dumps when run under mod_perl on Solaris 2.8 x86.
#!./perl
use Oraperl;
use XML::Parser;
my $parser = new XML::Parser;
$parser-parsestring(''); # fails with valid xml here as well
It runs fine on Linux and Sparc Solaris. It also works fine from the
command line, or if I remove the use Oraperl line. I'm using the
following releases. I had the same problem under apache 1.3.19 and
mod_perl-1.25, and with perl compiled with and without usemymalloc.
I also tried Apache with mod_perl as a DSO and statically linked.
apache 1.3.20
expat-1.95.1
mod_perl-1.26
perl-5.6.1
DBD-Oracle-1.06
DBI-1.15
XML-Parser-2.30
I searched the web and found a known problem with symbol conflict with
apache's expat, but I have --disable-rule=EXPAT. I also saw a
recommendation to use XML-Parser-2.29, which I tried with no success.
Has anyone here seen this problem or have ideas on how to solve it?
The gdb backtrace:
(gdb) bt
#0 0xdefd3f98 in ?? ()
#1 0xdfbd7da9 in ?? ()
#2 0xdfbdeee2 in ?? ()
#3 0xdfbd31a9 in ?? ()
#4 0xdf78c6d1 in Perl_pp_entersub ()
from /server/local/apache/libexec/libperl.so
#5 0xdf786f92 in Perl_runops_standard ()
from /server/local/apache/libexec/libperl.so
#6 0xdf7484d6 in S_call_body () from /server/local/apache/libexec/libperl.so
#7 0xdf74829a in Perl_call_sv () from /server/local/apache/libexec/libperl.so
#8 0xdf729676 in perl_call_handler ()
from /server/local/apache/libexec/libperl.so
#9 0xdf728ef4 in perl_run_stacked_handlers ()
from /server/local/apache/libexec/libperl.so
#10 0xdf727734 in perl_handler () from /server/local/apache/libexec/libperl.so
#11 0x80739a5 in ap_invoke_handler ()
#12 0x8088398 in process_request_internal ()
#13 0x8088402 in ap_process_request ()
#14 0x807f2db in child_main ()
#15 0x807f564 in make_child ()
#16 0x807f8ec in perform_idle_server_maintenance ()
#17 0x807fe21 in standalone_main ()
#18 0x8080460 in main ()
#19 0x8056adf in _start ()
I turned on the nontstop debugging. The output from where it seg faults
is as follows.
entering XML::Parser::Expat::parse
438: my $self = shift;
439: my $arg = shift;
440: croak Parse already in progress (Expat) if $self-{_State_};
441: $self-{_State_} = 1;
442: my $parser = $self-{Parser};
443: my $ioref;
444: my $result = 0;
446: if (defined $arg) {
447: if (ref($arg) and UNIVERSAL::isa($arg, 'IO::Handle')) {
455: eval {
456: $ioref = *{$arg}{IO};
456: $ioref = *{$arg}{IO};
-- end of output, seg fault here
XML/Parser.pm
455 sub Char {
456my $expat = shift;
457my $text = shift;
458my $class = ${$expat}{Pkg}::Characters;
459my $clist = $expat-{Curlist};
perl configure options:
-Dprefix=/server/local -Uusemymalloc -Ubincompat5005 -des
% perl -V
Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration:
Platform:
osname=solaris, osvers=2.8, archname=i86pc-solaris
uname='sunos x86-b 5.8 generic_108529-06 i86pc i386 i86pc '
config_args='-Dprefix=/server/local -Uinstallusrbinperl -Ubincompat5005 -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 ='-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'
ccversion='', gccversion='2.95.2 19991024 (release)', gccosandvers='solaris2.8'
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=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: USE_LARGE_FILES
Built under solaris
Compiled at Jul 20 2001 22:45:47
@INC:
/server/local/lib/perl5/5.6.1/i86pc-solaris
/server/local/lib/perl5/5.6.1
/server/local/lib/perl5/site_perl/5.6.1/i86pc-solaris
/server/local/lib/perl5/site_perl/5.6.1
/server/local/lib/perl5/site_perl
.
Re: segfault w/ Apache 1.3.20, mod_perl 1.26
Ged Haywood wrote: IIRC there was a problem with the compiler (gcc) that came with RH7.0, which compiler are you using? I'm using the patched version of GCC that RedHat later released, gcc-2.96-85. Dunno if it's relevant, but I see the following ChangeLog entry that might or might not be relevant to this problem (for mod_perl 1.25_01 - July 6, 2001): adjust perl_clear_symtab() to deal properly bleedperl's version of cv_undef() (which broke modules with directive handlers) thanks to Geoffrey Young for the spot On perl_clear_symtab() see below. Note that I tried both mod_perl 1.26 and 1.26_01, and both behave similarly. I.e., both coredump after handling all the commands in my Perl/Perl section. The coredump happens inside Perl_sv_free: #0 0x81fe1d2 in Perl_sv_free () #1 0x81d5e84 in Perl_cv_undef () #2 0x80acba9 in perl_clear_symtab () The message in my error_log file is: Attempt to free unreferenced scalar. Send us the output of perl -V and also the arguments you gave to Makefile.PL, then when they all get back from the conference maybe someone will have your answer. Ok, first the Makefile.PL args. I tried this various ways (e.g., with and without PERL_DEBUG; also, with just PERL_TRACE): SSL_BASE='/usr' perl Makefile.PL APACHE_SRC=/usr/local/src/apache/src USE_APACI=1 EVERYTHING=1 PERL_DEBUG=1 ADD_MODULE=all DO_HTTPD=1 APACI_ARGS='--enable-module=all' Here's my perl -V output: Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration: Platform: osname=linux, osvers=2.2.17-8smp, archname=i386-linux uname='linux porky.devel.redhat.com 2.2.17-8smp #1 smp fri nov 17 16:12:17 est 2000 i686 unknown ' config_args='-des -Doptimize=-O2 -march=i386 -mcpu=i686 -Dcc=gcc -Dcccdlflags=-fPIC -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux -Dd_dosuid -Dd_semctl_semun -Di_db -Di_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Uuselargefiles' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=undef use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef Compiler: cc='gcc', optimize='-O2 -march=i386 -mcpu=i686', gccversion=2.96 2731 (Red Hat Linux 7.1 2.96-78) cppflags='-fno-strict-aliasing' ccflags ='-fno-strict-aliasing' stdchar='char', d_stdstdio=define, usevfork=false intsize=4, longsize=4, ptrsize=4, doublesize=8 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=4 alignbytes=4, usemymalloc=n, prototype=define Linker and Libraries: ld='gcc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -ldl -lm -lc -lcrypt libc=/lib/libc-2.2.so, 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): Compile-time options: Built under linux Compiled at Apr 3 2001 11:27:33 @INC: /usr/lib/perl5/5.6.0/i386-linux /usr/lib/perl5/5.6.0 /usr/lib/perl5/site_perl/5.6.0/i386-linux /usr/lib/perl5/site_perl/5.6.0 /usr/lib/perl5/site_perl . Does this happen with a static build? Yes, indeed it does. -- Richard Goerwitz [EMAIL PROTECTED] tel: 401 438 8978
Re: segfault on subrequest?
On Thu, 15 Mar 2001, Pierre Phaneuf wrote:
I have a PerlTransHandler that is very simple:
the problem is likely that your trans handler is recursing. try adding
this to prevent recursion:
sub handler {
my($r) = @_;
return unless $r-is_main;
my($info);
$info = $r-lookup_file('/home/pp/pierre.jpg')-content_type();
warn(content type is $info\n);
return DECLINED;
}
But it causes a segfault when invoked... I removed the
-content_type(), so that I should normally see something like
Apache::SubRequest=SCALAR(0x815eb54), but it also crashes.
I tried using the exact same handler as a PerlHandler and as a
PerlHeaderParserHandler instead, and it works perfectly. I was thinking
that calling lookup_uri from within a PerlTransHandler might be a bad
idea (infinite loops!), but I would have thought that lookup_file would
be ok...
Okay, maybe everyone will jump in my face about this: this is on an
updated Red Hat 7.0 system, using Red Hat's Apache and mod_perl RPM
packages.
Re: Segfault on ppc-linux with modperl-1.25 with Apache 1.3.19 whencalling $r-send_fd()
On 19 Mar 2001, Mark Lipscombe wrote:
open ($FH, $fname);
...
$r-send_fd($FH);
you didn't check the return value of open(); patch below will check if
the filehandle is NULL and croak rather than segfault.
Index: src/modules/perl/Apache.xs
===
RCS file: /home/cvs/modperl/src/modules/perl/Apache.xs,v
retrieving revision 1.122
diff -u -r1.122 Apache.xs
--- src/modules/perl/Apache.xs 2001/06/14 04:36:21 1.122
+++ src/modules/perl/Apache.xs 2001/06/14 05:24:25
@@ -956,6 +956,10 @@
long length
CODE:
+if (!f) {
+croak(send_fd: NULL filehandle
+ (hint: did you check the return value of open?));
+}
RETVAL = send_fd_length(f, r, length);
OUTPUT:
Segfault question and possible workaround
Hello!
Some help and ideas are once again needed...
I'm quite a newbie with mod_perl, so there may be a totally
reasonable explanation to segfaults that follow from a few reloads.
It seems to me that subrequest and/or stat do not work together as
I thought.
##
[Tue May 8 12:32:08 2001] [notice] child pid 1357 exit signal Segmentation fault (11)
##
package Apache::WorkMates::AutoIndex;
use strict;
use Apache::Constants qw(:common DIR_MAGIC_TYPE);
sub handler {
my $r = shift;
return DECLINED unless $r-content_type and $r-content_type eq DIR_MAGIC_TYPE;
$r-send_http_header('text/plain');
opendir DIR, $r-filename;
my @filelist = readdir DIR;
closedir DIR;
foreach my $file (@filelist) {
my $subr = $r-lookup_file($r-filename . '/' . $file);
my $fstat = [ stat $subr-finfo ];
}
$r-print(Kukkuu!);
return OK;
}
1;
##
A very quick check with the following seems to fix it,
but I haven't tested it that much.
foreach ... {
my $real_file = $r-filename . '/' . $file;
my $fstat = [ stat $real_file ];
}
The first code is used in Apache::AutoIndex also, because
my own autoindex owns a lot to Philippe M. Chiasson (Thanks Philippe!).
So maybe some Apache::AutoIndex users have got similar segfaults?
Now there is some information about configuration:
##
diff httpd.conf.default httpd.conf
950a951,954
PerlModuleApache::WorkMates::AutoIndex
PerlHandler Apache::WorkMates::AutoIndex
##
gdb /usr/local/wm5/apache/bin/httpd
(gdb) run -X -f /usr/local/wm5/apache/conf/httpd.conf
Starting program: /usr/local/wm5/apache/bin/httpd -X -f
/usr/local/wm5/apache/conf/httpd.conf
Program received signal SIGSEGV, Segmentation fault.
0x8112181 in Perl_dounwind ()
(gdb) bt
#0 0x8112181 in Perl_dounwind ()
#1 0x811249c in Perl_die_where ()
#2 0x80ef440 in Perl_croak ()
#3 0x80fcb93 in Perl_sv_upgrade ()
#4 0x80ce0ad in Perl_gv_init ()
#5 0x80cf184 in Perl_gv_fetchpv ()
#6 0x8091689 in XS_Apache_finfo ()
#7 0x80fba4b in Perl_pp_entersub ()
#8 0x81277b0 in Perl_runops_standard ()
#9 0x80cb7c9 in perl_call_sv ()
#10 0x8084430 in perl_call_handler ()
#11 0x8083bc2 in perl_run_stacked_handlers ()
#12 0x8081fb0 in perl_handler ()
#13 0x809f799 in ap_invoke_handler ()
#14 0x80b40df in process_request_internal ()
#15 0x80b4146 in ap_process_request ()
#16 0x80ab086 in child_main ()
#17 0x80ab241 in make_child ()
#18 0x80ab3bc in startup_children ()
#19 0x80aba2c in standalone_main ()
#20 0x80ac25c in main ()
#21 0x2ab91dcc in __libc_start_main () from /lib/libc.so.6
(gdb)
##
Same compiler for perl, apache and mod_perl.
mod_perl-1.25
=
$WM5DIR/perl/bin/perl Makefile.PL \
PERL_DEBUG=1 \
EVERYTHING=1 \
APACHE_SRC=../$APACHEDIR/src \
DO_HTTPD=1 \
USE_APACI=1 \
APACI_ARGS='--enable-module=rewrite,--enable-module=so'
make make test make install
(make test 100% successful)
apache_1.3.19
=
./configure --prefix=$WM5DIR/apache \
--activate-module=src/modules/perl/libperl.a \
--enable-module=rewrite \
--enable-module=so \
--disable-rule=EXPAT
make
make install
perl5.005_03
Compiled with -Dprefix=/usr/local/wm5/perl -des -Uusrbinperl
perl -V
Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration:
Platform:
osname=linux, osvers=2.2.19, archname=i686-linux
uname='linux saphire.kas.utu.fi 2.2.19 #1 thu apr 5 15:18:02 est 2001 i686 unknown
'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef useperlio=undef d_sfio=undef
Compiler:
cc='cc', optimize='-O2', gccversion=2.95.2 2220 (Debian GNU/Linux)
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 -lgdbm -ldbm -ldb -ldl -lm -lc -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 May 8 2001 03:04:44
@INC:
/usr/local/wm5/perl/lib/5.00503/i686-linux
/usr/local/wm5/perl/lib/5.00503
/usr/local/wm5/perl/lib/site_perl/5.005/i686-linux
/usr/local/wm5/perl/lib/site_perl/5.005
.
--
Kari Nurmela,
[EMAIL PROTECTED], (02) 333 8847 / (0400) 786 547
Segfault on ppc-linux with modperl-1.25 with Apache 1.3.19 whencalling $r-send_fd()
Hi,
Apologies in advance for the length of this message.
I have two (apparently) identical setups, consisting of the following:
Apache 1.3.19 with php4, mod_ssl mod_perl compiled statically
Perl 5.6.0 (output of -V appears at the end of this message)
The only obvious difference is system A is i386-linux, and system B is
powerpc-linux.
Everything is fine on the i386 system, but this script on the PowerPC
causes a segfault without fail:
package Apache::LogoMikvas;
use strict;
use DBI ();
use File::Temp qw/ :POSIX /;
use vars qw($DBH);
use constant DBAUTH = 'root:fr3dcak3';
use constant MAX_TRIES = 10;
use Apache::Constants qw(:common);
sub handler {
my $r = shift;
my $DB = 'dbi:mysql:'.$ENV{DATABASE};
my %args = $r-args;
my ($www, $username, $domain) = split('\.', $r-header_in('Host'),
3);
unless ($username =~ /(\w+)/) {
Apache::LogoMikvas::FAILED("Non-sane input for /img/logo.gif:
$username");
}
my $DBH = DBI-connect($DB, split(':', DBAUTH, 2), {PrintError =
0})
|| Apache::LogoMikvas::FAILED($DBI::errstr);
my $find_logo = $DBH-prepare(END) ||
Apache::LogoMikvas::FAILED($DBI::errstr);
SELECT sites.sites_logo, date_format(sites_last_modified, '%W, %d %M %Y
%H:%i:%s') AS lms,
users.users_id
FROM users, sites
WHERE sites.sites_users_id = users.users_id
AND users.users_username = ?
END
$find_logo-execute($username) ||
Apache::LogoMikvas::FAILED($DBI::errstr);
my $find_logo_data = $find_logo-fetchrow_hashref ||
Apache::LogoMikvas::FAILED($DBI::errstr);
$find_logo-finish;
$r-no_cache(1);
$r-content_type('image/gif');
$r-send_http_header;
if ($find_logo_data-{sites_logo}) {
my ($FH, $fname);
$fname = $ENV{IMAGE_PATH} . $find_logo_data-{sites_logo};
open ($FH, $fname);
#$r-print("Filename we're trying to read: $fname\n");
$r-send_fd($FH);
#$r-print($find_logo_data-{sites_logo});
} else {
$r-printf("%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%",
71,73,70,56,57,97,1,0,1,0,128,255,0,192,192,192,0,0,0,33,249,4,1,0,0,0,0,44,0,0,0,0,1,0,1,0,0,2,2,68,1,0,59);
}
return OK;
}
sub FAILED {
my $errstr = shift;
die($errstr);
Apache::exit();
}
1;
The segfault occurs when $r-send_fd is called, the following is a stack
trace from running httpd -X and
requesting the URL in question:
Program received signal SIGSEGV, Segmentation fault.
0x1622664 in _IO_sgetn () at genops.c:365
365 genops.c: No such file or directory.
(gdb) bt
#0 0x1622664 in _IO_sgetn () at genops.c:365
#1 0x161cb38 in fread () at iofread.c:46
#2 0x188a71c in ap_send_fd_length ()
#3 0x1858530 in XS_Apache_send_fd ()
#4 0x193f694 in Perl_pp_entersub ()
#5 0x19386c4 in Perl_runops_standard ()
#6 0x18ee0d4 in S_call_body ()
#7 0x18edde4 in perl_call_sv ()
#8 0x184bfac in perl_call_handler ()
#9 0x184b7b4 in perl_run_stacked_handlers ()
#10 0x1849bb4 in perl_handler ()
#11 0x18731b0 in ap_invoke_handler ()
#12 0x188f09c in process_request_internal ()
#13 0x188f12c in ap_process_request ()
#14 0x1883adc in child_main ()
#15 0x1883cfc in make_child ()
#16 0x1883ed4 in startup_children ()
#17 0x1884754 in standalone_main ()
#18 0x18850bc in main ()
#19 0x15eb77c in __libc_start_main ()
at ../sysdeps/powerpc/elf/libc-start.c:107
#20 0x0 in ?? ()
If comment out the send_fd, it works fine.
Here is the output of perl -V:
Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration:
Platform:
osname=linux, osvers=2.4.3-pre4, archname=ppc-linux
uname='linux devbox 2.4.3-pre4 #1 thu mar 15 16:44:38 est 2001 ppc
unknown 'config_args=''
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=undef
useperlio=undef d_sfio=undef uselargefiles=define
use64bitint=undef use64bitall=undef uselongdouble=undef
usesocks=undef
Compiler:
cc='gcc', optimize='-O2', gccversion=2.95.2 19991024 (release)
cppflags='-fno-strict-aliasing -I/usr/local/include'
ccflags ='-fno-strict-aliasing -I/usr/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'
stdchar='char', d_stdstdio=define, usevfork=false
intsize=4, longsize=4, ptrsize=4, doublesize=8
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8
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 =''
libpth=/lib /usr/lib
libs=-lnsl -lndbm -lgdbm -ldbm -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'
Characteristics of this binary (from libperl):
Compile-time options: USE_LARGE_FILES
Built under linux
Compiled
segfault on subrequest?
I have a PerlTransHandler that is very simple:
sub handler {
my($r) = @_;
my($info);
$info = $r-lookup_file('/home/pp/pierre.jpg')-content_type();
warn("content type is $info\n");
return DECLINED;
}
But it causes a segfault when invoked... I removed the
"-content_type()", so that I should normally see something like
"Apache::SubRequest=SCALAR(0x815eb54)", but it also crashes.
I tried using the exact same handler as a PerlHandler and as a
PerlHeaderParserHandler instead, and it works perfectly. I was thinking
that calling lookup_uri from within a PerlTransHandler might be a bad
idea (infinite loops!), but I would have thought that lookup_file would
be ok...
Okay, maybe everyone will jump in my face about this: this is on an
updated Red Hat 7.0 system, using Red Hat's Apache and mod_perl RPM
packages.
--
Pierre Phaneuf
http://www3.sympatico.ca/pphaneuf/
Apache, mod_perl, mysql, php segfault!
Hello, anyone come across a problem where they get "exit signal Segmentation fault (11)" when they try to connect to mysql via mod_perl? I am getting it even on simple connect and disconnect - I can access Oracle via mod_perl. Neither standard standalone scripts or php have problems communicating to mysql.I heard something that there could be some sort of static linking problem with mysql when apache has both php and mod_perl modules activated. Any ideas would be greatly appreciated as I am stumped. I am using apache 1.3.12, mod_perl 1.25, php 4.0.3pl1 and mysql 3.23.33 from mydbi trace log: DBI 1.14-nothread dispatch trace level set to 4 Note: perl is running without the recommended perl -w option - DBI-connect(DBI:mysql:test;host=localhost, root, ) - DBI-install_driver(mysql) for perl=5.00503 pid=27862 ruid=99 euid=99 install_driver: DBD::mysql loaded (version 2.0415) New DBI::dr (for DBD::mysql::dr, parent=, id=) dbih_setup_handle(DBI::dr=HASH(0x8459418)=DBI::dr=HASH(0x83dbbc8), DBD::mysql::dr, 0, Null!) dbih_make_com(Null!, DBD::mysql::dr, 84) - install_driver= DBI::dr=HASH(0x8459418) - connect for DBD::mysql::dr (DBI::dr=HASH(0x8459418)~0x83dbbc8 'test;host=localhost' 'root' HASH(0x8432474)) New DBI::db (for DBD::mysql::db, parent=DBI::dr=HASH(0x83dbbc8), id=HASH(0x84329c8)) dbih_setup_handle(DBI::db=HASH(0x82a83c8)=DBI::db=HASH(0x836db54), DBD::mysql::db, 82c3a10, HASH(0x84329c8)) dbih_make_com(DBI::dr=HASH(0x83dbbc8), DBD::mysql::db, 520) = 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/
Re: Apache, mod_perl, mysql, php segfault!
On Mon, 5 Mar 2001, Michael Turley wrote: Hello, anyone come across a problem where they get "exit signal Segmentation fault (11)" when they try to connect to mysql via mod_perl? This is a known issue IIRC. Simply re-compile PHP without the built-in MySQL support (you can still connect to MySQL). -- 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 ** \\// //\\ // \\
DBI-connect SegFault blues
I've been writing a handler on a test box which uses the DBI-connect method, no problem, only my Perl authoring skills are at fault. Its based on Slackware 7.1, with Apache 1.3.14, mod_perl 1.24_01, and mod_ssl 2.7.1. I have DBI 1.14 and msql-mysql 1.2215 with Perl 5.6.0. MySQL version is 3.22.32. Once I got this satisfactory, I transferred it to the "production" box, which is running the same versions of everything, except it also has PHP 4.0.4pl1 and also mod_gzip 1.3.14.6e. Apart from that it has the same versions of everything, same base distro too. On this box, I'm getting the behaviour noted by a few other posts I've read on the archive. This is the DBI-connect leading to a segfault with little or no useful information in the logs. I've gone through the archive, and I can't find any solution apart from a source hack which is advised against. Is there any other solution to this problem? I can't down the production apache box without good cause as apart from my handler, the box is behaving as expected. BTW I can write trivial DBI scripts which when run from a shell, work fine, it's just when run under a handler (.pm). Any pointers are appreciated Thanks Matt
Re: mod_perl segfault
Doug MacEachern wrote: snipped ... it would probably be worth your while to try 5.6.1-trial1. Where does one download that? I have those in my logs, one more bug to kill. Someday, I'll go 24 hours without adding to my error logs, but that day won't happen too soon ... --Christopher Everett
Re: mod_perl segfault
On Sat, 17 Feb 2001, Christopher L. Everett wrote: Doug MacEachern wrote: snipped ... it would probably be worth your while to try 5.6.1-trial1. Where does one download that? I have those in my logs, one more bug to kill. Someday, I'll go 24 hours without adding to my error logs, but that day won't happen too soon ... TRIAL2 is the latest, I use it without any problems so far: http://public.activestate.com/gsar/perl-5.6.1-TRIAL2.tar.gz _ 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: Segfault: apache-1.3.17+modperl-1.25
Hmm, have you built mod_perl with PERL_USELARGEFILES=0? I've got almost the same set up (RH7) running just fine. On Wed, 14 Feb 2001, Gary Algier wrote: My children are segfaulting. I have: Solaris 2.6 (w/all latest patches installed right after the OS) Perl 5.6.0 (no largefiles, no threads) Apache 1.3.17 modperl 1.25 (as a DSO) gcc 2.95.2 (using Sun's as and ld) If I run apache leaving out: LoadModule perl_modulelibexec/libperl.so AddModule mod_perl.c it runs just fine. Put them in and the child seg faults. I did manage to gdb the process and it says: Program received signal SIGSEGV, Segmentation fault. 0xef0a2e00 in perl_header_parser () (gdb) where #0 0xef0a2e00 in perl_header_parser () #1 0x20714 in run_method () #2 0x208e4 in ap_header_parse () #3 0x3d9bc in process_request_internal () #4 0x3ded0 in ap_process_request () #5 0x314c8 in child_main () #6 0x31854 in make_child () #7 0x31dcc in perform_idle_server_maintenance () #8 0x32630 in standalone_main () #9 0x32f64 in main () Unfortunately, there are no debugging symbols so it is limited. It wasn't easy getting this, though if it would help I will endeavor to rebuild everything with debugging symbols and try again. In general, I know that DSOs are working as I runtime load the max. I also load php 4.0.4pl1 that way and it works. Any ideas? Does the trace help? -- Gary Algier, WB2FWZ [EMAIL PROTECTED] +1 856 787 2758 Ulticom Inc., 1020 Briggs Rd, Mt. Laurel, NJ 08054 Fax:+1 856 866 2033 A self-addressed envelope would be addressed "envelope."
Re: DBI+mod_perl SegFault!
Just to update this... The problem was with the detail I omitted below: PHP4.
The php.net buglist indicates that PHP 4.0.4 may fix the problem, but that is
the version I have - so I think it is still an open issue, even with PHP 4.0.4.
I'll report this to PHP.net so they are aware.
However, if anyone else is having this problem, reverting to PHP3 solved it for
me. And, in my case, was a trivial and painless process.
Thanks to all who mailed me great comments. After 2.5 days of tracking this
little issue down, I was about to lose all control ;) You all really helped
out.
Thanks,
-Eric.
Eric Peters wrote:
Hi all-
I'm really having a problem I hope I might be able to get some help
with. I'm using Apache 1.3.14, mod_perl 1.24, DBI 1.14, MySQL Modules 1.2215,
Perl 5.6.0, and MySQL 3.22.32. (I think that's all that's relevant)
In my httpd.conf I have the following:
#--
Location /testing
SetHandler perl-script
PerlHandler Testing
/Location
#--
And I have a script called Testing.pm that looks like this:
#--
package Testing;
use strict;
use DBI;
sub handler {
print "Content-type:\n\nhtmlheadtitletest/title/headbodypre";
print "Getting Data Sources...\n";
my @drivers = DBI-data_sources('mysql');
print "Done Getting Data Sources...\n";
foreach my $foo (@drivers) {
print "DataSource- $foo \n";
}
print "Getting Data Sources Complete...\n";
print "/pre/body/html\n";
}
1;
#--
Consistantly, I get a SegFault when going to /testing. Using strace, I see
that it actually calls DBI and gets the valid results. Everything looks good
to me, but it dies after closing the FD.
The funny thing is, if I modify the Testing.pm module to be test.pl, it works.
#--
#package Testing;
use strict;
use DBI;
#sub handler {
print "Content-type:\n\nhtmlheadtitletest/title/headbodypre";
print "Getting Data Sources...\n";
my @drivers = DBI-data_sources('mysql');
print "Done Getting Data Sources...\n";
foreach my $foo (@drivers) {
print "DataSource- $foo \n";
}
print "Getting Data Sources Complete...\n";
print "/pre/body/html\n";
#}
#1;
#--
Anybody have any ideas? I've tried everything I can come up with.
Thanks,
-Eric.
DBI+mod_perl SegFault!
Hi all-
I'm really having a problem I hope I might be able to get some help
with. I'm using Apache 1.3.14, mod_perl 1.24, DBI 1.14, MySQL Modules 1.2215,
Perl 5.6.0, and MySQL 3.22.32. (I think that's all that's relevant)
In my httpd.conf I have the following:
#--
Location /testing
SetHandler perl-script
PerlHandler Testing
/Location
#--
And I have a script called Testing.pm that looks like this:
#--
package Testing;
use strict;
use DBI;
sub handler {
print "Content-type:\n\nhtmlheadtitletest/title/headbodypre";
print "Getting Data Sources...\n";
my @drivers = DBI-data_sources('mysql');
print "Done Getting Data Sources...\n";
foreach my $foo (@drivers) {
print "DataSource- $foo \n";
}
print "Getting Data Sources Complete...\n";
print "/pre/body/html\n";
}
1;
#--
Consistantly, I get a SegFault when going to /testing. Using strace, I see
that it actually calls DBI and gets the valid results. Everything looks good
to me, but it dies after closing the FD.
The funny thing is, if I modify the Testing.pm module to be test.pl, it works.
#--
#package Testing;
use strict;
use DBI;
#sub handler {
print "Content-type:\n\nhtmlheadtitletest/title/headbodypre";
print "Getting Data Sources...\n";
my @drivers = DBI-data_sources('mysql');
print "Done Getting Data Sources...\n";
foreach my $foo (@drivers) {
print "DataSource- $foo \n";
}
print "Getting Data Sources Complete...\n";
print "/pre/body/html\n";
#}
#1;
#--
Anybody have any ideas? I've tried everything I can come up with.
Thanks,
-Eric.
Segfault: apache-1.3.17+modperl-1.25
My children are segfaulting. I have: Solaris 2.6 (w/all latest patches installed right after the OS) Perl 5.6.0 (no largefiles, no threads) Apache 1.3.17 modperl 1.25 (as a DSO) gcc 2.95.2 (using Sun's as and ld) If I run apache leaving out: LoadModule perl_modulelibexec/libperl.so AddModule mod_perl.c it runs just fine. Put them in and the child seg faults. I did manage to gdb the process and it says: Program received signal SIGSEGV, Segmentation fault. 0xef0a2e00 in perl_header_parser () (gdb) where #0 0xef0a2e00 in perl_header_parser () #1 0x20714 in run_method () #2 0x208e4 in ap_header_parse () #3 0x3d9bc in process_request_internal () #4 0x3ded0 in ap_process_request () #5 0x314c8 in child_main () #6 0x31854 in make_child () #7 0x31dcc in perform_idle_server_maintenance () #8 0x32630 in standalone_main () #9 0x32f64 in main () Unfortunately, there are no debugging symbols so it is limited. It wasn't easy getting this, though if it would help I will endeavor to rebuild everything with debugging symbols and try again. In general, I know that DSOs are working as I runtime load the max. I also load php 4.0.4pl1 that way and it works. Any ideas? Does the trace help? -- Gary Algier, WB2FWZ [EMAIL PROTECTED] +1 856 787 2758 Ulticom Inc., 1020 Briggs Rd, Mt. Laurel, NJ 08054 Fax:+1 856 866 2033 A self-addressed envelope would be addressed "envelope."
Re: Segfault: apache-1.3.17+modperl-1.25
did u compile the perl, apache and mod_perl all with the same compiler, assembler and linker?? you may want to search in the archives: solaris dso sigsegv i remember quite a few issues a while back. hth, -- ___cliff [EMAIL PROTECTED]http://www.genwax.com/ Gary Algier wrote: My children are segfaulting. I have: Solaris 2.6 (w/all latest patches installed right after the OS) Perl 5.6.0 (no largefiles, no threads) Apache 1.3.17 modperl 1.25 (as a DSO) gcc 2.95.2 (using Sun's as and ld) If I run apache leaving out: LoadModule perl_modulelibexec/libperl.so AddModule mod_perl.c it runs just fine. Put them in and the child seg faults. I did manage to gdb the process and it says: Program received signal SIGSEGV, Segmentation fault. 0xef0a2e00 in perl_header_parser () (gdb) where #0 0xef0a2e00 in perl_header_parser () #1 0x20714 in run_method () #2 0x208e4 in ap_header_parse () #3 0x3d9bc in process_request_internal () #4 0x3ded0 in ap_process_request () #5 0x314c8 in child_main () #6 0x31854 in make_child () #7 0x31dcc in perform_idle_server_maintenance () #8 0x32630 in standalone_main () #9 0x32f64 in main () Unfortunately, there are no debugging symbols so it is limited. It wasn't easy getting this, though if it would help I will endeavor to rebuild everything with debugging symbols and try again. In general, I know that DSOs are working as I runtime load the max. I also load php 4.0.4pl1 that way and it works. Any ideas? Does the trace help?
Re: Segfault: apache-1.3.17+modperl-1.25
On Wed, 14 Feb 2001, Gary Algier wrote: My children are segfaulting. I have: Solaris 2.6 (w/all latest patches installed right after the OS) Perl 5.6.0 (no largefiles, no threads) Apache 1.3.17 modperl 1.25 (as a DSO) gcc 2.95.2 (using Sun's as and ld I had same problems. Try to compile mod_perl statically. Works fine. If I run apache leaving out: LoadModule perl_modulelibexec/libperl.so AddModule mod_perl.c it runs just fine. Put them in and the child seg faults. I did manage to gdb the process and it says: Program received signal SIGSEGV, Segmentation fault. 0xef0a2e00 in perl_header_parser () (gdb) where #0 0xef0a2e00 in perl_header_parser () #1 0x20714 in run_method () #2 0x208e4 in ap_header_parse () #3 0x3d9bc in process_request_internal () #4 0x3ded0 in ap_process_request () #5 0x314c8 in child_main () #6 0x31854 in make_child () #7 0x31dcc in perform_idle_server_maintenance () #8 0x32630 in standalone_main () #9 0x32f64 in main () Unfortunately, there are no debugging symbols so it is limited. It wasn't easy getting this, though if it would help I will endeavor to rebuild everything with debugging symbols and try again. In general, I know that DSOs are working as I runtime load the max. I also load php 4.0.4pl1 that way and it works. Any ideas? Does the trace help? -- Gary Algier, WB2FWZ [EMAIL PROTECTED] +1 856 787 2758 Ulticom Inc., 1020 Briggs Rd, Mt. Laurel, NJ 08054 Fax:+1 856 866 2033 A self-addressed envelope would be addressed "envelope." Vasily Petrushin +7 (095) 2508363 http://www.interfax.ru mailto:[EMAIL PROTECTED]
Config directives segfault
Under mod_perl 1.25 I get segfaults related to config directives. I
tracked this down to perl_config.c, perl_perl_create_cfg, where the values
of PERL_DIR_CREATE (or PERL_SERVER_CREATE) had been overwritten or
something (gdb said "Out of bounds" for the type variable).
In AxKit.xs (generated by Apache::ExtUtils) I had:
BOOT:
XS_AxKit.name = "AxKit";
add_module(XS_AxKit);
stash_mod_pointer("AxKit", XS_AxKit);
register_cleanup(perl_get_startup_pool(), (void *)1,
remove_module_cleanup, null_cleanup);
If I commented out the last two lines there (because they were the only
difference I could see from older mod_perls), the segfaults went away.
For those wondering, this has been the cause of Take23 (and AxKit.com|org)
outages this weekend. Many appologies.
--
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: mod_perl segfault
On Sun, 10 Dec 2000, Alex Vandiver wrote: Heya -- Please 'scuse in advance the long post -- it had to be to fit in all of the information asked for (better too much than too little, I hope). Anyways, I've run into an intermittent segfault problem with mod_perl (Version 1.24). It causes the Apache (version 1.3.12) process to die: [Sun Dec 10 03:12:10 2000] [notice] child pid 18227 exit signal Segmentation fault (11) your stacktrace looks like one triggered by a 5.6.0 bug(s) that we've seen here a number of times. it would probably be worth your while to try 5.6.1-trial1.
mod_perl segfault
Heya -- Please 'scuse in advance the long post -- it had to be to fit in all of the information asked for (better too much than too little, I hope). Anyways, I've run into an intermittent segfault problem with mod_perl (Version 1.24). It causes the Apache (version 1.3.12) process to die: [Sun Dec 10 03:12:10 2000] [notice] child pid 18227 exit signal Segmentation fault (11) Here's my perl -V: Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration: Platform: osname=linux, osvers=2.2.12-20, archname=i586-linux uname='linux melnorme 2.2.12-20 #1 mon sep 27 10:25:54 edt 1999 i586 unknown ' config_args='-s' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=define use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef Compiler: cc='cc', optimize='-O2', gccversion=egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) cppflags='-fno-strict-aliasing -I/usr/local/include' ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64' stdchar='char', d_stdstdio=define, usevfork=false intsize=4, longsize=4, ptrsize=4, doublesize=8 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=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lc -lposix -lcrypt libc=/lib/libc-2.1.2.so, 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): Compile-time options: USE_LARGE_FILES Built under linux Compiled at Sep 6 2000 23:47:54 @INC: /usr/local/lib/perl5/5.6.0 /usr/local/lib/perl5/site_perl/5.6.0 /usr/local/lib/perl5/site_perl/5.6.0 /usr/local/lib/perl5/site_perl As I said above, this is mod_perl 1.24, running under Apache 1.3.12 The same error also happened with Apache 1.3.9, however. I built mod_perl with: perl Makefile.PL APACHE_PREFIX=/usr/local/apache APACHE_SRC=../apache_1.3.14/src DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 APACI_ARGS='--with-layout=RedHat --verbose' PERL_DEBUG=1 I caught a backtrace of the segfault: (gdb) run -X -D -f `pwd`/t/conf/httpd.conf -d `pwd`/t Starting program: /usr/src/redhat/SOURCES/mod_perl-1.24_01/../apache_1.3.14/src/httpd -X -D -f `pwd`/t/conf/httpd.conf -d `pwd`/t Program received signal SIGSEGV, Segmentation fault. 0x400cade7 in Perl_sv_setsv () from /usr/local/lib/perl5/5.6.0/CORE/libperl.so (gdb) bt #0 0x400cade7 in Perl_sv_setsv () from /usr/local/lib/perl5/5.6.0/CORE/libperl.so #1 0x400c09e8 in Perl_pp_sassign () from /usr/local/lib/perl5/5.6.0/CORE/libperl.so #2 0x400c052d in Perl_runops_standard () from /usr/local/lib/perl5/5.6.0/CORE/libperl.so #3 0x4007e36a in S_call_body () from /usr/local/lib/perl5/5.6.0/CORE/libperl.so #4 0x4007de2d in perl_call_sv () from /usr/local/lib/perl5/5.6.0/CORE/libperl.so #5 0x400b5230 in Perl_vdie () from /usr/local/lib/perl5/5.6.0/CORE/libperl.so #6 0x400b5391 in Perl_die () from /usr/local/lib/perl5/5.6.0/CORE/libperl.so #7 0x400e91dd in Perl_pp_require () from /usr/local/lib/perl5/5.6.0/CORE/libperl.so #8 0x400c052d in Perl_runops_standard () from /usr/local/lib/perl5/5.6.0/CORE/libperl.so #9 0x4007e36a in S_call_body () from /usr/local/lib/perl5/5.6.0/CORE/libperl.so #10 0x4007e0ab in perl_call_sv () from /usr/local/lib/perl5/5.6.0/CORE/libperl.so #11 0x40080f1e in S_call_list_body () from /usr/local/lib/perl5/5.6.0/CORE/libperl.so #12 0x40080bcc in Perl_call_list () from /usr/local/lib/perl5/5.6.0/CORE/libperl.so #13 0x400a2f85 in Perl_newATTRSUB () from /usr/local/lib/perl5/5.6.0/CORE/libperl.so #14 0x400a0087 in Perl_utilize () from /usr/local/lib/perl5/5.6.0/CORE/libperl.so #15 0x400993cd in Perl_yyparse () from /usr/local/lib/perl5/5.6.0/CORE/libperl.so #16 0x400e82a3 in S_doeval () from /usr/local/lib/perl5/5.6.0/CORE/libperl.so #17 0x400e99c3 in Perl_pp_entereval () from /usr/local/lib/perl5/5.6.0/CORE/libperl.so #18 0x400c052d in Perl_runops_standard () from /usr/local/lib/perl5/5.6.0/CORE/libperl.so #19 0x4007e36a in S_call_body () from /usr/local/lib/perl5/5.6.0/CORE/libperl.so #20 0x4007e0ab in perl_call_sv () from /usr/local/lib/perl5/5.6.0/CORE/libperl.so #21 0x8070deb in perl_call_handler (sv=0x86355f4, r=0x864bd44, args=0x0) at mod_perl.c:1663 #22 0x80705fb in perl_run_stacked_handlers (hook=0x80ba419 "PerlHandler", r=0x864bd44, handlers=0x8638c70) at mod_perl.c:1382 #23 0x806eb9d in perl_handler (r=0x864bd44) at mod_perl.c:908 #24 0x808b563 in ap_invoke_handler (r=0x864bd44) at http_config.c:516 #25
SegFault with Apache::Include
I am having some problems with Apache::Include.
When I include more than one file with it, the httpd seg faults.
The script can be as simple as this:
#!/usr/bin/perl
use Apache::Include ();
print "Content-type: text/html\n\n";
Apache::Include-virtual('/perl-bin/helloworld');
Apache::Include-virtual('/perl-bin/helloworld');
Where /perl-bin/helloworld only prints "Hello World".
This gives me
[notice] child pid 588 exit signal Segmentation fault (11)
It works fine when I only include one script.
I've been trying to trace and debug, but I get nowhere.
Do anyone know a solution for this?
I'm using Apache/1.3.12 , Linux
Thanks in advance / Magnus
segfault hell
I'm running current Apache and mod_perl 1.24. Solaris 2.6. 2G RAM.
PerlFreshRestart is off.
I've had these segfaults for months. I only get a few a day out of say
20,000 mod_perl requests. So the children come and go before I can get
strace or gdb on them.
They often happen in groups -- as if something funky happens to the OS and
a few segfault all at once. It's not the URI that's triggering the
segfault, and I've never been able to trigger it myself. It can happend
after just a few requests to a httpd child, or after many requests to a child.
Any other ideas on how to catch this in action without generating a huge
log file? Set MaxRequestsPerChild huge and attach gdb to every child?
Undefined subroutine Apache::RegistryNG-handler::handler called at
/usr/local/lib/perl5/site_perl/5.005/sun4-solaris/Apache.pm line 184.
Then that child may server up a few more static files, but next time
there's a mod_perl request:
Can't locate object method "handler" via package "handler" at
/usr/local/lib/perl5/site_perl/5.005/sun4-solaris/Apache.pm line 184.
I am using a $SIG{__DIE__} handler in my Registry script, which just writes
to a log file and calls (the overridden) exit.
Bill Moseley
mailto:[EMAIL PROTECTED]
Re: Segfault Apache1.3.12/mod_perl1.24/Solaris2.6
On Mon, 19 Jun 2000, G.W. Haywood wrote:
Hi Eric,
[Fri Jun 16 17:20:21 2000] [notice] \
child pid 22310 exit signal Segmentation Fault (11)
On Mon, 19 Jun 2000, Eric Cholet wrote:
backtrace.
(gdb) bt
#0 0x2b444 in perl_handler_ismethod ()
#1 0x2c43c in perl_call_handler ()
#2 0x2bd5c in perl_run_stacked_handlers ()
#3 0x29920 in perl_handler ()
#4 0x7fce8 in ap_invoke_handler ()
#5 0x9bdfc in ap_some_auth_required ()
#6 0x9be7c in ap_process_request ()
#7 0x8fbac in ap_child_terminate ()
#8 0x8fe14 in ap_child_terminate ()
#9 0x90014 in ap_child_terminate ()
#10 0x908f4 in ap_child_terminate ()
#11 0x914a0 in main ()
Curiously enough, Apache::Registry seems to run ok with a simple
"Hello world" type of script. Stay tuned.
if you haven't tried already, this bug has been fixed in cvs for quite a
while:
fix for 'sub handler : method {}' support when method is not found
[Eric Cholet [EMAIL PROTECTED]]
Re: Segfault in perl_handler_ismethod
On Mon, 26 Jun 2000, Rich Williams wrote:
Hi,
Linux 2.2.14, Apache 1.3.12, Perl 5.6.0, mod_perl 1.24.
On the first request, I get a segfault after perl_handler_ismethod
is called.
#0 0x40280fdc in mod_perl_register_cleanup (r=0x92ba3fc, sv=0x1) at mod_perl.c:1242
#1 0x40280fb0 in perl_handler_ismethod (pclass=0x92ba3fc, sub=0x1 Address 0x1 out
of bounds) at mod_perl.c:1236
this is a strange looking stacktrace, but this might be fixed in cvs with
this change:
fix for 'sub handler : method {}' support when method is not found
[Eric Cholet [EMAIL PROTECTED]]
segfault from Apache::Cookie and Apache::SSI
I'm getting repeatable segfaults (every time) by feeding a simple file to
Apache::SSI. It does a virtual include and then calls a perl sub that
creates a new Apache::Cookie object, at which point it segfaults. I've
reduced my test case to this:
!--#include virtual="foo.shtml"--
!--#perl sub="sub { my $cookie =
Apache::Cookie-new(Apache-request) }"--
It doesn't matter what's in foo.shtml (right now I have a single "X"), but
it does matter that it gets handled by Apache::SSI. If foo.shtml is not
handled by Apache::SSI, everything is fine.
I'm trying to reduce my test further, but does anyone have any ideas of
what I should look at? I'm running perl 5.005, Apache 1.3.12,
mod_perl 1.24, Apache::SSI 2.13, Apache::Cookie 0.01 (from libapreq 0.31)
on Linux (Red Hat 6.2).
- Perrin
Re: segfault from Apache::Cookie and Apache::SSI
Hi Perrin, On Thu, 10 Aug 2000, Perrin Harkins wrote: I'm getting repeatable segfaults (every time) by feeding a simple file to Apache::SSI. DSO or static? 73, Ged.
Re: segfault from Apache::Cookie and Apache::SSI
Hi again Perrin, On Thu, 10 Aug 2000, Perrin Harkins wrote: I'm using Red Hat's Perl RPM, but Apache/mod_perl is compiled from source. What compiler(s)? 73, Ged.
