ID:               26005
 Comment by:       jsnajdr at kerio dot com
 Reported By:      parsnip11 at hotmail dot com
 Status:           No Feedback
 Bug Type:         Session related
 Operating System: windows 2000 iis 5
 PHP Version:      4CVS-2003-10-31
 New Comment:

I am experiencing this bug too and I think I found its cause. It can
occur when PHP is used in a multithreaded program - I embed PHP
interpreter in my own multithreaded server using a custom SAPI module,
original submitter of this bug uses ISAPI module, which is also
multithreaded.

The 'Session is active' warning is generated by the
PHP_INI_MH(OnUpdateSaveHandler) function that checks
PS(session_status), i.e. the session module globals structure. This
handler is also called when calling TSRMLS_FETCH() (which is a define
for ts_resource_ex() call) before executing a PHP script. See this call
stack from gdb:

#0  OnUpdateSaveHandler (entry=0xb303890, new_value=0x8700f48 "files",
new_value_length=5, mh_arg1=0x0, mh_arg2=0x0, mh_arg3=0x0, stage=1,
tsrm_ls=0xb2dce18)
    at /root/src/php-4.3.4/ext/session/session.c:93
#1  0x0865414c in zend_ini_refresh_cache (p=0xb303890, stage=1,
tsrm_ls=0xb2dce18) at /root/src/php-4.3.4/Zend/zend_ini.c:177
#2  0x0865006f in zend_hash_apply_with_argument (ht=0xb300ac8,
apply_func=0x8654124 <zend_ini_refresh_cache>, argument=0x1,
tsrm_ls=0xb2dce18)
    at /root/src/php-4.3.4/Zend/zend_hash.c:717
#3  0x0865417d in zend_ini_refresh_caches (stage=1, tsrm_ls=0xb2dce18)
at /root/src/php-4.3.4/Zend/zend_ini.c:185
#4  0x08653f88 in zend_copy_ini_directives (tsrm_ls=0xb2dce18) at
/root/src/php-4.3.4/Zend/zend_ini.c:104
#5  0x0864b574 in zend_new_thread_end_handler (thread_id=4423709,
tsrm_ls=0xb2dce18) at /root/src/php-4.3.4/Zend/zend.c:374
#6  0x0862724f in allocate_new_resource
(thread_resources_ptr=0xabac72c, thread_id=4423709) at
/root/src/php-4.3.4/TSRM/TSRM.c:282
#7  0x08627305 in ts_resource_ex (id=0, th_id=0x0) at
/root/src/php-4.3.4/TSRM/TSRM.c:341 

But this handler reads unitialized memory in the new thread's
ps_globals - the TSRM resource has NULL constructor and TSRMLS_FETCH is
called before php_request_startup(), where all the modules are
activated and where the PHP_RINIT_FUNCTION(session) is called to
construct the structure.

Solution: the ps_globals resource must have a non-null constructor
registered in ts_allocate_resource() call in ext/session/session.c


Previous Comments:
------------------------------------------------------------------------

[2003-11-25 15:33:21] [EMAIL PROTECTED]

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.



------------------------------------------------------------------------

[2003-11-21 21:19:07] [EMAIL PROTECTED]

No, it's absolutely useless to us.
If possible, try disabling ALL extensions in your php.ini.


------------------------------------------------------------------------

[2003-11-20 15:50:34] parsnip11 at hotmail dot com

I just got the error again. I wish I could post the code that makes
this happen but I really dont know what it is. I've been running fine
for two weeks and it just happened again. 

I get the following message:

"PHP has encountered an Access Violation at 01210969"

I realize it's hard for you troubleshoot this issue if I cant give you
exact code but short of submitting my entire application I can't
isolate what's happening. All I know is it started happening after a
php upgrade. The code has not changed.

Does the above access violation provide any clues as to what the
problem could be?

------------------------------------------------------------------------

[2003-11-06 15:18:22] [EMAIL PROTECTED]

You have to provide a short but complete example before we can do
anything about this.


------------------------------------------------------------------------

[2003-10-31 09:52:16] parsnip11 at hotmail dot com

I have updated to the latest version of php and have also added and
session_write_close() before all of my "exit" statements as some people
have mentioned this helped.

No go... Just checked the logs this morning and this error has popped
up again

------------------------------------------------------------------------

The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
    http://bugs.php.net/26005

-- 
Edit this bug report at http://bugs.php.net/?id=26005&edit=1

Reply via email to