httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <ad...@rowe-clan.net>
Subject Fw: general/7525: Apache SEGFAULTS when started (see below)
Date Thu, 05 Apr 2001 19:08:20 GMT
This was ment for this list.  BTW - includes (when tags are properly formed) does
work, but fails in nasty ways when endtags are mis-formed.

----- Original Message ----- 
From: "William A. Rowe, Jr." <admin@rowe-clan.net>
To: <apache-bugdb@apache.org>
Cc: <apache-bugdb@apache.org>
Sent: Thursday, April 05, 2001 9:30 AM
Subject: Re: general/7525: Apache SEGFAULTS when started (see below)


> 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