Description:
------------
I am recently upgraded to php 4.3.3 from 4.2.9 and am using the php4isapi.dll on iis. My application has been working w/o any problems for quite awhile and after the upgrade, without rhyme or reason I am getting the following error every few days:
PHP Warning: Unknown(): A session is active. You cannot change the session module's ini settings at this time. in Unknown on line 0
I have no ini_set statement in my application and have even set my php.ini to read only in the event that it was somehow being modified. My application is EXTREMELY simple... it's basically just consists of a few html forms submitting to a sql db. Authentication happens via IIS and I'm using $AUTH_USER to get the user id.
Since this error is extremely intermittent and only happens 2 or 3 times a week, I cant seem to figure out what line seems or even what function is causing this error. I know that bugs cannot be solved w/o a code example that generates the error but I canAll I know is that the version of PHP is all that's changed so I'm inclined to think it's a bug.
Php.ini is set up as follows:
session.save_handler = files
session.save_path = C:\PHP\sessiondata ; argument passed to save_handler
session.use_cookies = 1
session.name = PHPSESSID
session.auto_start = 0
session.cookie_lifetime = 0
session.cookie_path = /
session.cookie_domain =
session.serialize_handler = php
session.gc_probability = 1
session.gc_maxlifetime = 50400
session.referer_check =
session.entropy_length =
session.entropy_file =
;session.entropy_length = 16
;session.entropy_file = /dev/urandom
session.cache_limiter =
;session.cache_limiter = nocache
session.cache_expire = 180
session.use_trans_sid = 1
Reproduce code:
---------------
As stated above, I'm really not sure WHAT is causing this error. No filename is mentioned in the error. My login.php included in every page is pretty simple:
session_start();
if(!isset($logged_in) || $logged_in != "!authenticated!") {
header("Location: http://myurl.com");
exit;
} else {
$user_id= str_replace("windows_domain\\\\", "", strtolower($AUTH_USER));
}
Actual result:
--------------
Generic 500 error page in IE for the user... On one occasion when this happened I had to restart IIS before PHP would work again....

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports

[2003-12-08 14:29 UTC] jsnajdr at kerio dot com

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

We also experience the same error with PHP 4.3.7 with Apache 1.3.31. We have the following session settings in .htaccess:
<IfModule mod_php4.c>
php_value session.cache_expire 200000
php_value session.gc_maxlifetime 200000
php_value session.cookie_domain ".weblabor.hu"
php_value session.cookie_lifetime 2000000
php_value session.auto_start 0
php_value session.save_handler user
php_value session.cache_limiter none
</IfModule>
Our session handlers store data in a database, and are set with session_set_save_handler() in userland code. The error is the exact one reported by the bug opener.

We have tackled down the problem to memory allocation issues. If PHP is unable to allocate more memory it quits, but then the session module still tries to save stuff, and due to the unavailability of memory, it is unable to do so.
The interesting part is that regardless of our display_errors=off setting, this session error still gets printed out to the browser (the mem allocation problem is only present in our logs). The session module should not print errors if display_errors is off.

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

[2005-02-14 11:02 UTC] zehunter38 at hotmail dot com

i'm using php 4.3.9 with apache 1.3.32 and i got the same error message : A session is active. You cannot change the session module's ini settings at this time...
memory seems ok in my server (still 46Mo free, maybe it's link to some memory allocation parameters?)

[2005-10-03 15:23 UTC] codebowl at gmail dot com

I am also having this problem however i am using php 5.0.5 on windows. I am running Apache 2 and the isapi module.
This seems to happen when i run a script that will do about 20 curl executions.
I also have no ini_set for session stuff, however i do have
ini_set('max_execution_time', 600);
I am not sure why i am getting this since it was brought up in php 4 i figured it would be fixed by 5, maybe it's something new?
I am also using a custom session handler, but up until now have never had a problem with it.

[2005-10-15 17:53 UTC] geoff at fireballgroup dot com

I am running Apache 1.3.31 and PHP 4.3.9. I got the same error and I was using a custom session handler to save my sessions in the database.
The onlt time this error occured was when I was sending two emails that took some time to execute. My specific problem was due to insufficient amount of time for the session handler to do its work. I bumped my time from 30 to set_time_limit(60) and it works fine now.

[2006-01-05 21:49 UTC] dmitriy at forsalebyowner dot com

I am experiencing the same problem. The message in the logs reads:
Unknown(): A session is active. You cannot change the session module's ini settings at this time. in Unknown on line 0
OS: Linux
Distribution: Debian (stable)
Apache: 2.0.54
PHP: 5.0.5

[2006-01-17 17:20 UTC] paresh at quasarsoftech dot com

Apache/2.0.55, (Win32), PHP/5.0.5
Changing the max_execution_time in my php.ini in my distribution on XAMPP worked for me.

I experienced this same error in my code. I had remapped native sessioning to use the database. During a specific update on a page, I was seeing this error. It turned out that the reason was that the update was in a transaction block that was failing, and I was not explicitly issuing a ROLLBACK.
The shared database resource will not accept further statements (like from the session handler), until the transaction has been rolled back. If you are not using transactions, you may want to check for a default setting where all queries are isolated in transactions by default (with postgresql).
In the end, I have learned that when you see this error, chances are good something is hosed with the database connection thereby making it not possible for the session handler to do its job.