From: "Greg Ames" <[EMAIL PROTECTED]> Sent: Thursday, January 24, 2002 11:01 AM
> some more info on this problem. gdb refuses to produce a decent backtrace from > the coredumps, maybe because of the unusual depth of the call stack. So I had a > hard time getting any meaningful info that way. But we do have the backtrace > from when I attached gdb to a live looping process - the message ID is in the > STATUS file (thanks, Justin). > > GET /builds/jakarta-tomcat/release/v3.2/bin/ > > the bottom two refer to the same thing. All of these refer to paths that no > longer exist: > > [gregames@daedalus gregames]$ ls > /www/jakarta.apache.org/builds/jakarta-tomcat/release > CVS v3.2.3 v3.2.4-beta-1 v3.3.old > v3.1.1 v3.2.4 v3.3 > > The backtrace I posted showed that apr_filepath_merge's addpath arg was > "builds/tomcat/release/v3.1/v3.1.1/v3.1.1/v3.1.1/..." This comes from > r->filename in ap_directory_walk. That seems odd in a few ways, beside the ever > growing bogus path. > > * why would we try to negotiate at all, when the only candidates are > directories, not files? BINGO. /builds/jakarta-tomcat/release/v3.2 [path info = /bin/] ... file not found. Not found? We attempt to negotiate. Now, what's broke about /v3.2 ? That is a danged good question, not one I have an easy answer to. Could we have a lingering 'is dir' status? Good question. I suspect that could be it; a recent OPTIMIZATION to dir_walk tells it to trust the finfo if it's already present in the structure. Now; we should be failing each of the v3.2.3, v.3.2.4, v.3.2.4-beta-1 items in mod_negotiation, since they are directories. BUT [here's the critical but] if we polluted the request rec's finfo, then bang, we blew it. Something smells here; maybe mod_negotiation now fails to test for 'is a dir', maybe mod_negotiation also fails to wipe out the earlier path [v3.1 +/+ v3.1.1], maybe the set-aside path_info was wrong. Any which way, you are on to something, Greg, and it has nothing to do with the redirection aspect, or autoindex, IMHO. But sub_req_lookup_dirent is also suspect. > * it looks like we might be triggering some 1.3 negotiation behavior, where any > extention under the sun is a match. We use MultiviewsMatch Handlers, so .asis > and .cgi extentions do not need to be specified in the URI. Exactly. We should be triggering negotation (v3.1 and v3.2 not found). But we should be ignoring dirs. > * why do we see /builds/tomcat/ rather than /builds/jakarta-tomcat/ in > r->filename? I would think the redirect would happen early, and subsequent > filenames would contain the new path. Probably not important, because we got > the same loop when jakarta-tomcat was part of the original URI. Agreed this is somewhat irrelevant, at this moment :) Bill
