ID: 27555 Comment by: slawo at csuk-solutions dot net Reported By: jaanus at heeringson dot com Status: No Feedback Bug Type: Documentation problem Operating System: Linux 2.4.24 PHP Version: 5CVS-2004-03-10 (dev) Assigned To: helly New Comment:
I strugled for hours today looking for the souce of the problems within our current application, finally I noticed that some objects did not apear in the sessions variable as they should. Finaly the conclusion is we relied on an inconsistent behavior in PHP. Linux Mandrake 10 php 5.1 Will this bug be seen to soon? This is not a bug, this is a feature... Previous Comments: ------------------------------------------------------------------------ [2006-01-19 00:51:20] graeme at druknet dot bt This is certainly entering the realms of a bug now with 5.1.2. If I unset an object which has destruct that tries to update the session variable then the output is truncated. Proper headers are not set. If I don't unset then I get the following unhelpful error message: Warning: Unknown: Your script possibly relies on a session side-effect which existed until PHP 4.2.3. Please be advised that the session extension does not consider global variables as a source of data, unless register_globals is enabled. You can disable this functionality and this warning by setting session.bug_compat_42 or session.bug_compat_warn to off, respectively. in Unknown on line 0 ------------------------------------------------------------------------ [2005-11-29 11:36:55] php at mike2k dot com This is still a bug. I just upgraded to PHP 5.1.1, using a custom session handler with mysqli, and this is a problem. It appears this is a workaround, albeit I don't think this should be required to function as it did before. I use procedural code, and not object oriented code, so having __destruct handlers do not help me. register_shutdown_function('session_write_close'); Here's my [very simple] session handler. Note db_query() is a simple wrapper for mysqli_query() and handles all the connection details internally. function session_close() { return true; } function session_die($id) { db_query("DELETE FROM session WHERE ID='$id'"); return true; } function session_gc($maxlifetime) { return true; } function session_open($path,$name) { return true; } function session_read($id) { $dchk = db_query("SELECT data FROM session WHERE ID='$id'"); if(db_numrows($dchk) == 1) { if(!isset($_SESSION['row'])) { $_SESSION['row'] = 1; } list($data) = db_rows($dchk); return base64_decode($data); } else { return ""; } db_free($dchk); return true; } function session_write($id,$data) { global $visitor; $data = base64_encode($data); if(!isset($_SESSION['row'])) { db_query("INSERT IGNORE INTO session (ID,data,accessed) VALUES('$id','$data',UNIX_TIMESTAMP(NOW()))"); } else { db_query("UPDATE session SET data='$data',accessed=UNIX_TIMESTAMP(NOW()) WHERE ID='$id'"); } return true; } (fyi: I have a cronjob that does garbage collection based on the "accessed" column) I still think this is a bug, I don't see why this was changed. ------------------------------------------------------------------------ [2005-11-20 16:43:47] lists at cyberlot dot net How about register_shutdown_function This is affected also, This isn't something you can just "Document" away. Basically your saying any user made or php made object is useless during the shutdown phase of php. php5 is supposed to bring object programming close to php and this steps all over it. Every single object related function, class, extension has now been made useless/impossible to call during shutdown be in within a session or in a use defined shutdown function. ------------------------------------------------------------------------ [2005-11-09 17:35:17] phpbugs at dubr dot com Why is this being considered a documentation bug? It clearly is a PHP bug and needs to be fixed. ------------------------------------------------------------------------ [2005-10-05 10:24:39] richard dot quadling at bandvulc dot co dot uk One of the real issues here is that the destruction of objects created by the user is not in a logically sequence. Having to manually free objects is sort of correct as relying on automated clearing/garbage collection can only, at best, guess the order in which things should be destroyed. So, assuming somehow there was a way to determine the order of destruction, what happens when you have object interdependance. Say, linking SESSION and DB. DB needs session details to know what the user is, but SESSION needs DB to update status of user. If you DON'T use __desrtuct() at all and use normal methods you HAVE to decide which goes first (which is a better choice than letting the system guess), but requires more work. I don't think there is an easy solution. Richard. ------------------------------------------------------------------------ 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/27555 -- Edit this bug report at http://bugs.php.net/?id=27555&edit=1