php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #31624 session_start() causes segmentation fault on complex objects
Submitted: 2005-01-20 17:00 UTC Modified: 2005-03-30 11:00 UTC
Votes:5
Avg. Score:4.4 ± 0.8
Reproduced:4 of 4 (100.0%)
Same Version:3 (75.0%)
Same OS:1 (25.0%)
From: ericvanblokland at gmail dot com Assigned:
Status: Closed Package: Session related
PHP Version: 4CVS-2005-01-22 OS: Fedora Core 2
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
50 + 34 = ?
Subscribe to this entry?

 
 [2005-01-20 17:00 UTC] ericvanblokland at gmail dot com
Description:
------------
PHP seems to crash on complex objects at exit or on session_start();

I suspect the php internal session_encode, session_decode, serialize and unserialize functions.

Ive not been able to reproduce this as it only seems to occur with *VERY* complex objects like my code generates.

Some strange facts I've found out about while trying to pinpoint the exact cause:
- In some occasions, escaping a foreach on $this->property in an objects __wakeup(); made the problem disappear.
- When manually decoding a session file, (about 3M) I also got a segmentation fault. After increasing the available memory to over 64M the session got correctly decoded. With this *SICK* amount of memory, the actual script kept segfaulting, however, it took longer to segfault so expect a memory leak or infinite loop.
- This problem occurs on a Fedora Core 2, Apache 2.0, PHP 4.3.10 machine, while on RedHat 7.3, Apache 1.3.29, PHP 4.3.6 everything works fine. So suspect the bugfix (4.3.9->4.3.10) on session handling for spooky behaviour.

I will try to keep you all up to date.
Thank you,
Eric van Blokland

Reproduce code:
---------------
Contact me for access to code. The code is very large and complex, I haven't been able to pinpoint to exact cause of this problem

Actual result:
--------------
Suspect internal session_encode to puke, all output correct though

#0  0x005086ae in malloc_consolidate () from /lib/tls/libc.so.6
#1  0x0050854d in _int_free () from /lib/tls/libc.so.6
#2  0x0050972b in free () from /lib/tls/libc.so.6
#3  0x01eea6af in shutdown_memory_manager (silent=0, clean_cache=0) at /usr/src/redhat/BUILD/php-4.3.10/Zend/zend_alloc.c:492
#4  0x01eca73a in php_request_shutdown (dummy=0x0) at /usr/src/redhat/BUILD/php-4.3.10/main/main.c:1003
#5  0x01f0ec10 in php_apache_request_dtor (r=0x945d6c0)
    at /usr/src/redhat/BUILD/php-4.3.10/sapi/apache2handler/sapi_apache2.c:453
#6  0x01f0eeda in php_handler (r=0x945d6c0) at /usr/src/redhat/BUILD/php-4.3.10/sapi/apache2handler/sapi_apache2.c:577
#7  0x0094ec88 in ap_run_handler () from /usr/sbin/httpd
#8  0x0925f9f8 in ?? ()
#9  0x00000000 in ?? ()

Might by 31106 Related
http://bugs.php.net/bug.php?id=31106



Error occurs with session_start(); suspect session_decode to puke. No output generated

#0  _zval_ptr_dtor (zval_ptr=0x6) at /usr/src/redhat/BUILD/php-4.3.10/Zend/zend_execute_API.c:287
#1  0x0177d898 in zend_hash_clean (ht=0x8832aac) at /usr/src/redhat/BUILD/php-4.3.10/Zend/zend_hash.c:582
#2  0x01788dcb in execute (op_array=0x862b22c) at /usr/src/redhat/BUILD/php-4.3.10/Zend/zend_execute.c:1702
#3  0x01788d15 in execute (op_array=0x8703514) at /usr/src/redhat/BUILD/php-4.3.10/Zend/zend_execute.c:1686
#4  0x0178a3fa in execute (op_array=0x8881b4c) at /usr/src/redhat/BUILD/php-4.3.10/Zend/zend_execute.c:2212
#5  0x01778d51 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/redhat/BUILD/php-4.3.10/Zend/zend.c:900
#6  0x0174b0af in php_execute_script (primary_file=0xfee57db0) at /usr/src/redhat/BUILD/php-4.3.10/main/main.c:1736
#7  0x0178e07f in php_handler (r=0x869e170) at /usr/src/redhat/BUILD/php-4.3.10/sapi/apache2handler/sapi_apache2.c:557
#8  0x00e18c88 in ap_run_handler () from /usr/sbin/httpd
#9  0x0832d9f8 in ?? ()
#10 0x00000000 in ?? ()


Might be 31313 Related, crash can be avoided by disabling foreach on $this->property 

http://bugs.php.net/bug.php?id=31313

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-03-19 17:08 UTC] tony2001@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

We're still waiting for reproduce script..
 [2005-03-25 01:55 UTC] sniper@php.net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.


 [2005-03-30 11:00 UTC] ericvanblokland at gmail dot com
I've never been able to create a simple reproduce code, as i've never been able to determine the exact cause of the crash. Then again, it occured working with *very* complex objects, so how simple could that reproduce code be?

Anyway as time went by, I was forced, due to the consistency of these segfaults, to switch to php5 which is serving me quite well at this time.

I'm changing status the closed now, however, if I find time in the futurem I will test the old source of my project on the latest available php4

One funky detail I remember about this bug, is that php could crash on simple variable assignment in __wakeup() during session_start()

example: $obj1->__wakeup() calls $this->obj2->init(); which does simple variable assignment $this->value = $value;

Note, that one or more references to these objects are resident inside the session. I know sniper say you can't/shouldn't use (circular) references inside a session, however as I said, everything works fine in php5.
I also tried to remove these references from the session (while required by the project, i wanted to know if the caused the segfaults), without succes though as result from another php4 bug: objects can't be copied after method calls through the object. (which is the other bug that forced me to switch to php5) 

Last but not least: check the bugreport system, a lot of my comments to this bug are missing.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Mar 19 07:01:29 2024 UTC