#14529 [Fbk->NoF]: Returning non-string type from session read() segfaults. (User save handler)

ID: 14529 Updated by: php-bugs@lists.php.net Reported By: jay1@swift-web.com -Status: Feedback +Status: No Feedback Bug Type: Session related Operating System: Linux RH 7.2 PHP Version: 4.3.0-dev New Comment: No feedback was provided for this bug for over a month, 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". Previous Comments: ------------------------------------------------------------------------ [2002-08-16 22:03:33] rasmus@php.net Ok, so after all that, the summary of this bug is that returning a non-string from the read() function from a custom session handler causes a problem. I tried to reproduce this in current CVS by returning either false, null and random integers/floats and could not get a segfault. Please test a current snapshot and provide a short script that reproduces this. ------------------------------------------------------------------------ [2002-03-26 21:41:50] yohgaki@php.net After all, it's a session bug. I'm sure this is reported, but I couldn't find one. ------------------------------------------------------------------------ [2002-03-26 19:39:54] jay1@swift-web.com I did the same thing a while back and things appeared to work again. My screens were not getting cut off on every page load. But apache still crashed on almost every page viewed. Somehow, IE was able to display the page (I'm thinking though cache but it caught some of the newer info - but not always) but Netscape, Opera and some linux browsers simply displayed an error that they could not connect and eventually even in IE the pages started getting cut off again. It's as if apache crashed anyways for me only crashed sooner if the session read function returned false instead of an empty string. I've cut my program very small and eliminated all include/require statements thinking I'd add them until the problem occured, only as a base program (still fairly complex) the problem still occurs. Yet I've written some very simple pages and they don't crash. It's almost like it's a combination of tasks that cause it. ------------------------------------------------------------------------ [2002-03-26 18:22:30] fabian@ahrberg.se YEAH! IT WORKS! I've solved my problem! It was related to my session_handling and the session_read function. When I forced the function to ALWAYS return a string, even if it was an empty one apache stopped crashing! return (string)$value; Previously I sometimes returned other values such as the boolean false. This didn't make apache crash with 4.0.6 but it does with the later versions. *happy happy happy* The page works like a charm again! No cut off pages! No messed up posted forms! No more weird sessions that doesn't register! I LOVE IT! ------------------------------------------------------------------------ [2002-03-20 06:18:03] albert@xs4all.nl http://www.php.net/manual/en/function.session-set-save-handler.php On this page are a lot of comments, one of them was striking: <quote> 04-Mar-2002 02:57 I just want to mention, that it's critical to return a string value with the read function, because there can be strange errors if - for example - the return value is null. In my case the php program stopped in the middle of an "echo" command, so it was really hard to find, that the real problem was with that session read callback function. The easyest way to handle this, that you should cast the return value before return. For example: function read ($id) { /* code here to produce $retval */ return (string)$retval; } </quote> Weird, isn't it, but maybe it helps getting more close to solving the problem. ps: we've got php4.1.2 now installed as a CGI, session.save_handler=files, still using the session_set_save_handler function (although it doesn't say so in the tutorial -explicitly- it does override the 'files'-setting, see one of the other comments) and I don't have any problems anymore. At least, not until now, fingers crossed. ------------------------------------------------------------------------ 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/14529 -- Edit this bug report at http://bugs.php.net/?id=14529&edit=1