Edit report at https://bugs.php.net/bug.php?id=62852&edit=1
ID: 62852
Comment by: webmaster at thedigitalorchard dot ca
Reported by: kasper at webmasteren dot eu
Summary: Unserialize Invalid Date causes crash
Status: Closed
Type: Bug
Package: Reproducible crash
Operating System: windows, linux
PHP Version: Irrelevant
Assigned To: laruence
Block user comment: N
Private report: N
New Comment:
My [ugly] workaround for this problem is to manually replace instances of
serialized DateTime objects with a fake, non-existent class name, which avoids
this crash.
$str = 'O:8:"DateTime":0:{}';
$str = str_replace('O:8:"DateTime"', 'O:12:"PHP_DateTime"',
$str);
Of course, if the serialized data needed to be recovered, an alternate approach
would be needed. In my own case, I want to be discarding this object. I'm hoping
this issue that ran into is an unforeseen issue with this latest bug fix, and a
proper fix can be made in a future update. I don't like adding in workarounds. :-)
Previous Comments:
------------------------------------------------------------------------
[2013-04-19 20:28:26] webmaster at thedigitalorchard dot ca
I'm getting an error since this bug was "fixed". In one of my databases, a
DateTime object was inadvertently serialized as a child object. Now, with this bug
fix, I'm getting the following error.
The serialized object is represented by this short string:
O:8:"DateTime":0:{}
Running that through unserialize presents this error:
"Invalid serialization data for DateTime object"
I'm unable to catch this error and handle it gracefully (ie. ignoring this object
unserialization entirely).
------------------------------------------------------------------------
[2013-03-15 20:31:10] ab@php.net
Automatic comment on behalf of ab
Revision: http://git.php.net/?p=php-src.git;a=commit;h=f8b91d9acff10ede7bd3f2bc631794a3abef8ff7
Log: Fixed bug #62852 Unserialize Invalid Date crash
------------------------------------------------------------------------
[2013-03-15 08:15:44] ab@php.net
This is also related to bug #53437, where the current implementation suggests
E_ERROR. The fix for ticket should have exactly the same handling the other one
has.
------------------------------------------------------------------------
[2013-03-14 07:50:26] ab@php.net
Looks like there is no other plausible alternative to affect the return value of unserialize from
the __wakeup perspective other than throwing an exception. Looking at what @laruence has done in bug
#64354 I think we can throw an exception in __wakeup and __set_state and integrate
DATE_CHECK_INITIALIZED wherever it's missing. This way it won't delete the invalid date
object from the scope, but that object will respond only with false on each method. Here's the
slightly modified snippet from @tstarling
<?php
$s2 = 'O:3:"Foo":3:{s:4:"date";s:20:"10007-06-07
03:51:49";s:13:"timezone_type";i:3;s:8:"timezone";s:3:"UTC";}';
global $foo;
class Foo extends DateTime {
function __construct() {
global $foo;
$foo = $this;
parent::__construct();
}
function __wakeup() {
global $foo;
$foo = $this;
parent::__wakeup();
}
}
try {
new Foo("10007-06-07 03:51:49");
} catch ( Exception $e ) {}
var_dump( $foo );
try {
unserialize( $s2 );
} catch ( Exception $e ) {}
var_dump( $foo );
Either in both cases after normal construct or after unserialize user will end up with an invalid
$foo object. So there is no BC breach as __construct() already throws an exception, making
__wakeup() do the same and checking dateobj->time != NULL in every method after that should be a
sufficient solution.
------------------------------------------------------------------------
[2013-03-04 12:41:15] ab@php.net
Here's corresponding BT on windows:
php5.dll!fetch_timezone_offset(timelib_tzinfo * tz, __int64 ts, __int64 * transition_time) Line
341C
php5.dll!timelib_get_time_zone_info(__int64 ts, timelib_tzinfo * tz) Line 415C
php5.dll!date_format(char * format, int format_len, timelib_time * t, int localtime) Line 1046C
php5.dll!date_object_get_properties(_zval_struct * object) Line 2117C
php5.dll!php_var_dump(_zval_struct * * struc, int level) Line 129C
php5.dll!zif_var_dump(int ht, _zval_struct * return_value, _zval_struct * * return_value_ptr,
_zval_struct * this_ptr, int return_value_used) Line 181C
php5.dll!zend_do_fcall_common_helper_SPEC(_zend_execute_data * execute_data) Line 320C
php5.dll!ZEND_DO_FCALL_SPEC_CONST_HANDLER(_zend_execute_data * execute_data) Line 1629C
php5.dll!execute(_zend_op_array * op_array) Line 107C
php5.dll!zend_execute_scripts(int type, _zval_struct * * retval, int file_count, ...) Line 1259C
php5.dll!php_execute_script(_zend_file_handle * primary_file) Line 2316C
php.exe!main(int argc, char * * argv) Line 1190C
php.exe!__tmainCRTStartup() Line 586C
kernel32.dll!@BaseThreadInitThunk@12 ()Unknown
ntdll.dll!___RtlUserThreadStart@8 ()Unknown
ntdll.dll!__RtlUserThreadStart@8 ()Unknown
------------------------------------------------------------------------
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
https://bugs.php.net/bug.php?id=62852
--
Edit this bug report at https://bugs.php.net/bug.php?id=62852&edit=1