Bill Stoddard wrote:
>
> The problem is that we are creating an extension_info out of a subrequest pool and
> sticking it into a longer lived hash table (allocated out of the request pool I'm
> guessing). When we pull the extension_info out of the hash table later and try to
>use it,
> we seg fault because the storage has been reused for something else. No thoughts on
>a fix.
This fixes the seg fault on my Linux box:
Index: modules/http/mod_mime.c
===================================================================
RCS file: /home/cvs/httpd-2.0/modules/http/mod_mime.c,v
retrieving revision 1.50
diff -u -d -b -r1.50 mod_mime.c
--- modules/http/mod_mime.c 2001/08/14 02:35:55 1.50
+++ modules/http/mod_mime.c 2001/08/14 19:39:45
@@ -220,13 +220,10 @@
attrib_info *suffix;
if (base->extension_mappings && add->extension_mappings) {
- if (base->copy_mappings)
- new->extension_mappings = base->extension_mappings;
- else {
new->extension_mappings = apr_hash_make(p);
overlay_extension_mappings(p, base->extension_mappings,
new->extension_mappings);
- }
+
overlay_extension_mappings(p, add->extension_mappings,
new->extension_mappings);
We can't allow overlay_extension_mappings to store things into the
extension_mappings hash table which have a shorter lifetime than the
hash table itself. Always using a new extension_mappings prevents this
from happening.
I'll commit this in a little while unless someone objects soon.
Greg
Greg
