Greg Ames wrote: > I don't remember seeing a fix for the recursive subrequest loops involving > mod_negotiation.
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). So I vi'd the 4 dumps, looking for the input buffers. They all reference host: jakarta.apache.org, and the request lines look very similar: GET /builds/tomcat/release/v3.1/bin/ <== two of these GET /builds/tomcat/release/v3.2/bin/ GET /builds/jakarta-tomcat/release/v3.2/bin/ /builds/tomcat/ is redirected to /builds/jakarta-tomcat/ via an .htaccess file, so 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? * 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. * 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. Greg
