You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Greg Stein <gs...@lyra.org> on 2002/05/31 20:36:38 UTC

Re: SEGV in head

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/

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