One further piece of information:
We can cleanly shutdown Apache 2.0 running the same PHP binaries (except
for the apache2filter module replacing the apache 1.3 module) without
any issues. I just now confirmed that with Apache 2.0, the thread which
is calling bc_new_num() is the *same* as the thread which calls
bc_free_num(). bc_new_num() gets called 3 times by the *same* thread at
PHP load time and gets called 3 times by the *same* thread at PHP unload
time. This means that there must be way someway to "instruct" Apache 1.3
to use the same thread for all related activities.
Any ideas?
Thanks,
S.R.
Ramesh Shankar wrote:
> Thanks for your reply.
>
> I think the issue is more fundamental than that. How and who is to
> guarantee that the thread which called bc_new_num() will be the same as
> the thread which called bc_free_num()? bc_new_num() is called when the
> Apache PHP module gets loaded by some thread in Apache and bc_free_num()
> gets called at shutdown time from some other thread. When _efree() is
> called, the memory being freed is blindly attempted to be removed from
> the list hanging off one of the AG() fields (AG(head), AG(phead)) and
> the node being removed is not in the list in the first place (as it is
> the "wrong" thread).
>
> Any help would be greatly appreciated.
>
> Thanks,
>
> S.R.
>
> Alan Knowles wrote:
>
>> Are you dl('')'ing and modules, - I think Zeev pointed me to a known
>> bug with this if you have a memory leak from a dl'ed module it will
>> crash on this type of debugging code (I think the filename gets freed
>> when you unload the module at shutdown, and hence filename points to
>> an out of bounds area)
>> Regards
>> Alan
>>
>> Ramesh Shankar wrote:
>>
>>> I am trying to port PHP and I am running into a problem with Apache
>>> 1.3. I am not familiar with the PHP language by itself and I am used
>>> to working at the O.S. level and so any help would be greatly
>>> appreciated. I tried to read through mailing list archives, the
>>> readmes, FAQs etc, but I couldn't find answer for this question:
>>>
>>> When PHP is loaded with Apache 1.3 and Apache is shutdown, PHP 4.2.2
>>> crashes inside the routine _efree() called from bc_free_num(). I
>>> found the problem to be related to linked list corruption and on
>>> further investigation, suspected it to be a case of the thread
>>> calling bc_free_num() to be different from that of the thread that
>>> called bc_new_num(). I verfied this by enabling TSRM_DEBUG while
>>> building zend, which enables this detection in _efree(). I also set
>>> the tsrm_error_level to TSRM_ERROR_LEVEL_ERROR to enable dispalying
>>> of TSRM messages to the screen. And sure enough, I got an error
>>> message from _efree() from the following excerpt:
>>>
>>> #if defined(ZTS) && TSRM_DEBUG
>>> if (p->thread_id != tsrm_thread_id()) {
>>> tsrm_error(TSRM_ERROR_LEVEL_ERROR, "Memory block allocated at
>>> %s:(%d) on thread %x freed at %s:(%d) on thread %x, ignoring",
>>> p->filename, p->lineno, p->thread_id,
>>> __zend_filename, __zend_lineno, tsrm_thread_id());
>>> return;
>>> }
>>> #endif
>>>
>>> I have ZTS defined thread support in Zend.
>>>
>>> I am not able to understand and appreciate all the details of the use
>>> of the macros to access the globals variables via AG(), CG() etc and
>>> from what I could figure out, ts_resource_ex()is some kind of thread
>>> specific data mechanism and would work only if threads are dedicated
>>> to PHP.
>>>
>>> I am not able to understand who is responsible for ensuring that the
>>> same thread gets used for a complete request - whether it is some
>>> thing that I need to do in Apache or whether I need to enable/disable
>>> something while compiling PHP.
>>>
>>> Any help would be greatly appreciated. Please copy me on your reply
>>> as well.
>>>
>>> Thanks in advance,
>>>
>>> S.R.
>>>
>>>
>>
>>
>>
>
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
