httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rasmus Lerdorf <ras...@lerdorf.on.ca>
Subject Re: mod_rewrite doesn't compile on Red Hat 6.0
Date Tue, 18 May 1999 12:32:47 GMT
> RedHat (or more correct glibc 2.1) is brain dead in moving ndbm.h to a db1/
> subdir. "#include <ndbm.h>" is the correct Unix-historic thing and when a
> vendor breaks this he is broken and not Apache. Sure, we've to find a
> workaround, of course. But I hate this stuff. And BTW, it's not only
> mod_rewrite: All modules which use NDBM (i.e. mod_rewrite, mod_auth_dbm,
> mod_ssl, mod_dav, etc. pp) have the same problem. I'll think about what the
> best workaround is for 1.3.7...

There are also some other problems with glibc-2.1.1.  I spent most of
Sunday trying to track down a weird bug.  I finally did find it, but I
still don't quite understand the reason for it.  I'll describe it briefly
here in case we might have the same thing somewhere in one of the Apache
modules.

The seg fault looked like this (reproduced on both Alpha and Intel):

  Program received signal SIGSEGV, Segmentation fault.
  0x2000065595c in _IO_new_fclose (fp=0x120188680) at iofclose.c:45
  iofclose.c:45: No such file or directory.

It happened only when this code was loaded dynamically:

First we registered a destructor function for a certain resource type.  In
this case it was the file pointer resource.  We just registered the
libc fclose() function directly.

...
GLOBAL(le_fp) = register_list_destructors(fclose,NULL); 
...

Then when it is time to clean up outstanding resources, the following
function gets called on each resource which in turn digs up the destructor
function for the resource and calls it.  

PHPAPI void list_entry_destructor(void *ptr) {
    list_entry *le = (list_entry *) ptr;
    list_destructors_entry *ld;
    TLS_VARS;
 
    if (_php3_hash_index_find(&GLOBAL(list_destructors),le->type,(void **)&ld)==SUCCESS)
{
        if (ld->list_destructor) {
            (ld->list_destructor)(le->ptr);    <== Crash was here
        }
    } else {
        php3_error(E_WARNING,"Unknown list entry type in request shutdown (%d)",le->type);
    }
} 

Now, this bit of code has worked fine for years, on all sorts of operating
systems and was fine in glibc-2.0.x as well.  But with glibc-2.1.1 when
this code is in a .so (works fine linked statically) it crashes.  The fix
was to do:

static void php3i_destructor_fclose(FILE *fp) {
    (void)fclose(fp);
}  
...
GLOBAL(le_fp) = register_list_destructors(php3i_destructor_fclose,NULL); 
...

ie. to wrap fclose() in our own function and use a pointer to our own
function instead of referencing the fclose function in libc directly.  

Perhaps it isn't a glibc bug, but rather a libdl bug.  But something is
certainly odd here on RH6.

-Rasmus


Mime
View raw message