Bug #15044 Updated: Signal 11/access violation w/user registered session handler

ID: 15044 Updated by: sniper@php.net Reported By: charles.haley@ac.aup.fr -Status: Duplicate +Status: Bogus Bug Type: Session related Operating System: Redhat 7.1/Windows ME PHP Version: 4.1.1 New Comment: ..just add your comments to the existing report(s). Previous Comments: ------------------------------------------------------------------------ [2002-01-16 03:02:35] yohgaki@php.net I'll make this one a duplicate since there is bug report for this. ------------------------------------------------------------------------ [2002-01-16 02:32:44] charles.haley@ac.aup.fr > Is MySQL return NULL for null fields? Then you > MUST NOT return NULL, but return ''. You have identified the problem. The fields in my database are defined as "NOT NULL". However, the record may not exist (this is certainly true the first time around) causing mysql_fetch to return a non-array value. My code would then subscript this non-array and return an unset value, which is equivalent to returning a NULL field. Yet again I am caught by the "almost-equivalence" of unset values and '' values. I checked out the idea by changing my read function to return '' if the row doesn't exist or the DB field is unset. The problem went away. It is interesting to note that the use of the non-existent index did *not* result in the normal warning (I run with all warnings turned on). In this case mysql_fetch returned a boolean type (false), which was then subscripted. No warning about incompatible types or a non-existent index was given. Probably some sort of warning should be generated when idiots like me do such silly things. > Are you having the same proboem with RH7.1 and > windows? Yes, and the solution derived from your suggestion works on both. As far as I am concerned, this issue is closed. I would suggest, though, that whatever calls session_read be a bit more defensive and protect itself against unset return values. Thank you. ------------------------------------------------------------------------ [2002-01-15 20:01:15] yohgaki@php.net FYI, I don't have problem with user save handler with PostgreSQL at all. Is MySQL return NULL for null fields? Then you MUST NOT return NULL, but return ''. Are you having the same proboem with RH7.1 and windows? Could you send backtrace from RH7.1, it may help. ------------------------------------------------------------------------ [2002-01-15 08:34:22] charles.haley@ac.aup.fr Thanks for the "die" tip. I am not supplying a serializer, but instead am depending on the one supplied by default. My assumption, which seems to be born out in practice, is that "write" is given already-serialized data and that "read" is expected to return this same serialized data. The issue is, of course, that the first "read" doesn't have anything to return since "write" hasn't yet been called. I can't pretend to understand what is happening. What is certain is that the behavior changed from 4.0.6 to 4.1.0. What seems to be true is that ensuring that read gives back *something* in correct serialized format corrects the problem. I suspect a relationship with constructing the new $_SESSION array, but can't prove it. ------------------------------------------------------------------------ [2002-01-15 08:11:16] yohgaki@php.net That's strange. read should treat '' well. That is your serializer? BTW, don't use die(), but return error (false) except for read. ------------------------------------------------------------------------ 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/15044 -- Edit this bug report at http://bugs.php.net/?id=15044&edit=1