#45880 [NoF-Csd]: libxml_use_internal_errors disables/resets previous call to set_error_handler
ID: 45880 User updated by: james at dunmore dot me dot uk Reported By: james at dunmore dot me dot uk -Status: No Feedback +Status: Closed Bug Type: *XML functions Operating System: Linux PHP Version: 5.2.6 New Comment: Hi, Sorry for the delay, took me a while to find the time to get 5.3 installed. I tried on 5.3 - problem gone away I've also done some further testing on 5.2.6, and it appears to only happen when we call that code as part of a SOAP service, from a SOAP client - problem fixed by re-calling set_error_handler to my custom one - but problem doesn't happen on same server, same code, but when called from another file (and not from a test SOAP client). Therefore, I tend to think that this is related to our install - but I'm getting someone else to look at it, and I will post my findings. Thank-you for your time. Regards, James. Previous Comments: [2008-08-29 01:00:01] php-bugs at lists dot php dot net 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. [2008-08-21 11:00:38] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.3-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.3-win32-installer-latest.msi Could you please try with 5.3, we made many changes to the error handling there which won't be backported to 5.2 as they require too many internal changes for a bug fix release. The issue should be fixed there. [2008-08-21 10:01:13] james at dunmore dot me dot uk Description: We use a custom error handler using set_error_handler() I found that after I call libxml_use_internal_errors(false); It resets my error_handler - not sure if this is intended? Reproduce code: --- //my set_error_handler suppresses E_NOTICE and E_WARNING //put an E_WARNING here, and it WILL be suppressed libxml_use_internal_errors(false); //put an E_WARNING here, and it won't be suppressed Expected result: Errors Suppressed Actual result: -- Errors not Suppresses -- Edit this bug report at http://bugs.php.net/?id=45880edit=1
#45880 [NEW]: libxml_use_internal_errors disables/resets previous call to set_error_handler
From: james at dunmore dot me dot uk Operating system: Linux PHP version: 5.2.6 PHP Bug Type: *XML functions Bug description: libxml_use_internal_errors disables/resets previous call to set_error_handler Description: We use a custom error handler using set_error_handler() I found that after I call libxml_use_internal_errors(false); It resets my error_handler - not sure if this is intended? Reproduce code: --- //my set_error_handler suppresses E_NOTICE and E_WARNING //put an E_WARNING here, and it WILL be suppressed libxml_use_internal_errors(false); //put an E_WARNING here, and it won't be suppressed Expected result: Errors Suppressed Actual result: -- Errors not Suppresses -- Edit bug report at http://bugs.php.net/?id=45880edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45880r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45880r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45880r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45880r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45880r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45880r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45880r=needscript Try newer version:http://bugs.php.net/fix.php?id=45880r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45880r=support Expected behavior:http://bugs.php.net/fix.php?id=45880r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45880r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45880r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45880r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45880r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45880r=dst IIS Stability:http://bugs.php.net/fix.php?id=45880r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45880r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45880r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45880r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45880r=mysqlcfg
#25876 [Com]: session_start(): Failed to initialize storage module
ID: 25876
Comment by: james at dunmore dot me dot uk
Reported By: golden at riscom dot com
Status: No Feedback
Bug Type: Session related
Operating System: freebsd 4.8
PHP Version: 4.3.9-4.3.10
New Comment:
I use DB for sessions, and had the problem with session_destory
(followed by session_start) as well.
I had this code in a prepend-db file:
$GLOBALS[mysql_session_handler] = new mysql_session_handler;
session_set_save_handler(
array($GLOBALS[mysql_session_handler],'mysql_session_open'),
array($GLOBALS[mysql_session_handler],'mysql_session_close'),
array($GLOBALS[mysql_session_handler],'mysql_session_read'),
array($GLOBALS[mysql_session_handler],'mysql_session_write'),
array($GLOBALS[mysql_session_handler],'mysql_session_destroy'),
array($GLOBALS[mysql_session_handler],'mysql_session_gc')
);
=
So instead, I put that inside the class as a static function (the in
the prepend, called that static function,
mysql_session_handler::setHandler();) , then called it again after
session destroy. i.e.
session_destroy();
mysql_session_handler::setHandler();
Problem sovled - well, it's not, session_destroy should not destroy
the save handler
Previous Comments:
[2008-04-02 06:37:29] webmaster at mindrabbit dot com
This bug is easy to repeat in following way:
1) Set session_save_handler to user based like DB
2) Start page like normal, start session etc
3) CHANGE your session_id BEFORE you print anything to your screen
3.1) Destroy the old session_id
3.2) set new session id with session_id('your_id')
3.3) Try start_session() which will produce error message
Problem is that system can not init custom session_save_handler in some
odd reason. When changing session_handler to local files, anything goes
normal. But with custom save handler like memcache or DB backend, code
will fail.
When you refresh page, problem disappears.
I have tested this with Apache 2.2.8, PHP 5.2.5 and MySQL 5.1.23RC and
with newest memcache.
--JT--
[2008-02-16 11:11:07] notrevevirtual at gmail dot com
System: FreeBSD 6.2-RELEASE
PHP Version 5.2.5
Apache Version Apache/2.0.63 (Unix)
This problem started after an server update (php+mysql+apache).
None of the solutions found here can fix it.
[2007-09-13 01:00:01] php-bugs at lists dot php dot net
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.
[2007-09-05 13:51:04] [EMAIL PROTECTED]
Can your reproduce this with PHP 5.2.4 or greater? (in case we happen
to release 5.2.5 in the meantime :)
[2007-08-30 07:54:07] golden at riscom dot com
We are currently having problem with the same think at one of our
servers.
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/25876
--
Edit this bug report at http://bugs.php.net/?id=25876edit=1
