ID: 14497 Updated by: yohgaki Reported By: [EMAIL PROTECTED] Old Status: Analyzed Status: Assigned Bug Type: Session related Operating System: FreeBSD 4.4-Stable PHP Version: 4.1.0, 4-200112131200 Assigned To: yohgaki New Comment:
I've not committed the fix for this bug yet, but you can work around the segfault. Return string when there is no data to read or failed to write. (i.e. return '';) User session save handler expect string data, if you return other than string, it segfualts. Previous Comments: ------------------------------------------------------------------------ [2001-12-21 03:36:49] [EMAIL PROTECTED] Assigned to myself. By the I updated this bug report, I know the fix, but I forgot what is was now :( I'll work on this after I finish things have to do.... ------------------------------------------------------------------------ [2001-12-19 23:00:15] [EMAIL PROTECTED] Is this fixed? Anyone mind if I fix this and commit? -- Yasuo Ohgaki ------------------------------------------------------------------------ [2001-12-14 16:00:04] [EMAIL PROTECTED] I had already tried out your user handlers (as you can see from the bug report). Your handlers weren't causing the crash but were helping in making the crash happen. (I would guess that the initialization of the internal data structures from your handlers allowed the invalid "return false;" pointer to be fubar'd in such a way to cause a segfault.) Read the bug report, it's all there, including on how I was reproducing the crash. Your session handlers have a few problems when there is concurrent access for the same session id. (It *DOES* happen, especially with AvantGo clients, trust me on this one) You also do not check for expiration in your session_read. Since garbage collection doesn't happen on every single access, there's a possibility that stale data would get loaded. Also, since your session handlers aren't mentioned anywhere on the PHP website under the session documentation, as well as not stressing the fact that returning false will cause data corruption, it still doesn't really address the issue. Personally I don't think the doing something in a script language should cause a low-level crash. I believe there was another recent bug dealing with the xslt extension that explained this issue well: "But PHP generating nice corefiles is not ok." At most I think PHP should return an error when the data isn't what was expected, not segfault, or core, or crash. ------------------------------------------------------------------------ [2001-12-14 15:29:01] [EMAIL PROTECTED] Could you take a look at my user session handlers using PostgreSQL. You'll see what kind of values should be returned. Please report the result. http://www.zend.com/codex.php?id=456&single=1 ------------------------------------------------------------------------ [2001-12-14 12:57:35] [EMAIL PROTECTED] After reading other similar problems, looking at PHP/Zend source code and tracking down all the different crashes, I believe I found the problem. I went back to the internal session code and for the past 2 hours or so things are working ok. (No faults) My session_read function had a "return false;" when there was no data available. Obviously, the lower-level functions treat this "false" as data and try and manipulate it as such. (Perhaps even trying to unserialize it?) Regardless, switching to "return '';" eliminated the crashes for me. Whether or not this is some other bug popping up (freeing the memory for a false incorrectly) or just a documentation issue I really don't know. At the very least, since many of the tutorials on user-defined session handlers have "return false;" (I just checked PHPBuilder and the code there has it), if there's a way to fix it in the code then great! If not, maybe put it in a FAQ somewhere or put it up in the documentation under the set_handler function. Comments? ------------------------------------------------------------------------ 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/?id=14497 Edit this bug report at http://bugs.php.net/?id=14497&edit=1 -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
