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." <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> 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." <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> > 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 > >
