Re: mod_perl and GD.pm segfault

[Stas Bekman]

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

mod_perl and GD.pm segfault

[Jason]

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: [mp2] segfault when connect to database

[Stas Bekman]

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

[Stas Bekman]

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

RE: [mp2] segfault when connect to database

[Marc M. Adkins]

> 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

[mp2] segfault when connect to database

[Danil Pismenny]

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: modperl segfault with threaded Perl 5.8

[Stas Bekman]

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

[Pavel Hlavnicka]

>> 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

[Stas Bekman]

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

[Pavel Hlavnicka]

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:


SetHandler perl-script
PerlHandler Apache::Registry
Options ExecCGI
allow from all


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]

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 "
#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 "
#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:


SetHandler perl-script
PerlHandler Apache::Registry
Options ExecCGI
allow from all


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

[Pavel Hlavnicka]

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:


SetHandler perl-script
PerlHandler Apache::Registry
Options ExecCGI
allow from all


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

[Stas Bekman]

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:


SetHandler perl-script
PerlHandler Apache::Registry
Options ExecCGI
allow from all


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

modperl segfault with threaded Perl 5.8

[Pavel Hlavnicka]

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:


	SetHandler perl-script
	PerlHandler Apache::Registry
	Options ExecCGI
	allow from all


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: mod_perl 2.0 and print/send_http_header method SEGFAULT

[Stas Bekman]

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

[Jérôme Augé]

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
  
Order deny,allow
Deny from all
Allow from localhost
  


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 = "plop";

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_SOURC

Re: mod_perl 2.0 and print/send_http_header method SEGFAULT

[Stas Bekman]

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

[Stas Bekman]

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é]

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é]

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

[Stas Bekman]

Jérôme Augé wrote:

On Tue, Jan 14, 2003 at 12:32:29PM +1100, Stas Bekman wrote:



   SetHandler perl-script
   PerlHeaderParserHandler Apache::Plop




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.


Ah sorry, I've missed the Trans part and tried it as Response handler.


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


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
__
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é]

On Tue, Jan 14, 2003 at 12:32:29PM +1100, Stas Bekman wrote:
> 
> 
> SetHandler perl-script
> PerlHeaderParserHandler Apache::Plop
> 
> 

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

[Stas Bekman]

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

Re: mod_perl 2.0 and print/send_http_header method SEGFAULT

[Stas Bekman]

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:


SetHandler perl-script
PerlHeaderParserHandler Apache::Plop


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&quo

mod_perl 2.0 and print/send_http_header method SEGFAULT

[Jérôme Augé]

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)

Thanks for your help,
Jérôme

-- 


package Apache::Plop;

use strict;
use Apache::RequestRec;
use Apache::RequestIO;
use Apache::RequestUtil;
use Apache::Const;
use Apache::ServerUtil;
use Apache::Response;
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";

# -->
# if I use this push_handlers, I never reach the "proxy_handler" sub
# So I commented it out and tried to do the work directly in "handler"

#$r->handler("perl-script"); #ok, let's do it   
#$r->push_handlers(PerlHandler => \&proxy_handler); 
#}
#
#sub proxy_handler {
#my $r = shift;

# <--

if( $r->method ne "GET" ) {
return Apache::DECLINED;
}
print STDERR "Good, this is a GET method ...\n";

# prepare the "real" request
my $request = HTTP::Request->new( $r->method, $r->uri );

# copy headers from client request
my %headers_in;
print STDERR "-- client headers --\n";
$r->headers_in()->do(
sub {
print STDERR "$_[0]: $_[1]\n";
$headers_in{$_[0]} = $_[1];
$request->header( {$_[0]}, $_[0] );
}
);
print STDERR "-- end --\n";

# make the "real" request myself
$ua->agent( $headers_in{ 'User-Agent' } );
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 = "plop";

# 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{$_};
}
$r->content_type( $headers_out{ 'Content-type' } );

print STDERR "-- send/print --\n";

# -->
# here is where the SEGFAULT occurs

$r->send_http_header();
$r->print( $content );

# I don't know how to write a content back to the client :(
# <--

print STDERR "-- end --\n";

return Apache::OK;
}

1;

Re: segfault after HTTP_MOVED_* and set_handlers()

[Geoffrey Young]

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()

[Stefano]

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:
  
   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()

[Stefano]

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:
  
   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()

[Stefano]

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:
  
   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: AB Segfault on mod_perl Handler

[Stas Bekman]

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

AB Segfault on mod_perl Handler

[Richard Clarke]

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.

[mp2] segfault deleting ENV variable

[Bradley Baetz]

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?

[Phil Lobbes]

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

[Phil Lobbes]

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 , 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 ,
srv_cb=0x7f68512a ) 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

[Doug MacEachern]

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

[Phil Lobbes]

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 , 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 ,
srv_cb=0x7f68512a ) 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 Linking:
dlsrc=dl_hpux.xs, dlext=sl, d_dlsymun=undef, ccdlf

Re: Fascinating segfault at Apache startup

[Chip Turner]

"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

[Jeremy Weatherford]

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

[E Kolve]

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

[Ernest Lergon]

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 *snip*

[Stas Bekman]

darren chamberlain wrote:
> * 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.  :)

Probably yes, let's wait for Kevin to reply. It wasn't supposed to be 
run as registry. thanks for the catch darren!


__
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]

[Stas Bekman]

Mark Fowler wrote:
> 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.

The Inline->init; is supposed to do that at require() time

I guess Inline could have provided a better diagnostics, but again I'm 
not in sync with the latest versions, which may do that already. 
probably a question for the Inline mailing list.

>>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?

you can precompile all the code before the server starts, and then have 
this dir readonly.
To precompile simple do:

  perl -Mmodule_with_inline_code -e1
of course assuming that you've explicitly set the Inline build dir in 
your code, like in my example.

__
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 *snip*

[darren chamberlain]

* 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

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]

[Mark Fowler]

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 MONTHS after compilation on multipleservers all compiled the same running different code and different RedhatReleased all on the same day [BUG]

[Stas Bekman]

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 multiple servers all compiled the same running different code and different Redhat Released all on the same day [BUG]

[darren chamberlain]

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]

[Stas Bekman]

Kevin A. McGrail wrote:
> 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.

cool! :)

> 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

thanks, I'll update the online version with your corrected one, once we 
figure out how to make it work with 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.

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 :) Can you 
run a simple Inline code doing just printf("Hello")? Once you make it 
run, the segfault should work just as well. could be that your webserver 
has no write perms to Inline dir... but you say it works with mod_cgi...

I'm a little out of sync with the recent developments with Inline, but 
last time I needed to do it for the book we work on, I wrote:

   package Factorial;
   use strict;

   use Apache::Constants qw(:common);

   use Inline 'Untaint';
   use Inline Config => DIRECTORY => '/tmp/Inline';
   use Inline 'C';
   Inline->init;

   sub handler {
   my $r = shift;
   $r->send_http_header('text/plain');

   printf "%3d! = %10d\n", $_, factorial($_) for 1..10;

   return Apache::Constants::OK;
   }

   1;

   __DATA__

   __C__

   double factorial(int x) {
   if (x < 2)  return 1;
   return x * factorial(x - 1);
   }

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.

__
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 multiple servers all compiled the same running different code and different Redhat Released all on the same day [BUG]

[Kevin A. McGrail]

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 multipleservers all compiled the same running different code and different RedhatReleased all on the same day [BUG]

[Stas Bekman]

> I would appreciate any comments of similar experiences or help in regards to
> making a core file.

http://perl.apache.org/preview/modperl-docs/dst_html/docs/2.0/devel/debug_c/debug_c.html#Getting_the_core_File_Dumped

__
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]

[Ged Haywood]

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... :)

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]

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: Segfault when using LWP

[Ryan Veety]

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   |
`--'

Segfault when using LWP

[Ryan Veety]

I just upgraded to Apache 1.3.23, mod_perl 1.26, openssl 0.9.6c, modssl 2.8.7.
Since then, httpd segfaults every time I use LWP::UserAgent to grab from a ssl
server.  The following mod_perl script is an example:

#!/usr/bin/perl

use strict;
use LWP::UserAgent;

my $ua = LWP::UserAgent->new;
my $request = HTTP::Request->new(GET => 'https://www.modssl.org/');
my $response = $ua->request($request);
my $text = $response->content;

print "Content-type: text/html\n\n";
print "It worked\n";
print $text;


This works perfectly from the command line, but segfaults when run within
mod_perl.  It also works fine when run in /cgi-bin, and it will work fine when
run in mod_perl if I change the request from https to http.  My first thought
was that the perl modules were linked to an older version of openssl, this is
not the case, I reinstalled all the perl modules and then even deleted perl
completely, recompiled it, reinstalled all the necessary perl modules, rebuilt
apache/mod_perl with the rebuilt perl, and the same thing still happens.  Once
httpd segfaults once, each apache process seems to crash/restart once per
second until I apachectl restart :(.  This all worked fine under mod_perl
1.25.

Any ideas??
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

[Ged Haywood]

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

[Chris Hutchinson]

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'

Re: segfault when using PerlRequire

[John D Groenveld]

> 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]

Re: segfault when using PerlRequire

[Stas Bekman]

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_lo

segfault when using PerlRequire

[John D Groenveld]

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:
d

Re: SegFault report with backtrace

[karnurme]

> > Here is a simple Test.pm handler that causes segfaults in our server.
> 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,

Thanks for idea! I'm afraid that the segfault report may be affected by
the naming, but the original module that caused the error was not named as
Test.pm. What a coincidence if I picked the one problematic
naming; Kari, the Midas of Bugs...

Best wishes,
-- 

Kari Nurmela,
[EMAIL PROTECTED], (02) 333 8847 / (0400) 786 547

Re: SegFault report with backtrace

[Ged Haywood]

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 report with backtrace

[karnurme]

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
r

My segfault problem

[Derek Balling]

At a friend's urging, I backed out mod_perl and moved to 1.25_01... 
problem vanished immediately.

Don't know what changed from 1.25_01 to 1.26, but looks like a bug 
got introduced somewhere. :-/

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]

>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
>
>(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 , 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 on start....

[Joshua Chamas]

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....

[Thomas Eibner]

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

(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  DnsZone 
  mod_pointer  

Re: segfault on start....

[Derek Balling]

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....

[Joshua Chamas]

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....

[Derek Balling]

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....

[Stas Bekman]

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/

segfault on start....

[Derek Balling]

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

[Bob Mroczka]

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/

Re: segfault

[Stas Bekman]

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

[Bob Mroczka]

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 ) 2>&1 | 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 with mod_perl, Oraperl, XML::Parser

[Matt Sergeant]

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.

--


/||** 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 with mod_perl, Oraperl, XML::Parser

[Scott Kister]

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(' here we go ');

# 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

[Tim Bunce]

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 w/ Apache 1.3.20, mod_perl 1.26

[Doug MacEachern]

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  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  section the produces
the segv?

Re: segfault with mod_perl, Oraperl, XML::Parser

[Philip Mak]

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

Re: segfault with mod_perl, Oraperl, XML::Parser

[Scott Kister]

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

Re: segfault w/ Apache 1.3.20, mod_perl 1.26

[Richard L. Goerwitz III]

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  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

segfault with mod_perl, Oraperl, XML::Parser

[Scott Kister]

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]

Hi there,

On Sun, 22 Jul 2001, Richard L. Goerwitz III wrote:

> 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  sections.  I'm using the Perl that came with
> my Linux (RedHat 7.0) machine, namely 5.6.0.

IIRC there was a problem with the compiler (gcc) that came with RH7.0,
which compiler are you using?

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.

Does this happen with a static build?

(Ducks for cover before Doug reads this... :)

73,
Ged.

PS: Please don't change your subject line, it messes up the thread.

More information on segfault

[Richard L. Goerwitz III]

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 , 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  section, then the seg-
fault happens anyway - after the last command gets handled).

-- 

Richard Goerwitz   [EMAIL PROTECTED]
tel: 401 438 8978

segfault w/ Apache 1.3.20, mod_perl 1.26

[Richard L. Goerwitz III]

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  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 , 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

Re: Segfault on ppc-linux with modperl-1.25 with Apache 1.3.19 whencalling $r->send_fd()

[Doug MacEachern]

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:

Re: segfault on subrequest?

[Doug MacEachern]

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.
> 
> 

Segfault question and possible workaround

[karnurme]

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()

[Mark Lipscombe]

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(<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

segfault on subrequest?

[Pierre Phaneuf]

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/

Re: Apache, mod_perl, mysql, php segfault!

[Matt Sergeant]

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).

-- 


/||** 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  **
 \\//
 //\\
//  \\

Apache, mod_perl, mysql, php segfault!

[Michael Turley]

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/

DBI->connect SegFault blues

[Matt]

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

[Stas Bekman]

On Sat, 17 Feb 2001, Christopher L. Everett wrote:

> Doug MacEachern wrote:
> 
> 
> 
> > ... 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: mod_perl segfault

[Christopher L. Everett]

Doug MacEachern wrote:



> ... 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: DBI+mod_perl SegFault!

[Eric J. Peters]

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:
>  
> #--
> 
>SetHandler perl-script
>PerlHandler Testing
> 
> #--
>  
> And I have a script called Testing.pm that looks like this:
>  
> #--
> package Testing;
>  
> use strict;
> use DBI;
>  
> sub handler {
>   print "Content-type:\n\ntest";
>   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 "\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\ntest";
>   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 "\n";
> #}
>  
> #1;
> #--
>  
> Anybody have any ideas?  I've tried everything I can come up with.
>  
> Thanks,
> -Eric.

Re: Segfault: apache-1.3.17+modperl-1.25

[dima]

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: Segfault: apache-1.3.17+modperl-1.25

[Vasily Petrushin]

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]

Re: Segfault: apache-1.3.17+modperl-1.25

[___cliff rayman___]

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?
>

Segfault: apache-1.3.17+modperl-1.25

[Gary Algier]

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."

DBI+mod_perl SegFault!

[Eric J. Peters]

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:

#--

   SetHandler perl-script
   PerlHandler Testing

#--

And I have a script called Testing.pm that looks like this:

#--
package Testing;
 
use strict;
use DBI;
 
sub handler {
  print "Content-type:\n\ntest";
  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 "\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\ntest";
  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 "\n";
#}

#1;
#--

Anybody have any ideas?  I've tried everything I can come up with.

Thanks,
-Eric.