ID: 14497
Updated by: yohgaki
Reported By: [EMAIL PROTECTED]
Status: Analyzed
Bug Type: Session related
Operating System: FreeBSD 4.4-Stable
PHP Version: 4.1.0, 4-200112131200
Old Assigned To: 
Assigned To: yohgaki
New Comment:

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....


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]

Reply via email to