httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject [Fwd: segfault when r->filename is NULL]
Date Sun, 15 Dec 2002 11:34:33 GMT
I've posted this problem and the research that I've done, 1.5 months ago 
without any followups. Apache still segfaults. Can anybody please look into 
it? Thanks.

-------- Original Message --------

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.

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.

The bt of segfault:

(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


__________________________________________________________________
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



Mime
View raw message