You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeff Trawick <tr...@attglobal.net> on 2001/08/17 17:19:21 UTC
[PATCH] mod_include fix
In the "2.0.24 tagged" thread, Greg mentioned a problem with
mod_include. This fixes it for me.
We're in find_end_sequence() walking over the directive and the rest
of the tag but we stop parsing so we don't walk over too much storage
(e.g., mmap) at once). When we resume later, ctx->directive_length
has the value it had when we bailed out, so directive_length is wrong
and we hit errors like:
[Fri Aug 17 11:12:06 2001] [error] [client 127.0.0.1] unknown directiv
e "include virt" in parsed doc /home/trawick/apacheinst/htdocs/manual/
mod/mod_include.html
If anyone else is hitting similar problems, please try this patch.
Index: modules/filters/mod_include.c
===================================================================
RCS file: /home/cvspublic/httpd-2.0/modules/filters/mod_include.c,v
retrieving revision 1.121
diff -u -r1.121 mod_include.c
--- modules/filters/mod_include.c 2001/08/11 04:04:12 1.121
+++ modules/filters/mod_include.c 2001/08/17 15:09:26
@@ -270,6 +270,8 @@
}
while (c < buf + len) {
if (ctx->bytes_parsed >= BYTE_COUNT_THRESHOLD) {
+ /* gonna start over parsing the directive next time through */
+ ctx->directive_length = 0;
return dptr;
}
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: [PATCH] mod_include fix
Posted by Jeff Trawick <tr...@attglobal.net>.
Jeff Trawick <tr...@attglobal.net> writes:
> Jeff Trawick <tr...@attglobal.net> writes:
>
> > I'm gonna take a short break then write a perl CGI to put the tag at
> > specified offsets, run it for i = 0 to very-large-number, and if I
> > don't get any parsing errors I'll commit it.
>
> cool... with 8187 blanks in front of the tag we barf
The only problem I can recreate with my second patch (uncommitted) is
at offset n*8192+8187... after looking at it briefly, it would seem
that the n*8192+8187 problem is the fault of find_start_sequence()
(i.e., unrelated to the code I've tweaked)
I'll commit the second patch now and try to make progress on
n*8192+8187 before I have to stop.
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: [PATCH] mod_include fix
Posted by Jeff Trawick <tr...@attglobal.net>.
Jeff Trawick <tr...@attglobal.net> writes:
> I'm gonna take a short break then write a perl CGI to put the tag at
> specified offsets, run it for i = 0 to very-large-number, and if I
> don't get any parsing errors I'll commit it.
cool... with 8187 blanks in front of the tag we barf
[Fri Aug 17 15:52:14 2001] [error] [client 127.0.0.1] unknown
directive "<!" in parsed doc
/home/trawick/apacheinst/cgi-bin/createtags.pl
I'll look into it now, but company is arriving from out of town soon
and I can only be so rude.
CGI is below
request it with parms like this: /cgi-bin/createtags.pl?offset=8187
#!/usr/local/bin/perl -w
BEGIN
{
use CGI::Carp qw(fatalsToBrowser);
}
use strict;
use CGI;
my $q = new CGI;
my $offset = $q->param('offset');
if (!$offset)
{
die "Yo! I need an offset!";
}
print "Content-type: text/html\n\n";
while ($offset > 0)
{
print " ";
--$offset;
}
print "<!--#include file=\"footer.html\" -->";
$offset = 100;
while ($offset > 0)
{
print " ";
--$offset;
}
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: [PATCH] mod_include fix
Posted by Jeff Trawick <tr...@attglobal.net>.
I played with the offset of the tag in the file so that I hit the
8192-byte boundary at a different spot in the tag and hit another
parse problem.
At this point, this patch on top of what I committed previously
handles both testcases :)
I'm gonna take a short break then write a perl CGI to put the tag at
specified offsets, run it for i = 0 to very-large-number, and if I
don't get any parsing errors I'll commit it.
Index: modules/filters/mod_include.c
===================================================================
RCS file: /home/cvspublic/httpd-2.0/modules/filters/mod_include.c,v
retrieving revision 1.122
diff -u -r1.122 mod_include.c
--- modules/filters/mod_include.c 2001/08/17 17:24:46 1.122
+++ modules/filters/mod_include.c 2001/08/17 18:48:28
@@ -270,8 +270,10 @@
}
while (c < buf + len) {
if (ctx->bytes_parsed >= BYTE_COUNT_THRESHOLD) {
- /* gonna start over parsing the directive next time through */
- ctx->directive_length = 0;
+ if (ctx->state == PARSE_DIRECTIVE) {
+ /* gonna start over parsing the directive next time through */
+ ctx->directive_length = 0;
+ }
return dptr;
}
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: [PATCH] mod_include fix
Posted by Jeff Trawick <tr...@attglobal.net>.
"Paul J. Reder" <re...@raleigh.ibm.com> writes:
> Please hold on committing this. I am looking at this patch right now. This fix doesn't
> seem right at first read. I'll post a go/no go in a little bit...
I think more stuff needs to be reset. debugging now...
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: [PATCH] mod_include fix
Posted by "Paul J. Reder" <re...@raleigh.ibm.com>.
Jeff Trawick wrote:
>
> In the "2.0.24 tagged" thread, Greg mentioned a problem with
> mod_include. This fixes it for me.
>
> We're in find_end_sequence() walking over the directive and the rest
> of the tag but we stop parsing so we don't walk over too much storage
> (e.g., mmap) at once). When we resume later, ctx->directive_length
> has the value it had when we bailed out, so directive_length is wrong
> and we hit errors like:
>
> [Fri Aug 17 11:12:06 2001] [error] [client 127.0.0.1] unknown directiv
> e "include virt" in parsed doc /home/trawick/apacheinst/htdocs/manual/
> mod/mod_include.html
>
> If anyone else is hitting similar problems, please try this patch.
>
> Index: modules/filters/mod_include.c
> ===================================================================
> RCS file: /home/cvspublic/httpd-2.0/modules/filters/mod_include.c,v
> retrieving revision 1.121
> diff -u -r1.121 mod_include.c
> --- modules/filters/mod_include.c 2001/08/11 04:04:12 1.121
> +++ modules/filters/mod_include.c 2001/08/17 15:09:26
> @@ -270,6 +270,8 @@
> }
> while (c < buf + len) {
> if (ctx->bytes_parsed >= BYTE_COUNT_THRESHOLD) {
> + /* gonna start over parsing the directive next time through */
> + ctx->directive_length = 0;
> return dptr;
> }
Please hold on committing this. I am looking at this patch right now. This fix doesn't
seem right at first read. I'll post a go/no go in a little bit...
Thanks,
--
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein
Re: [PATCH] mod_include fix (only show stopper in 2.0.24...)
Posted by Greg Ames <gr...@remulak.net>.
Greg Ames wrote:
> daedalus can now serve mod_include's manual page correctly, but log
> replay still produces
>
> [Fri Aug 17 10:42:01 2001] [error] [client 32.97.136.237] unable to
> include "FAQ-B.html?" in parsed file
> /www/httpd.apache.org/docs-2.0/misc/FAQ.html
>
> for FAQ-B, FAQ-D thru FAQ-G, and FAQ-I, in both docs/misc/ and
> docs-2.0/misc/
I need to leave for a band gig, but this stuff is due to
ap_run_sub_req() returning 32 to handle_include() around line 853. Not
obvious from the log/code. We need to drill down further.
Greg
Re: [PATCH] mod_include fix (only show stopper in 2.0.24...)
Posted by Greg Ames <gr...@remulak.net>.
Greg Ames wrote:
>
> Bill Stoddard wrote:
> >
> > Have we rolled 2.0.24 yet? I think this was the last showstopper.
> >
> > +1 on committing, push the tag and roll.
> >
>
> +1 on committing & pushing the mod_include tag. Serving mod_include's
> manual page is working, as Jeff already knows.
daedalus can now serve mod_include's manual page correctly, but log
replay still produces
[Fri Aug 17 10:42:01 2001] [error] [client 32.97.136.237] unable to
include "FAQ-B.html?" in parsed file
/www/httpd.apache.org/docs-2.0/misc/FAQ.html
for FAQ-B, FAQ-D thru FAQ-G, and FAQ-I, in both docs/misc/ and
docs-2.0/misc/
I'm going to look at the core dump first.
Greg
Re: [PATCH] mod_include fix (only show stopper in 2.0.24...)
Posted by Ryan Bloom <rb...@covalent.net>.
Yeah, but Cody's patch didn't actually change the vformatter code, it just
changed the function that called apr_vformatter.
Ryan
On Friday 17 August 2001 13:18, William A. Rowe, Jr. wrote:
> I was looking at this; psprintf_flush
>
> Hmmm.
>
> ----- Original Message -----
> From: "Ryan Bloom" <rb...@covalent.net>
> To: <ne...@apache.org>; "William A. Rowe, Jr." <wr...@rowe-clan.net>
> Sent: Friday, August 17, 2001 2:57 PM
> Subject: Re: [PATCH] mod_include fix (only show stopper in 2.0.24...)
>
> > Why do you say that? apr_vformatter doesn't show up any place in the
> > stack trace. Also Cody's patch is only used when a handler calls
> > ap_rvprintf, and none of the core modules use that function.
> >
> > Ryan
> >
> > On Friday 17 August 2001 12:40, William A. Rowe, Jr. wrote:
> > > Looks like a bug useing apr_vrformatter ... Cody's patch, perhaps?
> > >
> > > ----- Original Message -----
> > > From: "Greg Ames" <gr...@remulak.net>
> > > To: <ne...@apache.org>
> > > Sent: Friday, August 17, 2001 1:51 PM
> > > Subject: Re: [PATCH] mod_include fix (only show stopper in 2.0.24...)
> > >
> > > > Greg Ames wrote:
> > > > > noticed this in the error_log on my ThinkPad:
> > > > >
> > > > > [Fri Aug 17 13:11:24 2001] [notice] caught SIGTERM, shutting down
> > > > > [Fri Aug 17 13:11:24 2001] [notice] seg fault or similar nasty
> > > > > error detected in the parent process
> > > >
> > > > I can't make any sense out of the dump, nor can I re-create the
> > > > problem, even with Jeff's one-liner to mod_include backed out. I'm
> > > > writing this one off as sunspots, gamma rays or panty hose.
> > > >
> > > > Greg
> > > >
> > > > p.s. please speak up if this makes more sense to you.
> > > >
> > > > (gdb) bt
> > > > #0 0x40009a61 in ?? ()
> > > > #1 0x4000d360 in ?? ()
> > > > #2 0x4000d510 in ?? ()
> > > > #3 0x401160fe in ?? ()
> > > > #4 0x4014fb68 in ?? ()
> > > > #5 0x0808fd19 in apr_palloc (a=0x80e4c74, reqsize=1024) at
> > > > apr_pools.c:1100
> > > > #6 0x0808fea2 in apr_pool_userdata_get (data=0x80c0a0c,
> > > > key=0x80c0a0c "",
> > > > cont=0xbffff638) at apr_pools.c:1222
> > > > #7 0x0808ff00 in psprintf_flush (vbuff=0x80c0a0c) at
> > > > apr_pools.c:1289 #8 0x0808fe8c in apr_pool_userdata_get
> > > > (data=0x80be9fc,
> > > > key=0x400 <Address 0x400 out of bounds>, cont=0xbffff65c)
> > > > at apr_pools.c:1221
> > > > #9 0x0808ff00 in psprintf_flush (vbuff=0x80be9fc) at
> > > > apr_pools.c:1289 #10 0x08067d15 in usage (process=0x80bea74) at
> > > > main.c:258
> > > > #11 0x08068425 in get_addresses (p=0x1, w_=0xbffff754 "×øÿ¿",
> > > > paddr=0xbffff75c, default_port=134600058) at vhost.c:220
> > > > #12 0x4013f0de in ?? ()
> >
> > --
> >
> > ______________________________________________________________
> > Ryan Bloom rbb@apache.org
> > Covalent Technologies rbb@covalent.net
> > --------------------------------------------------------------
--
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: [PATCH] mod_include fix (only show stopper in 2.0.24...)
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
I was looking at this; psprintf_flush
Hmmm.
----- Original Message -----
From: "Ryan Bloom" <rb...@covalent.net>
To: <ne...@apache.org>; "William A. Rowe, Jr." <wr...@rowe-clan.net>
Sent: Friday, August 17, 2001 2:57 PM
Subject: Re: [PATCH] mod_include fix (only show stopper in 2.0.24...)
>
> Why do you say that? apr_vformatter doesn't show up any place in the
> stack trace. Also Cody's patch is only used when a handler calls ap_rvprintf,
> and none of the core modules use that function.
>
> Ryan
>
> On Friday 17 August 2001 12:40, William A. Rowe, Jr. wrote:
> > Looks like a bug useing apr_vrformatter ... Cody's patch, perhaps?
> >
> > ----- Original Message -----
> > From: "Greg Ames" <gr...@remulak.net>
> > To: <ne...@apache.org>
> > Sent: Friday, August 17, 2001 1:51 PM
> > Subject: Re: [PATCH] mod_include fix (only show stopper in 2.0.24...)
> >
> > > Greg Ames wrote:
> > > > noticed this in the error_log on my ThinkPad:
> > > >
> > > > [Fri Aug 17 13:11:24 2001] [notice] caught SIGTERM, shutting down
> > > > [Fri Aug 17 13:11:24 2001] [notice] seg fault or similar nasty error
> > > > detected in the parent process
> > >
> > > I can't make any sense out of the dump, nor can I re-create the problem,
> > > even with Jeff's one-liner to mod_include backed out. I'm writing this
> > > one off as sunspots, gamma rays or panty hose.
> > >
> > > Greg
> > >
> > > p.s. please speak up if this makes more sense to you.
> > >
> > > (gdb) bt
> > > #0 0x40009a61 in ?? ()
> > > #1 0x4000d360 in ?? ()
> > > #2 0x4000d510 in ?? ()
> > > #3 0x401160fe in ?? ()
> > > #4 0x4014fb68 in ?? ()
> > > #5 0x0808fd19 in apr_palloc (a=0x80e4c74, reqsize=1024) at
> > > apr_pools.c:1100
> > > #6 0x0808fea2 in apr_pool_userdata_get (data=0x80c0a0c, key=0x80c0a0c
> > > "",
> > > cont=0xbffff638) at apr_pools.c:1222
> > > #7 0x0808ff00 in psprintf_flush (vbuff=0x80c0a0c) at apr_pools.c:1289
> > > #8 0x0808fe8c in apr_pool_userdata_get (data=0x80be9fc,
> > > key=0x400 <Address 0x400 out of bounds>, cont=0xbffff65c)
> > > at apr_pools.c:1221
> > > #9 0x0808ff00 in psprintf_flush (vbuff=0x80be9fc) at apr_pools.c:1289
> > > #10 0x08067d15 in usage (process=0x80bea74) at main.c:258
> > > #11 0x08068425 in get_addresses (p=0x1, w_=0xbffff754 "×øÿ¿",
> > > paddr=0xbffff75c, default_port=134600058) at vhost.c:220
> > > #12 0x4013f0de in ?? ()
>
> --
>
> ______________________________________________________________
> Ryan Bloom rbb@apache.org
> Covalent Technologies rbb@covalent.net
> --------------------------------------------------------------
>
Re: [PATCH] mod_include fix (only show stopper in 2.0.24...)
Posted by Ryan Bloom <rb...@covalent.net>.
Why do you say that? apr_vformatter doesn't show up any place in the
stack trace. Also Cody's patch is only used when a handler calls ap_rvprintf,
and none of the core modules use that function.
Ryan
On Friday 17 August 2001 12:40, William A. Rowe, Jr. wrote:
> Looks like a bug useing apr_vrformatter ... Cody's patch, perhaps?
>
> ----- Original Message -----
> From: "Greg Ames" <gr...@remulak.net>
> To: <ne...@apache.org>
> Sent: Friday, August 17, 2001 1:51 PM
> Subject: Re: [PATCH] mod_include fix (only show stopper in 2.0.24...)
>
> > Greg Ames wrote:
> > > noticed this in the error_log on my ThinkPad:
> > >
> > > [Fri Aug 17 13:11:24 2001] [notice] caught SIGTERM, shutting down
> > > [Fri Aug 17 13:11:24 2001] [notice] seg fault or similar nasty error
> > > detected in the parent process
> >
> > I can't make any sense out of the dump, nor can I re-create the problem,
> > even with Jeff's one-liner to mod_include backed out. I'm writing this
> > one off as sunspots, gamma rays or panty hose.
> >
> > Greg
> >
> > p.s. please speak up if this makes more sense to you.
> >
> > (gdb) bt
> > #0 0x40009a61 in ?? ()
> > #1 0x4000d360 in ?? ()
> > #2 0x4000d510 in ?? ()
> > #3 0x401160fe in ?? ()
> > #4 0x4014fb68 in ?? ()
> > #5 0x0808fd19 in apr_palloc (a=0x80e4c74, reqsize=1024) at
> > apr_pools.c:1100
> > #6 0x0808fea2 in apr_pool_userdata_get (data=0x80c0a0c, key=0x80c0a0c
> > "",
> > cont=0xbffff638) at apr_pools.c:1222
> > #7 0x0808ff00 in psprintf_flush (vbuff=0x80c0a0c) at apr_pools.c:1289
> > #8 0x0808fe8c in apr_pool_userdata_get (data=0x80be9fc,
> > key=0x400 <Address 0x400 out of bounds>, cont=0xbffff65c)
> > at apr_pools.c:1221
> > #9 0x0808ff00 in psprintf_flush (vbuff=0x80be9fc) at apr_pools.c:1289
> > #10 0x08067d15 in usage (process=0x80bea74) at main.c:258
> > #11 0x08068425 in get_addresses (p=0x1, w_=0xbffff754 "×øÿ¿",
> > paddr=0xbffff75c, default_port=134600058) at vhost.c:220
> > #12 0x4013f0de in ?? ()
--
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: [PATCH] mod_include fix (only show stopper in 2.0.24...)
Posted by Greg Ames <gr...@remulak.net>.
"William A. Rowe, Jr." wrote:
>
> Looks like a bug useing apr_vrformatter ... Cody's patch, perhaps?
hmmm, that did change recently. I don't know how it ties into the rest
of the *printf* stuff, or if the apparent recursion below makes any
sense, or why I should see so many "??"s in the bt. I'm making slow
progress with the mod_include FAQ-x problem, and will stick to that for
now.
> > (gdb) bt
> > #0 0x40009a61 in ?? ()
> > #1 0x4000d360 in ?? ()
> > #2 0x4000d510 in ?? ()
> > #3 0x401160fe in ?? ()
> > #4 0x4014fb68 in ?? ()
> > #5 0x0808fd19 in apr_palloc (a=0x80e4c74, reqsize=1024) at
> > apr_pools.c:1100
> > #6 0x0808fea2 in apr_pool_userdata_get (data=0x80c0a0c, key=0x80c0a0c
> > "",
> > cont=0xbffff638) at apr_pools.c:1222
> > #7 0x0808ff00 in psprintf_flush (vbuff=0x80c0a0c) at apr_pools.c:1289
> > #8 0x0808fe8c in apr_pool_userdata_get (data=0x80be9fc,
> > key=0x400 <Address 0x400 out of bounds>, cont=0xbffff65c)
> > at apr_pools.c:1221
> > #9 0x0808ff00 in psprintf_flush (vbuff=0x80be9fc) at apr_pools.c:1289
> > #10 0x08067d15 in usage (process=0x80bea74) at main.c:258
> > #11 0x08068425 in get_addresses (p=0x1, w_=0xbffff754 "×øÿ¿",
> > paddr=0xbffff75c, default_port=134600058) at vhost.c:220
> > #12 0x4013f0de in ?? ()
> >
Re: [PATCH] mod_include fix (only show stopper in 2.0.24...)
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Looks like a bug useing apr_vrformatter ... Cody's patch, perhaps?
----- Original Message -----
From: "Greg Ames" <gr...@remulak.net>
To: <ne...@apache.org>
Sent: Friday, August 17, 2001 1:51 PM
Subject: Re: [PATCH] mod_include fix (only show stopper in 2.0.24...)
> Greg Ames wrote:
> >
> > noticed this in the error_log on my ThinkPad:
> >
> > [Fri Aug 17 13:11:24 2001] [notice] caught SIGTERM, shutting down
> > [Fri Aug 17 13:11:24 2001] [notice] seg fault or similar nasty error
> > detected in the parent process
>
> I can't make any sense out of the dump, nor can I re-create the problem,
> even with Jeff's one-liner to mod_include backed out. I'm writing this
> one off as sunspots, gamma rays or panty hose.
>
> Greg
>
> p.s. please speak up if this makes more sense to you.
>
> (gdb) bt
> #0 0x40009a61 in ?? ()
> #1 0x4000d360 in ?? ()
> #2 0x4000d510 in ?? ()
> #3 0x401160fe in ?? ()
> #4 0x4014fb68 in ?? ()
> #5 0x0808fd19 in apr_palloc (a=0x80e4c74, reqsize=1024) at
> apr_pools.c:1100
> #6 0x0808fea2 in apr_pool_userdata_get (data=0x80c0a0c, key=0x80c0a0c
> "",
> cont=0xbffff638) at apr_pools.c:1222
> #7 0x0808ff00 in psprintf_flush (vbuff=0x80c0a0c) at apr_pools.c:1289
> #8 0x0808fe8c in apr_pool_userdata_get (data=0x80be9fc,
> key=0x400 <Address 0x400 out of bounds>, cont=0xbffff65c)
> at apr_pools.c:1221
> #9 0x0808ff00 in psprintf_flush (vbuff=0x80be9fc) at apr_pools.c:1289
> #10 0x08067d15 in usage (process=0x80bea74) at main.c:258
> #11 0x08068425 in get_addresses (p=0x1, w_=0xbffff754 "×øÿ¿",
> paddr=0xbffff75c, default_port=134600058) at vhost.c:220
> #12 0x4013f0de in ?? ()
>
Re: [PATCH] mod_include fix (only show stopper in 2.0.24...)
Posted by Greg Ames <gr...@remulak.net>.
Greg Ames wrote:
>
> noticed this in the error_log on my ThinkPad:
>
> [Fri Aug 17 13:11:24 2001] [notice] caught SIGTERM, shutting down
> [Fri Aug 17 13:11:24 2001] [notice] seg fault or similar nasty error
> detected in the parent process
I can't make any sense out of the dump, nor can I re-create the problem,
even with Jeff's one-liner to mod_include backed out. I'm writing this
one off as sunspots, gamma rays or panty hose.
Greg
p.s. please speak up if this makes more sense to you.
(gdb) bt
#0 0x40009a61 in ?? ()
#1 0x4000d360 in ?? ()
#2 0x4000d510 in ?? ()
#3 0x401160fe in ?? ()
#4 0x4014fb68 in ?? ()
#5 0x0808fd19 in apr_palloc (a=0x80e4c74, reqsize=1024) at
apr_pools.c:1100
#6 0x0808fea2 in apr_pool_userdata_get (data=0x80c0a0c, key=0x80c0a0c
"",
cont=0xbffff638) at apr_pools.c:1222
#7 0x0808ff00 in psprintf_flush (vbuff=0x80c0a0c) at apr_pools.c:1289
#8 0x0808fe8c in apr_pool_userdata_get (data=0x80be9fc,
key=0x400 <Address 0x400 out of bounds>, cont=0xbffff65c)
at apr_pools.c:1221
#9 0x0808ff00 in psprintf_flush (vbuff=0x80be9fc) at apr_pools.c:1289
#10 0x08067d15 in usage (process=0x80bea74) at main.c:258
#11 0x08068425 in get_addresses (p=0x1, w_=0xbffff754 "×øÿ¿",
paddr=0xbffff75c, default_port=134600058) at vhost.c:220
#12 0x4013f0de in ?? ()
Re: [PATCH] mod_include fix (only show stopper in 2.0.24...)
Posted by Greg Ames <gr...@remulak.net>.
Bill Stoddard wrote:
>
> Have we rolled 2.0.24 yet? I think this was the last showstopper.
>
> +1 on committing, push the tag and roll.
>
+1 on committing & pushing the mod_include tag. Serving mod_include's
manual page is working, as Jeff already knows. I was about to slap the
patch onto daedalus and try the log replay again, then noticed this in
the error_log on my ThinkPad:
[Fri Aug 17 13:11:24 2001] [notice] caught SIGTERM, shutting down
[Fri Aug 17 13:11:24 2001] [notice] seg fault or similar nasty error
detected in the parent process
[Fri Aug 17 13:11:51 2001] [notice] Apache/2.0.24-dev (Unix) configured
-- resuming normal operations
and yes, I do have a core dump now that I've got "User webuser" in the
config file.
The fun never stops.
Greg
Re: [PATCH] mod_include fix (only show stopper in 2.0.24...)
Posted by Daniel Stone <da...@sfarc.net>.
On Fri, Aug 17, 2001 at 12:16:08PM -0500, William A. Rowe, Jr. wrote:
> From: "Bill Stoddard" <bi...@wstoddard.com>
> Sent: Friday, August 17, 2001 12:06 PM
>
>
> > Have we rolled 2.0.24 yet? I think this was the last showstopper.
> >
> > +1 on committing, push the tag and roll.
>
> Hold up, I'm finished as well, but Jeff Trawick's patches to fix the segfaults
> in mod_ssl should probably be pushed as well. Jeff, if you agree, please patch
> and push the tags of anything that you trust to resolve segfaults.
>
> [Segfaults are very nasty to spmt MPMs :-]
+1 on committing the mod_ssl and mod_include fixes, pushing the tag, and
rolling.
:) d
--
Daniel Stone <da...@sfarc.net>
* illuzion is away - watching pretty flashy lights - messages will be
translated into FORTRAN and fed to an obese wombat
Re: [PATCH] mod_include fix (only show stopper in 2.0.24...)
Posted by Jeff Trawick <tr...@attglobal.net>.
"William A. Rowe, Jr." <wr...@rowe-clan.net> writes:
> From: "Bill Stoddard" <bi...@wstoddard.com>
> Sent: Friday, August 17, 2001 12:06 PM
>
>
> > Have we rolled 2.0.24 yet? I think this was the last showstopper.
> >
> > +1 on committing, push the tag and roll.
>
> Hold up, I'm finished as well, but Jeff Trawick's patches to fix the segfaults
> in mod_ssl should probably be pushed as well. Jeff, if you agree, please patch
> and push the tags of anything that you trust to resolve segfaults.
got simple instructions for me?
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: [PATCH] mod_include fix (only show stopper in 2.0.24...)
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Bill Stoddard" <bi...@wstoddard.com>
Sent: Friday, August 17, 2001 12:06 PM
> Have we rolled 2.0.24 yet? I think this was the last showstopper.
>
> +1 on committing, push the tag and roll.
Hold up, I'm finished as well, but Jeff Trawick's patches to fix the segfaults
in mod_ssl should probably be pushed as well. Jeff, if you agree, please patch
and push the tags of anything that you trust to resolve segfaults.
[Segfaults are very nasty to spmt MPMs :-]
> ----- Original Message -----
> From: "Jeff Trawick" <tr...@attglobal.net>
> To: <ne...@apache.org>
> Sent: Friday, August 17, 2001 11:19 AM
> Subject: [PATCH] mod_include fix
>
>
> > In the "2.0.24 tagged" thread, Greg mentioned a problem with
> > mod_include. This fixes it for me.
> >
> > We're in find_end_sequence() walking over the directive and the rest
> > of the tag but we stop parsing so we don't walk over too much storage
> > (e.g., mmap) at once). When we resume later, ctx->directive_length
> > has the value it had when we bailed out, so directive_length is wrong
> > and we hit errors like:
> >
> > [Fri Aug 17 11:12:06 2001] [error] [client 127.0.0.1] unknown directiv
> > e "include virt" in parsed doc /home/trawick/apacheinst/htdocs/manual/
> > mod/mod_include.html
> >
> > If anyone else is hitting similar problems, please try this patch.
> >
> > Index: modules/filters/mod_include.c
> > ===================================================================
> > RCS file: /home/cvspublic/httpd-2.0/modules/filters/mod_include.c,v
> > retrieving revision 1.121
> > diff -u -r1.121 mod_include.c
> > --- modules/filters/mod_include.c 2001/08/11 04:04:12 1.121
> > +++ modules/filters/mod_include.c 2001/08/17 15:09:26
> > @@ -270,6 +270,8 @@
> > }
> > while (c < buf + len) {
> > if (ctx->bytes_parsed >= BYTE_COUNT_THRESHOLD) {
> > + /* gonna start over parsing the directive next time through */
> > + ctx->directive_length = 0;
> > return dptr;
> > }
> >
> >
> > --
> > Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
> > http://www.geocities.com/SiliconValley/Park/9289/
> > Born in Roswell... married an alien...
> >
>
>
Re: [PATCH] mod_include fix (only show stopper in 2.0.24...)
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Simple way? set aside the 2.0.25 text in another file, commit your
update, push the tag and paste/commit the 2.0.25 changes.
While you are in there, could you add these please;
*) Numerous improvements to the Win32 build system. Introduced command line
builds without requiring .mak files for MSVC 6.0 and later versions.
Improved .dsp file compatibility for both Visual Studio 5.0 and 6.0 users.
[William Rowe]
*) Assorted corrections and improvements to the winnt_mpm startup code. Better
reporting of uninstalled services and other error conditions, and changed the
default service name to Apache2. [William Rowe]
*) Numerous improvements to the Win32 ApacheMonitor utility, including winnt_mpm
compatibility with existing Apache 1.3 Win32 Apache management utilites.
[Mladen Turk <mt...@mappingsoft.com>, William Rowe]
----- Original Message -----
From: "Jeff Trawick" <tr...@attglobal.net>
To: <ne...@apache.org>
Sent: Friday, August 17, 2001 12:26 PM
Subject: Re: [PATCH] mod_include fix (only show stopper in 2.0.24...)
> "Bill Stoddard" <bi...@wstoddard.com> writes:
>
> > Have we rolled 2.0.24 yet? I think this was the last showstopper.
> >
> > +1 on committing, push the tag and roll.
>
> I'll commit now...
>
> Somebody else can play with the mod_include.c tag. How would
> something be added to the 2.0.24 version of CHANGES at this point?
>
> --
> Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
> http://www.geocities.com/SiliconValley/Park/9289/
> Born in Roswell... married an alien...
>
Re: [PATCH] mod_include fix (only show stopper in 2.0.24...)
Posted by Jeff Trawick <tr...@attglobal.net>.
"Bill Stoddard" <bi...@wstoddard.com> writes:
> Have we rolled 2.0.24 yet? I think this was the last showstopper.
>
> +1 on committing, push the tag and roll.
I'll commit now...
Somebody else can play with the mod_include.c tag. How would
something be added to the 2.0.24 version of CHANGES at this point?
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: [PATCH] mod_include fix (only show stopper in 2.0.24...)
Posted by Bill Stoddard <bi...@wstoddard.com>.
Have we rolled 2.0.24 yet? I think this was the last showstopper.
+1 on committing, push the tag and roll.
Bill
----- Original Message -----
From: "Jeff Trawick" <tr...@attglobal.net>
To: <ne...@apache.org>
Sent: Friday, August 17, 2001 11:19 AM
Subject: [PATCH] mod_include fix
> In the "2.0.24 tagged" thread, Greg mentioned a problem with
> mod_include. This fixes it for me.
>
> We're in find_end_sequence() walking over the directive and the rest
> of the tag but we stop parsing so we don't walk over too much storage
> (e.g., mmap) at once). When we resume later, ctx->directive_length
> has the value it had when we bailed out, so directive_length is wrong
> and we hit errors like:
>
> [Fri Aug 17 11:12:06 2001] [error] [client 127.0.0.1] unknown directiv
> e "include virt" in parsed doc /home/trawick/apacheinst/htdocs/manual/
> mod/mod_include.html
>
> If anyone else is hitting similar problems, please try this patch.
>
> Index: modules/filters/mod_include.c
> ===================================================================
> RCS file: /home/cvspublic/httpd-2.0/modules/filters/mod_include.c,v
> retrieving revision 1.121
> diff -u -r1.121 mod_include.c
> --- modules/filters/mod_include.c 2001/08/11 04:04:12 1.121
> +++ modules/filters/mod_include.c 2001/08/17 15:09:26
> @@ -270,6 +270,8 @@
> }
> while (c < buf + len) {
> if (ctx->bytes_parsed >= BYTE_COUNT_THRESHOLD) {
> + /* gonna start over parsing the directive next time through */
> + ctx->directive_length = 0;
> return dptr;
> }
>
>
> --
> Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
> http://www.geocities.com/SiliconValley/Park/9289/
> Born in Roswell... married an alien...
>