From:             daniel dot beardsley at gmail dot com
Operating system: CentOS
PHP version:      5.4.5
Package:          Reproducible crash
Bug Type:         Bug
Bug description:Seg fault or broken object references on unserialize()

Description:
------------
Occurs on php 5.4.0, but not on 5.3 (I'll try on other versions soon).
Please run this test from /tmp/serialize/run_tests.sh (see bottom for 
explanation)

## Description ##

If calling unserialize() somehow calls back into user code (i.e.
autoloading a
class while unserializing it) and user code does another unserialize() (no

matter what it is), object references in the outer unserialization process
won't 
be restored correctly. Sometimes the outer call can result in a
Segmentation 
Fault instead of just broken references.

In particular, object refrerences will often be replaced with a seemingly
random
value from your serialized object graph (or NULL).

The call stack at the time of the problem looks like this:

  #0 /tmp/serialize/setup.php(6): unserialize('i:4');
  #1 [internal function]: __autoload('A')
  #2 /tmp/serialize/unserialize_autoload.php(4): unserialize('O:1:"A":4:
{s:1:...')
  #3 {main}

The unserialize call in frame #2 returns incorrect results because of the 
"recursive" unserialize call in frame #0.

Note:
For reasons that completely escape me, this code seems dependent on the
literal 
path it's run from.  Some paths hide the bug, some cause failure, and some
cause 
a SegFault.  It's consistent on a per-path basis, but I found no pattern.  

Test script:
---------------
https://gist.github.com/3353895

Expected result:
----------------
Before and After output should be the same. Last line of output should
read: 
"Passed, no differences"

Before Serialization:
class A#1 (4) {
  public $b =>
  class B#2 (0) {
  }
  public $b1 =>
  class B#2 (0) {
  }
  public $c =>
  class B#3 (0) {
  }
  public $c1 =>
  class B#3 (0) {
  }
}

Actual result:
--------------
After Serialization:
class A#1 (4) {
  public $b =>
  class B#2 (0) {
  }
  public $b1 =>
  string(2) "1\000"
  public $c =>
  class B#3 (0) {
  }
  public $c1 =>
  NULL
}


-- 
Edit bug report at https://bugs.php.net/bug.php?id=62836&edit=1
-- 
Try a snapshot (PHP 5.4):            
https://bugs.php.net/fix.php?id=62836&r=trysnapshot54
Try a snapshot (PHP 5.3):            
https://bugs.php.net/fix.php?id=62836&r=trysnapshot53
Try a snapshot (trunk):              
https://bugs.php.net/fix.php?id=62836&r=trysnapshottrunk
Fixed in SVN:                        
https://bugs.php.net/fix.php?id=62836&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=62836&r=needdocs
Fixed in release:                    
https://bugs.php.net/fix.php?id=62836&r=alreadyfixed
Need backtrace:                      
https://bugs.php.net/fix.php?id=62836&r=needtrace
Need Reproduce Script:               
https://bugs.php.net/fix.php?id=62836&r=needscript
Try newer version:                   
https://bugs.php.net/fix.php?id=62836&r=oldversion
Not developer issue:                 
https://bugs.php.net/fix.php?id=62836&r=support
Expected behavior:                   
https://bugs.php.net/fix.php?id=62836&r=notwrong
Not enough info:                     
https://bugs.php.net/fix.php?id=62836&r=notenoughinfo
Submitted twice:                     
https://bugs.php.net/fix.php?id=62836&r=submittedtwice
register_globals:                    
https://bugs.php.net/fix.php?id=62836&r=globals
PHP 4 support discontinued:          
https://bugs.php.net/fix.php?id=62836&r=php4
Daylight Savings:                    https://bugs.php.net/fix.php?id=62836&r=dst
IIS Stability:                       
https://bugs.php.net/fix.php?id=62836&r=isapi
Install GNU Sed:                     
https://bugs.php.net/fix.php?id=62836&r=gnused
Floating point limitations:          
https://bugs.php.net/fix.php?id=62836&r=float
No Zend Extensions:                  
https://bugs.php.net/fix.php?id=62836&r=nozend
MySQL Configuration Error:           
https://bugs.php.net/fix.php?id=62836&r=mysqlcfg

Reply via email to