I had filed a bug report #21855 sometime back.
What the problem was:
When PHP 4.2.3 was being used along with Apache2 (worker model) accessing
the index.php script
of PHPMyAdmin was causing the thread that was servicing the request to die
with this in
the Apache error_log
[notice] child pid 26712 exit signal Illegal instruction (4)
On HPUX 32bit there is a 64k default size assigned to a thread stack and
128k on HPUX 64bit
The gdb backtrace and disassembly showed that the stack size was growing too
large.
execute() function in zend_execute.c make a call to do_alloca() and that
allocates all the mem on
the stack directly. while great for performance and avoiding memory leaks,
execute() gets recursive
easily and i've measure to to take upto about 28k per invocation. That
easily sends the comsumption
through the roof for moderately complex scripts like phpMyAdmin's index.php.
This limit is easily hit
on HPUX. I am not sure the default stack limits on child threads (i.e not
process's main thread)
on other OS's are. I do believe it _may_ be higher.
Solution 1:
Increase the thread stack size when a thread is created .... in httpd's
(thread.c). Well but the problem
shows up only in PHP. And increasing it there effects all threads created
by Apache. Also bumping up
thread stack size causes increased memory alloaction regardless of how
much of the stack is acutally
used (as i checked with the pthread folks).
Solution 2:
Modify the zend_execute.c
from
EX(Ts) = (temp_variable *)
do_alloca(sizeof(temp_variable)*op_array->T);
to:
EX(Ts) = (temp_variable *)
emalloc(sizeof(temp_variable)*op_array->T);
And free it in 'case ZEND_RETURN:'
from:
free_alloca(EX(Ts));
to:
efree(EX(Ts));
Unfortunately thats not good enough (as fate would have it) for there seems
to be another
bug a causing SIGSEGV and sometimes SIGBUS. The stack traces seem not very
useful since
they are partially corrupted during the crash...and what you get is not what
you expect.
This time the problem is in ext/mysql/libmysql/dbug.c
The crash is ocurring when the _db_return_ () function.
And the crash seem to originate at this piece of code....
#ifndef THREAD
if (state->framep != NULL)
state->framep = (char **) *state->framep; // Crash when dereference
*state->framep
#endif
When compiled with the the worker model, i would assume that THREAD would
get #define-d somehow
and this code would never execute. but thats not the case.
Disabling the entire DBUG_ENTER / DBUG_RETURN mechanism controlled by
another #define seems to
do away with the problem. Can someone please clarify to me how these
debugger support routines
are useful to end users.
Solution 1: (not a solution perhaps)
If debugger support routeines are not useful we could simply disable the
routines
But i would imagine it is infact of some use for some end user in a land far
far away.
Although intuitive, I am not very clear about the exact intention for
THREAD macro gicen the
behaviour i am seeing.
Can anyone tell me if its a good idea to simply force it in #debug.c for
worker model builds ?
-- Roshan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
