from:"dbohling"

Re: repost: [mp1.0] recurring segfaults on mod_perl-1.27/apache-1.3.26

2002-10-18 Thread dbohling



Ged Haywood wrote:

Hello there,

On Fri, 18 Oct 2002 [EMAIL PROTECTED] wrote:



Hardware is definitely not at fault.
[snip]

[snip]

[snip]
first backtrace shows the segfault happening in mod_perl_sent_header(),
and the second shows it happening in  the ap_make_array() which was from
Apache::Cookie. I don't have one handy now, but I've also seen it happen
in ap_soft_timeout() after an XS_Apache_print (r-server was out of bounds).



[snip,snip,snip]

I saw another reply to your post talking about the way mod_perl was
built.  Could you let us know what the directory tree looked like as
far as the top level of the Apache and mod_perl directories?  That
should only take two lines of text, if not then that might be a clue.
I ask because I had a strange problem several years ago when I first
built mod_perl because I had

/usr/local/apache_1.xx

and

/usr/local/apache_1.xx/mod_perl-1.xx


I keep mod_perl in /usr/src/mod_perl-1.27 and apache in 
/usr/src/apache_1.3.26



which is definitely not the right way to do it.  In view of the fact
that your segfaults seem to be happening in unrelated parts of the
server I'm tempted to say that it must be something pretty fundamental.


yeah, the request_rec is all smashed up.


But that's just a gut feeling, no real reason that I can point to.

Have you tried pulling out as many modules as possible from the build
to see if anything changes, and then adding them back say as a DSO or
one at a time?


I've got nothing non-standard other than php and mod_perl compiled in. 
I'm going to try removing some of the standard modules and test.




73,
Ged.






--
--
Daniel Bohling
NewsFactor Network

Re: repost: [mp1.0] recurring segfaults on mod_perl-1.27/apache-1.3.26

2002-10-18 Thread dbohling

Thanks for the reply Ed. Hardware is definitely not at fault. Our site
proxies requests off to several backend servers and they all segfault in
the same way. I believe that there's a problem with libapreq or with
mod_perl itself. Unfortunately I'm not skilled enough in C programming
(yet) to find the problem.

Thanks anyway Ed, I was wondering if my messages were making it to the
list at all.

Ed wrote:
Daniel,

Could be bad hardware. Search google for Signal 11.

Probably your memory (usual cause I've seen).

good luck.

On Tue, Oct 08, 2002 at 09:46:16AM -0700, [EMAIL PROTECTED] wrote:

Sorry for the repost, but no responses so far, and I need some help with
this one.

I've managed to get a couple of backtraces on a segfault problem we've
been having for months now. The segfaults occur pretty rarely on the
whole, but once a client triggers one on a particular page, they do not
stop. The length and content of the request are key in making the
segfaults happen. Modifying the cookie or adding characters to the
request line causes the segfaults to stop.

example (word wrapped):

This request will produce a segfault (backtrace in attached gdb1.txt)
and about 1/3 of the expected page :

nc 192.168.1.20 84
GET /perl/section/entcmpt/ HTTP/1.1
User-Agent: Mozilla/5.0 (compatible; Konqueror/3; Linux 2.4.18-5)
Pragma: no-cache
Cache-control: no-cache
Accept: text/*, image/jpeg, image/png, image/*, */*
Accept-Encoding: x-gzip, gzip, identity
Accept-Charset: iso-8859-1, utf-8;q=0.5, *;q=0.5
Accept-Language: en
Host: 192.168.1.20:84
Cookie:
mxstsn=1033666066:19573.19579.19572.19574.19577.19580.19576.19558.19560.19559.19557.19567.19566.19568.19544.19553.19545.19551.19554.19546.19548.19547.19532.19535.19533.19538.19534:0;

Apache=192.168.2.1.124921033666065714

Adding a bunch of zeroes to the URI (which does not change the code
functionality) causes the page to work correctly:

nc 192.168.1.20 84
GET
/perl/section/entcmpt/?

HTTP/1.1
User-Agent: Mozilla/5.0 (compatible; Konqueror/3; Linux 2.4.18-5)
Pragma: no-cache
Cache-control: no-cache
Accept: text/*, image/jpeg, image/png, image/*, */*
Accept-Encoding: x-gzip, gzip, identity
Accept-Charset: iso-8859-1, utf-8;q=0.5, *;q=0.5
Accept-Language: en
Host: 192.168.1.20:84
Cookie:
mxstsn=1033666066:19573.19579.19572.19574.19577.19580.19576.19558.19560.19559.19557.19567.19566.19568.19544.19553.19545.19551.19554.19546.19548.19547.19532.19535.19533.19538.19534:0;

Apache=192.168.2.1.124921033666065714

Some info:
/usr/apache-perl/bin/httpd -l
Compiled-in modules:
http_core.c
mod_env.c
mod_log_config.c
mod_mime.c
mod_negotiation.c
mod_status.c
mod_include.c
mod_autoindex.c
mod_dir.c
mod_cgi.c
mod_asis.c
mod_imap.c
mod_actions.c
mod_userdir.c
mod_alias.c
mod_access.c
mod_auth.c
mod_so.c
mod_setenvif.c
mod_php4.c
mod_perl.c

Please forgive any obvious missing info (i'm not a c programmer). The
first backtrace shows the segfault happening in mod_perl_sent_header(),
and the second shows it happening in the ap_make_array() which was from
Apache::Cookie. I don't have one handy now, but I've also seen it happen
in ap_soft_timeout() after an XS_Apache_print (r-server was out of bounds).

I've added a third backtrace where r-content_encoding contains the
above 'mxstsn' cookie name.

Any help would be greatly appreciated.

--
--
Daniel Bohling
NewsFactor Network

Re: [OT] Perl vs. PHP..... but where is mod_perl?

2002-10-18 Thread dbohling

Whoa guys, we do actually have somewhat of a clue over here. That piece 
was a mistake (for the same reasons all of you took issue with) and was 
pulled as soon as I explained the problems with it (and before I'd ever 
seen any of the comments on list).

The url to the story, and most of our site, clearly says we 'use Perl;'. 
We use PHP only for simple templating functions, and as a continuation 
of legacy setup, and is slated for complete removal.


Randal L. Schwartz wrote:
allan == allan juul [EMAIL PROTECTED] writes:




allan odd yes, they are up to date it seems
allan head('http://www.newsfactor.com/perl/story/19716.html')

allan returns:
allan Apache/1.3.26 (Unix) PHP/4.2.2 mod_perl/1.27

allan bad article BTW IMHO
allan ./allan


Heh.  They really *don't* understand even what they have.

Here's the source to part of the page I got during signup:

META HTTP-EQUIV=refresh content=30;URL=Apache::Cookie=SCALAR(0x8974a94)
Thank you for registering, merlyn.
p
Your registration is now complete.  
p 
You will now be taken back to the page you were on before the sign-up process.
br
Or you can click a href=Apache::Cookie=SCALAR(0x8974a94)here/a to return quicker.
p
Regards,
br
NewsFactor team

Heh!  Apache::Cookie=SCALAR(0x)  Even in the refresh header!

That's just too funny.



This is a bug introduced by having to insert workarounds for segfaults 
caused by Apache::Cooke/mod_perl. I've been asking for help with this 
issue for off and on for months now. See:

http://www.geocrawler.com/mail/thread.php3?subject=repost%3A+%5Bmp1.0%5D+recurring+segfaults+on+mod_perl-1.27%2Fapache-1.3.26list=182



--
--
Daniel Bohling
NewsFactor Network

Re: [OT] Perl vs. PHP..... but where is mod_perl?

2002-10-18 Thread dbohling



Perrin Harkins wrote:

[EMAIL PROTECTED] wrote:


This is a bug introduced by having to insert workarounds for segfaults 
caused by Apache::Cooke/mod_perl. I've been asking for help with this 
issue for off and on for months now.


I suggest you stop using Apache::Cookie and see if the segfaults go 
away.  There are pure Perl modules that handle cookies well, and it's 
not an expensive operation.  Apache::Cookie is probably overkill in most 
situations.

This problem was fairly intermittent a while back, but became a real 
problem after we revamped our ad serving code to store details of the 
served ads across subrequests via $r-notes(); Not realizing that 
$r-main() is kinda misleading in that it doesn't really point to the 
top level request, we created a wrapper around Apache::Subrequest::run() 
to include code to copy all the notes from the parent to the subrequest 
and vice-versa. This caused the segfaults to escalate.

Btw when I mean escalate, i mean that the odds of any browser getting a 
segfaulting page were increased, not that they are random - a particular 
request - URI,User-Agent,Accept,Cookie, etc combo - consistently 
segfaults, at least for a few days.

While trying to debug this we replaced Apache::Cookie (i'm not certain 
if every instance of which, but I think we did) with regexes against 
$r-header_in(Cookie), to no avail.


At this point we are using Apache::Cookie and not overriding 
Apache::Subrequest::run(), and this is working without the segfaults.
But, we just recently tried to add an additional call to Apache::Cookie 
for our ad system and they all came right back.


--
--
Daniel Bohling
NewsFactor Network

repost: [mp1.0] recurring segfaults on mod_perl-1.27/apache-1.3.26

2002-10-08 Thread dbohling

Sorry for the repost, but no responses so far, and I need some help with
this one.

example (word wrapped):

This request will produce a segfault (backtrace in attached gdb1.txt)
and about 1/3 of the expected page :

Apache=192.168.2.1.124921033666065714

Adding a bunch of zeroes to the URI (which does not change the code
functionality) causes the page to work correctly:

nc 192.168.1.20 84
GET
/perl/section/entcmpt/?

Apache=192.168.2.1.124921033666065714

I've added a third backtrace where r-content_encoding contains the
above 'mxstsn' cookie name.

Any help would be greatly appreciated.

--
--
Daniel Bohling
NewsFactor Network

[root@proxy dumps]# gdb /usr/apache-perl/bin/httpd core.12510
GNU gdb Red Hat Linux (5.2-2)
Copyright 2002 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-redhat-linux...
Core was generated by `/usr/apache-perl/bin/httpd'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libpam.so.0...done.
Loaded symbols for /lib/libpam.so.0
Reading symbols from /usr/lib/libmysqlclient.so.10...done.
Loaded symbols for /usr/lib/libmysqlclient.so.10
Reading symbols from /lib/libcrypt.so.1...done.
Loaded symbols for /lib/libcrypt.so.1
Reading symbols from /lib/libresolv.so.2...done.
Loaded symbols for /lib/libresolv.so.2
Reading symbols from /lib/i686/libm.so.6...done.
Loaded symbols for /lib/i686/libm.so.6
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libnsl.so.1...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/i686/libc.so.6...bdone.
Loaded symbols for /lib/i686/libc.so.6
Reading symbols from /lib/libutil.so.1...done.
Loaded symbols for /lib/libutil.so.1
Reading symbols from /usr/lib/libexpat.so.0...done.
Loaded symbols for /usr/lib/libexpat.so.0
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libnss_files.so.2...done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /usr/lib/perl5/5.6.1/i386-linux/auto/Data/Dumper/Dumper.so...done.
Loaded symbols for /usr/lib/perl5/5.6.1/i386-linux/auto/Data/Dumper/Dumper.so
Reading symbols from /usr/lib/perl5/5.6.1/i386-linux/auto/Socket/Socket.so...done.
Loaded symbols for /usr/lib/perl5/5.6.1/i386-linux/auto/Socket/Socket.so
Reading symbols from

Backtraces on recurring segfaults on mod_perl-1.27/apache-1.3.26

2002-10-03 Thread dbohling

example (word wrapped):

This request will produce a segfault (backtrace in attached gdb1.txt)
and about 1/3 of the expected page :

Apache=192.168.2.1.124921033666065714

Adding a bunch of zeroes to the URI (which does not change the code
functionality) causes the page to work correctly:

nc 192.168.1.20 84
GET
/perl/section/entcmpt/?
HTTP/1.1
User-Agent: Mozilla/5.0 (compatible; Konqueror/3; Linux 2.4.18-5)
Pragma: no-cache
Cache-control: no-cache
Accept: text/*, image/jpeg, image/png, image/*, */*
Accept-Encoding: x-gzip, gzip, identity
Accept-Charset: iso-8859-1, utf-8;q=0.5, *;q=0.5
Accept-Language: en
Host: 192.168.1.20:84
Cookie:
mxstsn=1033666066:19573.19579.19572.19574.19577.19580.19576.19558.19560.19559.19557.19567.19566.19568.19544.19553.19545.19551.19554.19546.19548.19547.19532.19535.19533.19538.19534:0;

Apache=192.168.2.1.124921033666065714

I've added a third backtrace where r-content_encoding contains the
above 'mxstsn' cookie name.

Any help would be greatly appreciated.

--
--
Daniel Bohling
NewsFactor Network

Apache::SubRequest::run segfaulting

2002-06-05 Thread dbohling


Hey list,

To be able to pass some notes across php subrequest calls which in turn 
call a mod_perl handlers we've overriden Apache::SubRequest::run() in 
startup.pl like so:

### save the original method
*NFN::run_save = \Apache::SubRequest::run;

## build our custom version
sub NFN::run_custom {
my $subr = shift(_);
## copy our notes into the subrequest
my $parent_notes = $subr-main-notes();
for my $key (keys(%$parent_notes)) {
if ($key =~ /^NFN_/) {
$subr-notes($key, $parent_notes-{$key});
}
}
my retval = ();
## i don't know if run() returns differently in
## scalar vs. array context, so i've split up the
## call here.  (normally, i would just say
## return NFN::run_save() but i can't return until later
if(wantarray) {
## call the original method
retval = NFN::run_save($subr, _);
}
else {
## call the original method
my $retval = NFN::run_save($subr, _);
retval = ($retval);
}
## copy our notes back into the parent
my $child_notes = $subr-notes();
for my $key (keys(%$child_notes)) {
if ($key =~ /^NFN_/) {
$subr-main-notes($key, $child_notes-{$key});
}
}
return wantarray ? retval : $retval[0];
}
### make calls to Apache::Subrequest::run get handled by
### our custom method.
*Apache::SubRequest::run = \NFN::run_custom;


This works as intended but has a peculiar side effect. My development 
machine's browser, mozilla 1.0 rc3, segfaults the apache process when 
serving a particular page on our sites. My laptop has the same exact 
build and does not do this at all. I've seen 1 machine in our office do 
this on IE 6.0 , but only on a different page. In all cases when apache 
segfaults, about 1/4 of the html for the page comes out. This 1/4 is 
served by a php page which is called via $subr-run() from a registry 
script. The php subrequest finishes normally, but the registry script 
causes the segfault at the next print command after the $subr-run() call.



Watching my log files I can see that other machines are also segfaulting 
apache processes. This behavior stops when I remove our modification to 
the run method. The absolute bizarre thing is that almost all pages on 
our site work exactly the same way, call the same php files, but only 
one segfaults apache from my browser, but on the IE machine, it's a 
different page that segfaults.

Anyhow, I've managed to grab a backtrace from when my browser hits the 
server:

Program received signal SIGSEGV, Segmentation fault.
0x08138498 in ap_bwrite ()
(gdb) bt
#0  0x08138498 in ap_bwrite ()
#1  0x08147572 in ap_rwrite ()
#2  0x08127e31 in XS_Apache_write_client ()
#3  0x08127c52 in XS_Apache_print ()
#4  0x0819c12c in Perl_pp_entersub ()
#5  0x08157645 in S_call_body ()
#6  0x0815721b in perl_call_sv ()
#7  0x081570a1 in perl_call_method ()
#8  0x08197a16 in Perl_pp_print ()
#9  0x08196a58 in Perl_runops_standard ()
#10 0x08157654 in S_call_body ()
#11 0x08157431 in perl_call_sv ()
#12 0x081570a1 in perl_call_method ()
#13 0x0811d8e2 in perl_call_handler ()
#14 0x0811d1f9 in perl_run_stacked_handlers ()
#15 0x0811bca9 in perl_handler ()
#16 0x08139191 in ap_invoke_handler ()
#17 0x08149a6c in process_request_internal ()
#18 0x08149aee in ap_process_request ()
#19 0x08142984 in child_main ()
#20 0x08142b00 in make_child ()
#21 0x08142c36 in startup_children ()
#22 0x081431fb in standalone_main ()
#23 0x081439e8 in main ()
#24 0x400ef507 in __libc_start_main (main=0x8143680 main, argc=2, 
ubp_av=0xbad4,
 init=0x8073d5c _init, fini=0x81da5f0 _fini, 
rtld_fini=0x4000dc14 _dl_fini,
 stack_end=0xbacc) at ../sysdeps/generic/libc-start.c:129




-- 
--
Daniel Bohling
NewsFactor Network

Apache::Util segfaulting

2002-01-07 Thread dbohling


Hi all,

I'm having an odd problem with a particular registry script.

This script causes a segmentation fault at the first usage of 
Apache::Util::escape_uri(),

This same script also uses Apache::Util::escape_html() with no problems 
at all.

Other scripts on this same server use Apache::Util::escape_uri() without 
any problems.

I've tried to get a core dump with httpd -X but it won't leave one.

This is apache 1.3.14 with mod_perl/1.24_01 and php/3.0.17 both built 
against the same mysql libraries.

Any ideas?

 
--
Daniel Bohling
NewsFactor Network

Re: Apache::Cooke reserved chars

2001-12-18 Thread dbohling



darren chamberlain wrote:

 [EMAIL PROTECTED] [EMAIL PROTECTED] said something to this effect on 
12/17/2001:
 
I'm recording a url at the beginning of an app to restore the
entrance url:

sub set_referer {
  my $self = shift;
  if ($self-{R}) {
  require Apache::Cookie;
  
  my $cookie = Apache::Cookie-new($self-{R},
  -name=  REFERER,
  -value   =  $self-{R}-header_in('Referer'),
  -expires =  '2d',
  -domain  =  .$NFN::sites{$ENV{SITE}}{domain},
  -path=  '/'
  );
  $cookie-bake;
  }
  
}


Which stores the cookie portion like so:

REFERER=http://www.newsfactor.com/x.pl%3faction=reply_form_htmlboard=nfntalkbackid=3288

However when I pull this back in with Apache::Cookie-fetch,
the data then reads:

http://www.newsfactor.com/x.pl?action=reply_form_html

Apache::Cookie seems to be stripping out the portion after the first 
ampersand.

Anybody know what do do here?

 
 Use escape_uri and unescape_uri, or some other pair of reversable
 functions.  For example, store it as:
 
 use Apache::Util qw(escape_uri unescape_uri);
 sub set_referer {
   my $self = shift;
   if ($self-{R}) {
   require Apache::Cookie;
   
   my $cookie = Apache::Cookie-new($self-{R},
   -name=  REFERER,
   -value   =  escape_uri($self-{R}-header_in('Referer')),
   -expires =  '2d',
   -domain  =  .$NFN::sites{$ENV{SITE}}{domain},
   -path=  '/'
   );
   $cookie-bake;
   }
   
 }
 
 And then fetch it as:
 
   my $value = unescape_uri($cookies{'REFERER'});
 
 (darren)
 


Thanks darren,

Tried this and it appears that Apache::Util escapes the same characters 
that Apache::Cookie does when it prepares this cookie. Problem is that 
it wont pull the ampersands back in. I'm assuming the thinking is that 
Apache::Cookie shoud be able to decode a string it encodes. I'm running 
an older version of mod_perl (1.24_01), wondering if anybody knows if 
this issue has been seen before, and if it's been fixed in more recent 
versions.




-- 
--
Daniel Bohling
NewsFactor Network

Re: Apache::Cooke reserved chars

2001-12-18 Thread dbohling

darren chamberlain wrote:

[EMAIL PROTECTED] [EMAIL PROTECTED] said something to this effect on
12/18/2001:

Use escape_uri and unescape_uri, or some other pair of reversable
functions. For example, store it as:

Tried this and it appears that Apache::Util escapes the same
characters that Apache::Cookie does when it prepares this
cookie. Problem is that it wont pull the ampersands back in.
I'm assuming the thinking is that Apache::Cookie shoud be able
to decode a string it encodes. I'm running an older version of
mod_perl (1.24_01), wondering if anybody knows if this issue
has been seen before, and if it's been fixed in more recent
versions.

URI::Escape::uri_escape allows you to pass a list of unsafe
characters as the optional second argument (although
Apache::Util::unescape_uri does not; see src/main/util.c in the
apache source for why). Here is an updated version of my
previous example (trimmed; the value for $url is the one you gave
in the original message):

use URI::Escape;
my $url =
q|http://www.newsfactor.com/x.pl?action=reply_form_htmlboard=nfntalkbackid=3288|;
my $escaped = uri_escape($url, '\x00-\xff');

Now, $escaped looks like:

%68%74%74%70%3A%2F%2F%77%77%77%2E%6E%65%77%73%66%61%63%74%6F%72%2E%63%6F%6D%2F%78%78%78%78%78%2E%70%6C%3F%61%63%74%69%6F%6E%3D%72%65%70%6C%79%5F%66%6F%72%6D%5F%68%74%6D%6C%26%62%6F%61%72%64%3D%6E%66%6E%74%61%6C%6B%62%61%63%6B%26%69%64%3D%33%32%38%38

This should be OK as a cookie value. The value of $escaped is
easily retrievable with:

my $unescaped = uri_unescape($escaped);

The only problem, such as it may be, is that the version in
URI::Escape pure perl, and therefore slower than the version in
Apache::Util.

(darren)

Yeah I don't wanna have to load up URI::Escape, I'm just doing a s//___/g

and doing the inverse after receiving the URL on the other end.

Does anybody know why Apache::Cookie is barfing on the ampersands? I
looked at the RFC yesterday and ampersand is not listed as unsafe.

Btw, thanks for your suggestions darren.

--
--
Daniel Bohling
NewsFactor Network

Apache::Cooke reserved chars

2001-12-17 Thread dbohling


Hi all,

I'm recording a url at the beginning of an app to restore the
entrance url:

sub set_referer {
my $self = shift;
if ($self-{R}) {
require Apache::Cookie;

my $cookie = Apache::Cookie-new($self-{R},
-name=  REFERER,
-value   =  $self-{R}-header_in('Referer'),
-expires =  '2d',
-domain  =  .$NFN::sites{$ENV{SITE}}{domain},
-path=  '/'
);
$cookie-bake;
}

}


Which stores the cookie portion like so:

REFERER=http://www.newsfactor.com/x.pl%3faction=reply_form_htmlboard=nfntalkbackid=3288


However when I pull this back in with Apache::Cookie-fetch,
the data then reads:

http://www.newsfactor.com/x.pl?action=reply_form_html


Apache::Cookie seems to be stripping out the portion after the first 
ampersand.

Anybody know what do do here?

Thanks in advance,


-- 
--
Daniel Bohling
NewsFactor Network

Re: repost: [mp1.0] recurring segfaults on mod_perl-1.27/apache-1.3.26

Re: repost: [mp1.0] recurring segfaults on mod_perl-1.27/apache-1.3.26

Re: [OT] Perl vs. PHP..... but where is mod_perl?

Re: [OT] Perl vs. PHP..... but where is mod_perl?

repost: [mp1.0] recurring segfaults on mod_perl-1.27/apache-1.3.26

Backtraces on recurring segfaults on mod_perl-1.27/apache-1.3.26

Apache::SubRequest::run segfaulting

Apache::Util segfaulting

Re: Apache::Cooke reserved chars

Re: Apache::Cooke reserved chars

Apache::Cooke reserved chars

11 matches

Site Navigation

Mail list logo

Footer information