You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Cliff Woolley <jw...@virginia.edu> on 2002/05/31 18:26:36 UTC
SEGV in head (was Re: Links on http://xml.apache.org/axis are
incorrect)
On Fri, 31 May 2002, Cliff Woolley wrote:
> Okay, I've bumped icarus back down to the version of httpd it was running
> yesterday (2.0.37-dev from a week ago). No more segfaults. I'll analyze
> the corefiles from the new version. Thanks for letting me know.
Okay, so HEAD from last night caused the following segfault on the URL
http://cvs.apache.org/viewcvs.cgi/~checkout~/xml-axis/java/docs/install.html
I have three corefiles, but they're all the same. They're in
/usr/local/apache2.0.37-dev3/corefiles and are against the
/usr/local/apache2.0.37-dev3/bin/httpd binary.
--Cliff
(gdb) bt
#0 0x281de546 in strchr () from /usr/lib/libc.so.4
#1 0x80c6444 in __DTOR_END__ ()
#2 0x8085b82 in translate_userdir (r=0x816a050) at mod_userdir.c:320
#3 0x80a7594 in ap_run_translate_name (r=0x816a050) at request.c:108
#4 0x80a8384 in ap_process_request_internal (r=0x816a050) at request.c:167
#5 0x80aaa53 in ap_sub_req_method_uri (method=0x80c1471 "GET",
new_file=0x816f838 "/~checkout~/xml-axis/java/docs/install.html",
r=0x8170050, next_filter=0x0) at request.c:1639
#6 0x80aaaac in ap_sub_req_lookup_uri (
new_file=0x816f838 "/~checkout~/xml-axis/java/docs/install.html",
r=0x8170050, next_filter=0x0) at request.c:1651
#7 0x8095fc8 in ap_add_cgi_vars (r=0x8170050) at util_script.c:404
#8 0x807c011 in run_cgi_child (script_out=0xbfbff71c, script_in=0xbfbff718,
script_err=0xbfbff714, command=0x81713f7 "viewcvs.cgi", argv=0x816f7e0,
r=0x8170050, p=0x8170018, e_info=0xbfbff6d4) at mod_cgi.c:436
#9 0x807ca85 in cgi_handler (r=0x8170050) at mod_cgi.c:686
#10 0x80895c0 in ap_run_handler (r=0x8170050) at config.c:193
#11 0x8089ec2 in ap_invoke_handler (r=0x8170050) at config.c:373
#12 0x8071cb8 in ap_process_request (r=0x8170050) at http_request.c:268
#13 0x806aef7 in ap_process_http_connection (c=0x815b120) at http_core.c:291
#14 0x8097af4 in ap_run_process_connection (c=0x815b120) at connection.c:85
#15 0x8097f80 in ap_process_connection (c=0x815b120, csd=0x815b050)
at connection.c:207
#16 0x80878de in child_main (child_num_arg=14) at prefork.c:671
#17 0x8087ab9 in make_child (s=0x810e680, slot=14) at prefork.c:765
#18 0x8087d9b in perform_idle_server_maintenance (p=0x80d2018) at prefork.c:900
#19 0x808825b in ap_mpm_run (_pconf=0x80d2018, plog=0x810a018, s=0x810e680)
at prefork.c:1093
#20 0x808fca7 in main (argc=3, argv=0xbfbffb1c) at main.c:646
#21 0x805e9b5 in _start ()
Re: SEGV in head (was Re: Links on http://xml.apache.org/axis are incorrect)
Posted by Greg Stein <gs...@lyra.org>.
On Fri, May 31, 2002 at 01:05:34PM -0400, Jeff Trawick wrote:
> Justin Erenkrantz <je...@apache.org> writes:
>
> > On Fri, May 31, 2002 at 12:40:03PM -0400, Jeff Trawick wrote:
> > > It looks to me that this code in translate_userdir() is referencing x
> > > whether or not the char was found (by ap_strchr_c()). I haven't
> > > looked in the coredump to verify that was the problem for this
> > > segfault.
> >
> > I agree. Anyone think this wouldn't do the trick? -- justin
>
> looks fine... the only difference between that and what I coded up is
> that I moved the decl for x down to line 290 to shorten the search for
> where x is used :)
What the hell is "x" ?? Damn. That code should have a USEFUL variable name...
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: SEGV in head (was Re: Links on http://xml.apache.org/axis are incorrect)
Posted by Justin Erenkrantz <je...@apache.org>.
On Fri, May 31, 2002 at 01:05:34PM -0400, Jeff Trawick wrote:
> looks fine... the only difference between that and what I coded up is
> that I moved the decl for x down to line 290 to shorten the search for
> where x is used :)
And I caught that too when I went to commit it. =) -- justin
Re: SEGV in head (was Re: Links on http://xml.apache.org/axis are incorrect)
Posted by Jeff Trawick <tr...@attglobal.net>.
Justin Erenkrantz <je...@apache.org> writes:
> On Fri, May 31, 2002 at 12:40:03PM -0400, Jeff Trawick wrote:
> > It looks to me that this code in translate_userdir() is referencing x
> > whether or not the char was found (by ap_strchr_c()). I haven't
> > looked in the coredump to verify that was the problem for this
> > segfault.
>
> I agree. Anyone think this wouldn't do the trick? -- justin
looks fine... the only difference between that and what I coded up is
that I moved the decl for x down to line 290 to shorten the search for
where x is used :)
> Index: modules/mappers/mod_userdir.c
> ===================================================================
> RCS file: /home/cvs/httpd-2.0/modules/mappers/mod_userdir.c,v
> retrieving revision 1.48
> diff -u -r1.48 mod_userdir.c
> --- modules/mappers/mod_userdir.c 28 May 2002 23:14:15 -0000 1.48
> +++ modules/mappers/mod_userdir.c 31 May 2002 16:43:42 -0000
> @@ -317,7 +317,7 @@
> else
> filename = apr_pstrcat(r->pool, userdir, "/", w, NULL);
> }
> - else if (ap_strchr_c(x, ':')) {
> + else if (x && ap_strchr_c(x, ':')) {
> redirect = apr_pstrcat(r->pool, x, w, dname, NULL);
> apr_table_setn(r->headers_out, "Location", redirect);
> return HTTP_MOVED_TEMPORARILY;
>
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: SEGV in head (was Re: Links on http://xml.apache.org/axis are
incorrect)
Posted by Cliff Woolley <jw...@virginia.edu>.
On Fri, 31 May 2002, Justin Erenkrantz wrote:
> - else if (ap_strchr_c(x, ':')) {
> + else if (x && ap_strchr_c(x, ':')) {
+1. This looks correct to me.
--Cliff
Re: SEGV in head (was Re: Links on http://xml.apache.org/axis are incorrect)
Posted by Justin Erenkrantz <je...@apache.org>.
On Fri, May 31, 2002 at 12:40:03PM -0400, Jeff Trawick wrote:
> It looks to me that this code in translate_userdir() is referencing x
> whether or not the char was found (by ap_strchr_c()). I haven't
> looked in the coredump to verify that was the problem for this
> segfault.
I agree. Anyone think this wouldn't do the trick? -- justin
Index: modules/mappers/mod_userdir.c
===================================================================
RCS file: /home/cvs/httpd-2.0/modules/mappers/mod_userdir.c,v
retrieving revision 1.48
diff -u -r1.48 mod_userdir.c
--- modules/mappers/mod_userdir.c 28 May 2002 23:14:15 -0000 1.48
+++ modules/mappers/mod_userdir.c 31 May 2002 16:43:42 -0000
@@ -317,7 +317,7 @@
else
filename = apr_pstrcat(r->pool, userdir, "/", w, NULL);
}
- else if (ap_strchr_c(x, ':')) {
+ else if (x && ap_strchr_c(x, ':')) {
redirect = apr_pstrcat(r->pool, x, w, dname, NULL);
apr_table_setn(r->headers_out, "Location", redirect);
return HTTP_MOVED_TEMPORARILY;
Re: SEGV in head (was Re: Links on http://xml.apache.org/axis are incorrect)
Posted by Jeff Trawick <tr...@attglobal.net>.
Cliff Woolley <jw...@virginia.edu> writes:
> On Fri, 31 May 2002, Cliff Woolley wrote:
>
> > Okay, I've bumped icarus back down to the version of httpd it was running
> > yesterday (2.0.37-dev from a week ago). No more segfaults. I'll analyze
> > the corefiles from the new version. Thanks for letting me know.
>
> Okay, so HEAD from last night caused the following segfault on the URL
> http://cvs.apache.org/viewcvs.cgi/~checkout~/xml-axis/java/docs/install.html
>
> I have three corefiles, but they're all the same. They're in
> /usr/local/apache2.0.37-dev3/corefiles and are against the
> /usr/local/apache2.0.37-dev3/bin/httpd binary.
>
> --Cliff
>
> (gdb) bt
> #0 0x281de546 in strchr () from /usr/lib/libc.so.4
> #1 0x80c6444 in __DTOR_END__ ()
> #2 0x8085b82 in translate_userdir (r=0x816a050) at mod_userdir.c:320
It looks to me that this code in translate_userdir() is referencing x
whether or not the char was found (by ap_strchr_c()). I haven't
looked in the coredump to verify that was the problem for this
segfault.
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: SEGV in head
Posted by Cliff Woolley <jw...@virginia.edu>.
On Fri, 31 May 2002, Greg Stein wrote:
> Ah. It wants to take the rest of the path (after the CGI script; the
> "/~checkout~/..." part), assume it is a URI, and try to translate that into
> a filename. If it is successful, it stores that into PATH_TRANSLATED.
> Wow. What possible utility does that serve?
It allows the script to process the actual file referenced by that URI (as
in PATH_INFO-style) as an "action", basically. So let's say I have a URI:
/cgi-bin/processit.cgi/foo/bar.html
And processit.cgi reads html files and manipulates them in some way.
processit.cgi needs to know the actual location of /foo/bar.html in the
filesystem. PATH_TRANSLATED is how it does that.
I've actually used this functionality before, it's quite handy. :)
--Cliff
Re: SEGV in head
Posted by Greg Stein <gs...@lyra.org>.
On Fri, May 31, 2002 at 12:26:36PM -0400, Cliff Woolley wrote:
>...
> Okay, so HEAD from last night caused the following segfault on the URL
> http://cvs.apache.org/viewcvs.cgi/~checkout~/xml-axis/java/docs/install.html
>
> I have three corefiles, but they're all the same. They're in
> /usr/local/apache2.0.37-dev3/corefiles and are against the
> /usr/local/apache2.0.37-dev3/bin/httpd binary.
>
> --Cliff
>
> (gdb) bt
> #0 0x281de546 in strchr () from /usr/lib/libc.so.4
> #1 0x80c6444 in __DTOR_END__ ()
> #2 0x8085b82 in translate_userdir (r=0x816a050) at mod_userdir.c:320
I'd like to know *how* it even got to that code. Right at the top of
translate_userdir(), there are the following lines:
/*
* If the URI doesn't match our basic pattern, we've nothing to do with
* it.
*/
if (name[0] != '/' || name[1] != '~') {
return DECLINED;
}
[ where name == r->uri ]
So how does the above URL match that at all? Shouldn't r->uri be equal to
"/viewcvs.cgi/~checkout~/..."
???
> #3 0x80a7594 in ap_run_translate_name (r=0x816a050) at request.c:108
> #4 0x80a8384 in ap_process_request_internal (r=0x816a050) at request.c:167
> #5 0x80aaa53 in ap_sub_req_method_uri (method=0x80c1471 "GET",
> new_file=0x816f838 "/~checkout~/xml-axis/java/docs/install.html",
> r=0x8170050, next_filter=0x0) at request.c:1639
> #6 0x80aaaac in ap_sub_req_lookup_uri (
> new_file=0x816f838 "/~checkout~/xml-axis/java/docs/install.html",
> r=0x8170050, next_filter=0x0) at request.c:1651
> #7 0x8095fc8 in ap_add_cgi_vars (r=0x8170050) at util_script.c:404
Oh!! Just had to read further down the stack. What the hell is happening
here?
Ah. It wants to take the rest of the path (after the CGI script; the
"/~checkout~/..." part), assume it is a URI, and try to translate that into
a filename. If it is successful, it stores that into PATH_TRANSLATED.
Wow. What possible utility does that serve?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/