segfault when r->filename is NULL

[Stas Bekman <st...@stason.org>]

In apache-1.3 it was possible to shortcut the translation handler, by
returning OK right away, thus saving several stat() syscalls when you
knew that your handler is virtual and doesn't need to run the
uri->filename translation.

In httpd-2.0 this doesn't work anymore. mod_mime's find_ct() segfaults
at:

     if ((fn = strrchr(r->filename, '/')) == NULL) {
         fn = r->filename;
     }

because shortcutting the trans handler leaves r->filename equal to NULL.

(gdb) where
#0  0x402f30e3 in ?? () from /lib/i686/libc.so.6
#1  0x080d1d8b in ap_run_type_checker (r=0x8684f98) at request.c:116
#2  0x080d2353 in ap_process_request_internal (r=0x0) at request.c:271
#3  0x08097509 in ap_process_request (r=0x86106ec) at http_request.c:286
#4  0x08093489 in ap_process_http_connection (c=0x867f088) at 
http_core.c:293
#5  0x080c76ab in ap_run_process_connection (c=0x867f088) at connection.c:85
#6  0x080bcaf4 in child_main (child_num_arg=0) at prefork.c:696
#7  0x080bcc9d in make_child (s=0x815d2e0, slot=0) at prefork.c:736
#8  0x080bccfe in startup_children (number_to_start=4) at prefork.c:808
#9  0x080bd43b in ap_mpm_run (_pconf=0x81109f0, plog=0x8156b08, 
s=0x810e9e8) at prefork.c:1024
#10 0x080c235d in main (argc=4, argv=0xbffff604) at main.c:645
#11 0x40296082 in ?? () from /lib/i686/libc.so.6

I've traced the difference to ap_directory_walk, where in 1.3 version
it did:

     if (r->filename == NULL) {
         r->filename = ap_pstrdup(r->pool, r->uri);
         r->finfo.st_mode = 0;   /* Not really a file... */
         r->per_dir_config = per_dir_defaults;

         return OK;
     }

whereas in 2.0 it does:

     if (r->filename == NULL) {
         ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r,
                       "Module bug?  Request filename is missing for URI 
%s",
                       r->uri);
        return OK;
     }

hence the segfault.

I understand that the shortcutting trick worked in 1.3 only because
the default core_map_to_storage() was executed, which was fixing-up
the r->filename.

So I've two questions:

1) when the default trans handler fails to locate the file on the
    filesystem, it assigns the
    r->uri to it. but this is not a filename. why not init filename to
    "", when the r object is created and then one doesn't need to find
    workarounds to set r->filename to a non-existing path.

2) shouldn't Apache cleanly assert if after the translation
    phase r->filename is still NULL? segfaulting doesn't help the
    module authors to trace the problem. Especially as you can see from
    the trace I've attached the trace is not very useful, and I had to
    step through with debugger to find the offending code.

    I'm not sure what's the best place for this check, but probably
    right after:

         if ((access_status = ap_run_translate_name(r))) {
             return decl_die(access_status, "translate", r);
         }

is the obvious place.

__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com