Re: [PHP-DEV] Apache+php3 coredumps: more funk.. From: Rasmus Lerdorf (rasmus <email protected>)
Date: 11/07/99

Looks like an Apache header mismatch problem to me. Are you sure that the
Apache header files you are compiling PHP against matches the Apache you
are actually running?

On Fri, 5 Nov 1999, CyberPsychotic wrote:

> I am not sure if that's more apache bug than php, but here's what I found
> out: I am running apache+php3+mod_perl+fp extentions and I get a coredump
> whenever php3 script requested. Oddy enough, but when I recompiled php3
> module with -ggdb switch the problem has gone (mistery). However I've
> saved the sick binary (and I recompiled apache twice without -ggdb flag,
> coredump remained, so the problem is reproductable). Here's what I have
> been able to find out so far:
>
> The coredump is caused in php3_init_request_info routine:
>
> (gdb) where
> #0 0x809b692 in php3_init_request_info ()
> #1 0x8091174 in php3_request_startup ()
> #2 0x8092816 in apache_php3_module_main ()
> #3 0x808f956 in send_php3 ()
> #4 0x808f9d2 in send_parsed_php3 ()
> #5 0x80d9bb3 in ap_invoke_handler ()
> #6 0x80efd69 in ap_some_auth_required ()
> #7 0x80f01e4 in ap_internal_redirect ()
> #8 0x80886cd in mod_perl_set_opmask ()
> #9 0x80d9bb3 in ap_invoke_handler ()
> #10 0x80efd69 in ap_some_auth_required ()
> #11 0x80efdcc in ap_process_request ()
> #12 0x80e6239 in ap_child_terminate ()
> #13 0x80e64ac in ap_child_terminate ()
> #14 0x80e686a in ap_child_terminate ()
> #15 0x80e6df5 in ap_child_terminate ()
> #16 0x80e7563 in main ()
> #17 0x8067dfe in _start ()
> (gdb)
>
> And when we are about to call _estrdup...
>
> (gdb) x/20i php3_init_request_info
> 0x809b670 <php3_init_request_info>: push %ebp
> 0x809b671 <php3_init_request_info+1>: mov %esp,%ebp
> 0x809b673 <php3_init_request_info+3>: movl $0x0,0x81e1794
> 0x809b67d <php3_init_request_info+13>: movl $0x0,0x81e1798
> 0x809b687 <php3_init_request_info+23>: mov 0x81c06c0,%eax
> 0x809b68c <php3_init_request_info+28>: mov 0xbc(%eax),%eax
> 0x809b692 <php3_init_request_info+34>: push %eax <--- here
> 0x809b693 <php3_init_request_info+35>: call 0x8099500 <_estrdup>
> ...
>
> we are passing a nullpointer to the routine:
>
> (gdb) info regi eax
> eax 0x0 0
>
> in php3_init_request_info we basically just use `filename' which has been
> set in `r' struct earlier, and reassigned to php3_rqst in
> apache_php3_module_main later.
>
> #if APACHE
> int php3_init_request_info(void *conf)
> {
> const char *buf;
> TLS_VARS;
>
> GLOBAL(request_info).current_user = NULL;
> GLOBAL(request_info).current_user_length = 0;
>
> /* see above for why this has to be estrdup()'d */
> GLOBAL(request_info).filename = estrdup(GLOBAL(php3_rqst)->filename);
> ...
>
>
>
> so the filename is basically what we get get from apache. I am not quite
> sure why the filename goes as `NULL' here, need to dig into apache code
> alitle bit, but I am curious why not make php code alittle more error
> resistant?
>
> I would suggest following fix in alloc.c
>
> --- alloc.c.orig Fri Nov 5 20:23:02 1999
> +++ alloc.c Fri Nov 5 20:23:44 1999
> @@ -264,6 +264,8 @@
> int length;
> char *p;
>
> + if (!s) return NULL;
> +
> length = strlen(s)+1;
> BLOCK_INTERRUPTIONS;
> #if DEBUG
>
>
> and make apropriate sanity checks in every place where estrdup is being
> called from.
>
>
> If anyone with better understanding of apache code is willing to track
> down this problem, I am willing to help with further investigation.
>
>
> regards
> Fyodor
>
>
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, e-mail: php-dev-unsubscribe <email protected>
> For additional commands, e-mail: php-dev-help <email protected>
> To contact the list administrators, e-mail: php-list-admin <email protected>
>
> 

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: php-dev-unsubscribe <email protected>
For additional commands, e-mail: php-dev-help <email protected>
To contact the list administrators, e-mail: php-list-admin <email protected>