www-apache-bugdb mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <ad...@rowe-clan.net>
Subject Re: general/7525: Apache SEGFAULTS when started (see below)
Date Thu, 05 Apr 2001 16:30:00 GMT
The following reply was made to PR general/7525; it has been noted by GNATS.

From: "William A. Rowe, Jr." <admin@rowe-clan.net>
To: <apache-bugdb@apache.org>, <mvz@crol.cz>, <submit@bugz.apache.org>
Cc:  
Subject: Re: general/7525: Apache SEGFAULTS when started (see below)
Date: Thu, 5 Apr 2001 09:21:50 -0700

 > >Release:        2.0.16
 > >Environment:
 > OS: Linux (RedBug 7.0)
 > Kernel: linux-2.4.3
 > glibc: 2.2
 > gcc: 2.96
 > CFLAGS: "-g" (for second time - eh :-) ...)
 > ld: GNU ld 2.10.90
 
 This looks _very_ familiar...
 
 > #0  0x080b1373 in apr_hash_get (ht=Error accessing memory address 0x82cfd3a5: No such
process.
 > ) at apr_hash.c:266
 > 266         for (hep = &ht->array[hash & ht->max], he = *hep;(gdb) where
 > #0  0x080b1373 in apr_hash_get (ht=Error accessing memory address 0x82cfd3a5: No such
process.
 > ) at apr_hash.c:266
 > #1  0x40236660 in __morecore () from /lib/libc.so.6
 > Error accessing memory address 0x82cfd365: No such process.
 > (gdb)q
 > 
 > >How-To-Repeat:
 > Don't know... try to compile that version of apache on same configuration with
 > same options... ?
 > >Fix:
 > Sorry, I'm not C programmer, but I'm very good bug reporter. :-)
 > 
 > Maybe pthread implementation on Linux?
 
 
 apr_hash gets me, we use that code within the apr_register_optional_fn code, and perhaps
 we have trashed the stack on linux.
 
 The bugfix I committed last night is very win32 specific, though.  It resolved the ambiguity
 of taking the apr_register_optional_fn 's address (which was stdcall) and reforming a fn
 pointer (which was cdecl).  By changing apr_register_optional_fn() to _NONSTD, we walk away
 from this problem.
 
 But there may be other platforms where this behavior is simply evil.  Any platform that
 encodes call/return information _might_ have trouble doing so to the optional fn pointer.
 
 And one last note, Ben acks the problem but I don't see a reminder in status.  It is very,
 very WRONG to use a void* as a void (*)(void)!!!  And the void* is what we stuff into the
 hash.  Now I wouldn't be against an apr_anyvoid_t that is the minimum size of either a
 data or fn pointer, to retain the ambiguity.  That might not be too ethical either, but
 at least we won't overflow on the odder platforms.
 
 Anyone have a RedBug 7.0 linux-2.4.3 glibc 2.2 that could replicate?
 
 Bill
 

Mime
View raw message