On 21 Dec 2001 yohgaki@php.net 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] yohgaki@php.net
>
> Is this fixed?
> Anyone mind if I fix this and commit?
> --
> Yasuo Ohgaki
>
>
> ------------------------------------------------------------------------
>
> [2001-12-14 16:00:04] jbozza@thinkburst.com
>
> 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] yohgaki@php.net
>
> 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] jbozza@thinkburst.com
>
> 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] jbozza@thinkburst.com
>
> 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: php-dev-unsubscribe@lists.php.net
> For additional commands, e-mail: php-dev-help@lists.php.net
> To contact the list administrators, e-mail: php-list-admin@lists.php.net
>