For now, I'll add a check to mod_mime to keep it from
segfaulting.
Perhaps we should also fix the root cause by either setting
r->filename to "" instead of NULL in 2.x's directory_walk.
I don't have a strong opinion on that part, though, so I'll
defer to anyone else who does.
Brian
On Sun, 2002-12-15 at 03:34, Stas Bekman wrote:
> 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:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
>
