On 21 Dec 2001 [EMAIL PROTECTED] wrote: > 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....
Didn't you send me a patch for this? Derick > > > Previous Comments: > ------------------------------------------------------------------------ > > [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? > > > ------------------------------------------------------------------------ > > [2001-12-14 10:11:51] [EMAIL PROTECTED] > > Another update. If I have the following in the script: > > session_register("onevar"); > > And then don't set the variable to anything, I get the crash on >zend_hash_get_current_key_ex > > If I have the following in my script: > > session_register("onevar"); > $_SESSION["onevar"] = ""; //Anything in the quotes. > > Or just: > > $_SESSION["onevar"] = ""; > > I get the crash at _zend_is_inconsistent > > > Next, if I have the following: > > session_register("onevar"); > session_unregister("onevar"); > > I get an entirely different crash. Here's the bt. > > Program received signal SIGSEGV, Segmentation fault. > 0x81497bc in zend_hash_del_key_or_index (ht=0x829e7e4, arKey=0x829d6a4 "onevar", >nKeyLength=7, h=4009320036, flag=0) > at zend_hash.c:484 > 484 p = ht->arBuckets[nIndex]; > (gdb) bt > #0 0x81497bc in zend_hash_del_key_or_index (ht=0x829e7e4, arKey=0x829d6a4 "onevar", >nKeyLength=7, h=4009320036, flag=0) > at zend_hash.c:484 > #1 0x80bfb74 in zif_session_unregister (ht=1, return_value=0x82ae5a4, this_ptr=0x0, >return_value_used=0) at session.c:1279 > #2 0x816af2e in execute (op_array=0x82944a4) at ./zend_execute.c:1598 > #3 0x81448e9 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at >zend.c:810 > #4 0x808caad in php_execute_script (primary_file=0xbfbff894) at main.c:1310 > #5 0x8150426 in apache_php_module_main (r=0x8284034, display_source_mode=0) at >sapi_apache.c:90 > #6 0x808919e in send_php (r=0x8284034, display_source_mode=0, filename=0x8284b14 >"/home/www/intranet/htdocs/test.php") > at mod_php4.c:575 > #7 0x80891f2 in send_parsed_php (r=0x8284034) at mod_php4.c:590 > #8 0x8175311 in ap_invoke_handler (r=0x8284034) at http_config.c:517 > #9 0x81899b4 in process_request_internal (r=0x8284034) at http_request.c:1307 > #10 0x8189a1e in ap_process_request (r=0x8284034) at http_request.c:1323 > #11 0x8180a1f in child_main (child_num_arg=0) at http_main.c:4209 > #12 0x8180bdd in make_child (s=0x8226034, slot=0, now=1008341402) at http_main.c:4313 > #13 0x8180d56 in startup_children (number_to_start=5) at http_main.c:4395 > #14 0x8181360 in standalone_main (argc=2, argv=0xbfbffbbc) at http_main.c:4683 > #15 0x8181b78 in main (argc=2, argv=0xbfbffbbc) at http_main.c:5010 > > Next, if I have the following: > > $_SESSION["onevar"] = "Test"; > session_unset(); > > I get the following (yet another bt): > > Program received signal SIGSEGV, Segmentation fault. > 0x81482f9 in _zend_is_inconsistent (ht=0x84003038, file=0x81e01e4 "zend_hash.c", >line=558) at zend_hash.c:84 > 84 if (ht->inconsistent==HT_OK) { > (gdb) bt > #0 0x81482f9 in _zend_is_inconsistent (ht=0x84003038, file=0x81e01e4 "zend_hash.c", >line=558) at zend_hash.c:84 > #1 0x8149b31 in zend_hash_clean (ht=0x84003038) at zend_hash.c:558 > #2 0x80bff90 in zif_session_unset (ht=0, return_value=0x82ae5e4, this_ptr=0x0, >return_value_used=0) at session.c:1384 > #3 0x816af2e in execute (op_array=0x82944a4) at ./zend_execute.c:1598 > #4 0x81448e9 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at >zend.c:810 > #5 0x808caad in php_execute_script (primary_file=0xbfbff894) at main.c:1310 > #6 0x8150426 in apache_php_module_main (r=0x8284034, display_source_mode=0) at >sapi_apache.c:90 > #7 0x808919e in send_php (r=0x8284034, display_source_mode=0, filename=0x8284b14 >"/home/www/intranet/htdocs/test.php") > at mod_php4.c:575 > #8 0x80891f2 in send_parsed_php (r=0x8284034) at mod_php4.c:590 > #9 0x8175311 in ap_invoke_handler (r=0x8284034) at http_config.c:517 > #10 0x81899b4 in process_request_internal (r=0x8284034) at http_request.c:1307 > #11 0x8189a1e in ap_process_request (r=0x8284034) at http_request.c:1323 > #12 0x8180a1f in child_main (child_num_arg=0) at http_main.c:4209 > #13 0x8180bdd in make_child (s=0x8226034, slot=0, now=1008342128) at http_main.c:4313 > #14 0x8180d56 in startup_children (number_to_start=5) at http_main.c:4395 > #15 0x8181360 in standalone_main (argc=2, argv=0xbfbffbbc) at http_main.c:4683 > #16 0x8181b78 in main (argc=2, argv=0xbfbffbbc) at http_main.c:5010 > > Finally, if I do the following: > > session_register("onevar"); > // No initialization on $onevar or $_SESSION["onevar"] > session_unset(); > > I get this: (Last bt) > > Program received signal SIGSEGV, Segmentation fault. > 0x8149b5d in zend_hash_clean (ht=0x829e764) at zend_hash.c:565 > 565 p = p->pListNext; > (gdb) bt > #0 0x8149b5d in zend_hash_clean (ht=0x829e764) at zend_hash.c:565 > #1 0x80bff90 in zif_session_unset (ht=0, return_value=0x829d564, this_ptr=0x0, >return_value_used=0) at session.c:1384 > #2 0x816af2e in execute (op_array=0x82944a4) at ./zend_execute.c:1598 > #3 0x81448e9 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at >zend.c:810 > #4 0x808caad in php_execute_script (primary_file=0xbfbff894) at main.c:1310 > #5 0x8150426 in apache_php_module_main (r=0x8284034, display_source_mode=0) at >sapi_apache.c:90 > #6 0x808919e in send_php (r=0x8284034, display_source_mode=0, filename=0x8284b14 >"/home/www/intranet/htdocs/test.php") > at mod_php4.c:575 > #7 0x80891f2 in send_parsed_php (r=0x8284034) at mod_php4.c:590 > #8 0x8175311 in ap_invoke_handler (r=0x8284034) at http_config.c:517 > #9 0x81899b4 in process_request_internal (r=0x8284034) at http_request.c:1307 > #10 0x8189a1e in ap_process_request (r=0x8284034) at http_request.c:1323 > #11 0x8180a1f in child_main (child_num_arg=0) at http_main.c:4209 > #12 0x8180bdd in make_child (s=0x8226034, slot=0, now=1008342253) at http_main.c:4313 > #13 0x8180d56 in startup_children (number_to_start=5) at http_main.c:4395 > #14 0x8181360 in standalone_main (argc=2, argv=0xbfbffbbc) at http_main.c:4683 > #15 0x8181b78 in main (argc=2, argv=0xbfbffbbc) at http_main.c:5010 > > > I apologize for the large amount of bt's, but I figured they'd all be helpful with >tracking down the problem. > > (BTW, all my recent testing has been under the snap version I downloaded yesterday) > > > ------------------------------------------------------------------------ > > 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] > -- 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]
