Bug #63481 [Asn->Fbk]: Segmentation fault caused by unserialize()
Edit report at https://bugs.php.net/bug.php?id=63481&edit=1 ID: 63481 Updated by: m...@php.net Reported by:aurelijus at astdev dot lt Summary:Segmentation fault caused by unserialize() -Status: Assigned +Status: Feedback Type: Bug Package:Reproducible crash Operating System: RHEL 6 & Mac OS X 10.7.4 PHP Version:5.4.8 Assigned To:mike Block user comment: N Private report: N New Comment: Please show the code, which does the serialisation. Which PHP version did the serialisation? Serialized strings are not portable between PHP versions, thea are just meant to be used as temporary representation. Previous Comments: [2012-11-11 07:45:16] larue...@php.net mike,do you have time to look at this? seems due to the unserialize hash level. I tried BG(seralize_lock)++ before calling zend_user_unserliaze, the problem gone. but that break test #63481. I am keeping dig this, but it's better if you can look at this [2012-11-10 17:15:44] larue...@php.net assigned by accident. [2012-11-10 17:10:04] larue...@php.net I can reproduce it. [2012-11-10 16:28:22] aurelijus at astdev dot lt Serialized object: http://aurelijus.eu/string2.txt [2012-11-10 16:24:38] aurelijus at astdev dot lt Description: Hey, I can reproduce this on my local machine (Mac OS X 10.7.4) & our dev server (RHEL 6) with PHP 5.4.* (including 5.4.9RC1). With 5.3.* it's fine. We are trying to unserialize big \Serializable object and it causes the segmentation fault. Code example bellow. Serialized object that causes the issue is attached. PHP Configure: ./configure --prefix=/opt/local --mandir=/opt/local/share/man -- infodir=/opt/local/share/info --program-suffix=54d -- includedir=/opt/local/include/php54d --libdir=/opt/local/lib/php54d --with- config-file-path=/opt/local/etc/php54d --with-config-file-scan- dir=/opt/local/var/db/php54d --disable-all --enable-bcmath --enable-ctype -- enable-dom --enable-fileinfo --enable-filter --enable-hash --enable-json -- enable-libxml --enable-pdo --enable-phar --enable-session --enable-simplexml -- enable-tokenizer --enable-xml --enable-xmlreader --enable-xmlwriter --with- bz2=/opt/local --with-mhash=/opt/local --with-pcre-regex=/opt/local --with- libxml-dir=/opt/local --with-zlib=/opt/local --without-pear --disable-cgi -- disable-fpm --enable-cli --with-libedit=/opt/local --enable-debug Test script: --- Expected result: It should not cause segmentation fault. Actual result: -- Segmentation fault. Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0xffbf VM Regions Near 0xffbf: --> shared memory 7fe0-7fe02000 [8K] r-x/r-x SM=SHM Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 php54d 0x00010f75d994 zend_mm_check_ptr + 500 1 php54d 0x00010f75feed _zend_mm_free_int + 109 2 php54d 0x00010f761bed _efree + 125 3 php54d 0x00010f7ea6eb zend_object_std_dtor + 283 4 php54d 0x00010f7ead20 zend_objects_free_object_storage + 32 5 php54d 0x00010f7f7dc5 zend_objects_store_free_object_storage + 325 6 php54d 0x00010f78c977 shutdown_executor + 1335 7 php54d 0x00010f7a9d1a zend_deactivate + 122 8 php54d 0x00010f6eb681 php_request_shutdown + 1009 9 php54d 0x00010f9834c8 do_cli + 7288 10 php54d 0x00010f984415 main + 3461 11 php54d 0x00010f3de304 start + 52 -- Edit this bug report at https://bugs.php.net/bug.php?id=63481&edit=1
[PHP-BUG] Req #63485 [NEW]: I don't think the mssql_min_error_severity() function works as it should.
From: david at sickmiller dot com
Operating system: CentOS 5.8
PHP version: 5.3.18
Package: MSSQL related
Bug Type: Feature/Change Request
Bug description:I don't think the mssql_min_error_severity() function works as
it should.
Description:
Hi,
I don't think the mssql_min_error_severity() function works as it should.
At a minimum, the one example in the manual does not make sense
(http://www.php.net/function.mssql-min-error-severity#refsect1-function.mssql-min-error-severity-examples).
The example uses a SQL statement with a syntax error. Regardless of what
you set mssql_min_error_severity to, a syntax error is always going to
trigger both (a) a PHP Warning and (b) a false return value from
mssql_query(). This behavior contradicts the comment above
mssql_min_error_severity(1);. Also, since the code checks the return value
from mssql_query(), it's most likely the user will want to use @ to
suppress the PHP Warning but that is not shown in the example.
Here's an example that at least shows the mssql_min_error_severity()
function doing something:
, >=
or when the subquery is used as an expression. (severity 16)
// PHP Warning: mssql_query(): General SQL Server error: Check messages
from the SQL Server (severity 16)
mssql_min_error_severity(17);
mssql_min_message_severity(17);
$query = mssql_query('SELECT *, (select error from master.dbo.sysmessages)
as bad_subquery from master.dbo.sysmessages');
// Prints nothing
Now, the behavior I disagree with relates to the return value from
mssql_query(). Unlike the PHP Warnings, it seems to be unaffected by the
min severity settings. Please see the test script section.
Test script:
---
https://bugs.php.net/bug.php?id=63485&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63485&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63485&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63485&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63485&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63485&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63485&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63485&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63485&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63485&r=support
Expected behavior: https://bugs.php.net/fix.php?id=63485&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63485&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63485&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63485&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63485&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63485&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63485&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63485&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63485&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63485&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63485&r=mysqlcfg
[PHP-BUG] Bug #63486 [NEW]: mysqli_free_result leave the resource variable in a messy state
From: der...@php.net
Operating system:
PHP version: 5.4.8
Package: MySQLi related
Bug Type: Bug
Bug description:mysqli_free_result leave the resource variable in a messy state
Description:
An Xdebug user filed the following report:
http://bugs.xdebug.org/view.php?id=900
I've just investigated this, and found out that this is something I can't
fix in Xdebug. mysqli_free_result() destroys the internal object, but
leaves the resource (in your case, $rs) in a silly state. All Xdebug does
internally is basically a var_dump( $rs ), and after it is freed with
mysqli_free_result(), that throws exactly the same error (without Xdebug).
This can however, easily be fixed in the MySQLi extension with the attached
patch. The patch applies to PHP 5.4, but this also a problem in master and
PHP 5.3. It is also possible, that other mysqli_free_* functions can
benefit from a similar construct.
Test script:
---
Expected result:
The expected result is perhaps something like "NULL" (which my patch makes
it do).
Actual result:
--
hi mom
Warning: var_dump(): Couldn't fetch mysqli_result in
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php on line 10
Call Stack:
0.0002 662616 1. {main}()
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php:0
0.0032 672792 2. var_dump(class mysqli_result { public
$current_field = NULL; public $field_count = NULL; public $lengths = NULL;
public $num_rows = NULL; public $type = NULL })
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php:10
Warning: var_dump(): Couldn't fetch mysqli_result in
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php on line 10
Call Stack:
0.0002 662616 1. {main}()
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php:0
0.0032 672792 2. var_dump(class mysqli_result { public
$current_field = NULL; public $field_count = NULL; public $lengths = NULL;
public $num_rows = NULL; public $type = NULL })
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php:10
Warning: var_dump(): Property access is not allowed yet in
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php on line 10
Call Stack:
0.0002 662616 1. {main}()
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php:0
0.0032 672792 2. var_dump(class mysqli_result { public
$current_field = NULL; public $field_count = NULL; public $lengths = NULL;
public $num_rows = NULL; public $type = NULL })
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php:10
Warning: var_dump(): Couldn't fetch mysqli_result in
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php on line 10
Call Stack:
0.0002 662616 1. {main}()
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php:0
0.0032 672792 2. var_dump(class mysqli_result { public
$current_field = NULL; public $field_count = NULL; public $lengths = NULL;
public $num_rows = NULL; public $type = NULL })
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php:10
Warning: var_dump(): Property access is not allowed yet in
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php on line 10
Call Stack:
0.0002 662616 1. {main}()
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php:0
0.0032 672792 2. var_dump(class mysqli_result { public
$current_field = NULL; public $field_count = NULL; public $lengths = NULL;
public $num_rows = NULL; public $type = NULL })
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php:10
class mysqli_result#2 (5) {
public $current_field =>
NULL
public $field_count =>
NULL
public $lengths =>
NULL
public $num_rows =>
NULL
public $type =>
NULL
}
--
Edit bug report at https://bugs.php.net/bug.php?id=63486&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63486&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63486&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63486&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63486&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63486&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63486&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63486&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63486&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63486&r=support
Expected behavior: https://bugs.php.net/fix.php?id=63486&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63486&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63486&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63486&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63486&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63486&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=6
Bug #63486 [PATCH]: mysqli_free_result leave the resource variable in a messy state
Edit report at https://bugs.php.net/bug.php?id=63486&edit=1
ID: 63486
Patch added by: der...@php.net
Reported by:der...@php.net
Summary:mysqli_free_result leave the resource variable in a
messy state
Status: Open
Type: Bug
Package:MySQLi related
PHP Version:5.4.8
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: mysqli-clear-result-cleanup
Revision: 1352638381
URL:
https://bugs.php.net/patch-display.php?bug=63486&patch=mysqli-clear-result-cleanup&revision=1352638381
Previous Comments:
[2012-11-11 12:52:02] der...@php.net
Description:
An Xdebug user filed the following report:
http://bugs.xdebug.org/view.php?id=900
I've just investigated this, and found out that this is something I can't fix
in Xdebug. mysqli_free_result() destroys the internal object, but leaves the
resource (in your case, $rs) in a silly state. All Xdebug does internally is
basically a var_dump( $rs ), and after it is freed with mysqli_free_result(),
that throws exactly the same error (without Xdebug). This can however, easily
be fixed in the MySQLi extension with the attached patch. The patch applies to
PHP 5.4, but this also a problem in master and PHP 5.3. It is also possible,
that other mysqli_free_* functions can benefit from a similar construct.
Test script:
---
Expected result:
The expected result is perhaps something like "NULL" (which my patch makes it
do).
Actual result:
--
hi mom
Warning: var_dump(): Couldn't fetch mysqli_result in
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php on line 10
Call Stack:
0.0002 662616 1. {main}()
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php:0
0.0032 672792 2. var_dump(class mysqli_result { public $current_field
= NULL; public $field_count = NULL; public $lengths = NULL; public $num_rows =
NULL; public $type = NULL })
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php:10
Warning: var_dump(): Couldn't fetch mysqli_result in
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php on line 10
Call Stack:
0.0002 662616 1. {main}()
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php:0
0.0032 672792 2. var_dump(class mysqli_result { public $current_field
= NULL; public $field_count = NULL; public $lengths = NULL; public $num_rows =
NULL; public $type = NULL })
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php:10
Warning: var_dump(): Property access is not allowed yet in
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php on line 10
Call Stack:
0.0002 662616 1. {main}()
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php:0
0.0032 672792 2. var_dump(class mysqli_result { public $current_field
= NULL; public $field_count = NULL; public $lengths = NULL; public $num_rows =
NULL; public $type = NULL })
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php:10
Warning: var_dump(): Couldn't fetch mysqli_result in
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php on line 10
Call Stack:
0.0002 662616 1. {main}()
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php:0
0.0032 672792 2. var_dump(class mysqli_result { public $current_field
= NULL; public $field_count = NULL; public $lengths = NULL; public $num_rows =
NULL; public $type = NULL })
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php:10
Warning: var_dump(): Property access is not allowed yet in
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php on line 10
Call Stack:
0.0002 662616 1. {main}()
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php:0
0.0032 672792 2. var_dump(class mysqli_result { public $current_field
= NULL; public $field_count = NULL; public $lengths = NULL; public $num_rows =
NULL; public $type = NULL })
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php:10
class mysqli_result#2 (5) {
public $current_field =>
NULL
public $field_count =>
NULL
public $lengths =>
NULL
public $num_rows =>
NULL
public $type =>
NULL
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=63486&edit=1
Bug #63481 [Fbk->Asn]: Segmentation fault caused by unserialize()
Edit report at https://bugs.php.net/bug.php?id=63481&edit=1 ID: 63481 User updated by:aurelijus at astdev dot lt Reported by:aurelijus at astdev dot lt Summary:Segmentation fault caused by unserialize() -Status: Feedback +Status: Assigned Type: Bug Package:Reproducible crash Operating System: RHEL 6 & Mac OS X 10.7.4 PHP Version:5.4.8 Assigned To:mike Block user comment: N Private report: N New Comment: Getting serialization code might be complicated, cause it's mostly 3rd pary framework code + DB, but I'll try. String was generated with 5.4.8. Previous Comments: [2012-11-11 08:41:52] m...@php.net Please show the code, which does the serialisation. Which PHP version did the serialisation? Serialized strings are not portable between PHP versions, thea are just meant to be used as temporary representation. [2012-11-11 07:45:16] larue...@php.net mike,do you have time to look at this? seems due to the unserialize hash level. I tried BG(seralize_lock)++ before calling zend_user_unserliaze, the problem gone. but that break test #63481. I am keeping dig this, but it's better if you can look at this [2012-11-10 17:15:44] larue...@php.net assigned by accident. [2012-11-10 17:10:04] larue...@php.net I can reproduce it. [2012-11-10 16:28:22] aurelijus at astdev dot lt Serialized object: http://aurelijus.eu/string2.txt 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=63481 -- Edit this bug report at https://bugs.php.net/bug.php?id=63481&edit=1
[PHP-BUG] Req #63488 [NEW]: CURLOPT_RESOLVE not defined
From: kf at sumptuouscapital dot com Operating system: GNU/Linux PHP version: 5.4.8 Package: HTTP related Bug Type: Feature/Change Request Bug description:CURLOPT_RESOLVE not defined Description: Since curl 7.21.3 curl_easy_setopt has an option CURLOPT_RESOLVE [0]. Using this option from within PHP results in the following NOTICE and WARNING. Usage of this functionality is necessary for proper Sever Name Indication for verifying CA Certs in certain scenarios. The actual functionality presented by this option seems to work despite the notice and warning. The notice is: PHP Notice: Use of undefined constant CURLOPT_RESOLVE - assumed 'CURLOPT_RESOLVE' in /var/www/localhost/htdocs/status-srv/sks_get_peer_data.php on line 351 This Notice can be removed by explicitly setting a string rather than using it as a constant, however, the following Warning is still presented in both scenarios: Warning: curl_setopt() expects parameter 2 to be long, string given in /var/www/localhost/htdocs/status-srv/sks_get_peer_data.php on line 351 [0] http://curl.haxx.se/libcurl/c/curl_easy_setopt.html Test script: --- https://www.google.com:80/";); curl_setopt($ch, CURLOPT_RESOLVE, "google.com:80:173.194.32.5"); curl_exec($ch); ?> Expected result: No warning Actual result: -- works, but with notice and warning output. -- Edit bug report at https://bugs.php.net/bug.php?id=63488&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63488&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63488&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63488&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63488&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63488&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63488&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63488&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63488&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63488&r=support Expected behavior: https://bugs.php.net/fix.php?id=63488&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63488&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63488&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63488&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63488&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63488&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63488&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63488&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63488&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63488&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63488&r=mysqlcfg
Req->Bug #63488 [Opn]: CURLOPT_RESOLVE not defined
Edit report at https://bugs.php.net/bug.php?id=63488&edit=1 ID: 63488 User updated by:kf at sumptuouscapital dot com Reported by:kf at sumptuouscapital dot com Summary:CURLOPT_RESOLVE not defined Status: Open -Type: Feature/Change Request +Type: Bug Package:HTTP related Operating System: GNU/Linux PHP Version:5.4.8 Block user comment: N Private report: N New Comment: Please disregard the part about the functionality working as expected, it does not use the provided information, just worked out in earlier testing due to circumstance. Due to this I'm flagging it as a bug rather than a RFE Previous Comments: [2012-11-11 18:01:45] kf at sumptuouscapital dot com Description: Since curl 7.21.3 curl_easy_setopt has an option CURLOPT_RESOLVE [0]. Using this option from within PHP results in the following NOTICE and WARNING. Usage of this functionality is necessary for proper Sever Name Indication for verifying CA Certs in certain scenarios. The actual functionality presented by this option seems to work despite the notice and warning. The notice is: PHP Notice: Use of undefined constant CURLOPT_RESOLVE - assumed 'CURLOPT_RESOLVE' in /var/www/localhost/htdocs/status-srv/sks_get_peer_data.php on line 351 This Notice can be removed by explicitly setting a string rather than using it as a constant, however, the following Warning is still presented in both scenarios: Warning: curl_setopt() expects parameter 2 to be long, string given in /var/www/localhost/htdocs/status-srv/sks_get_peer_data.php on line 351 [0] http://curl.haxx.se/libcurl/c/curl_easy_setopt.html Test script: --- https://www.google.com:80/";); curl_setopt($ch, CURLOPT_RESOLVE, "google.com:80:173.194.32.5"); curl_exec($ch); ?> Expected result: No warning Actual result: -- works, but with notice and warning output. -- Edit this bug report at https://bugs.php.net/bug.php?id=63488&edit=1
Bug #63488 [Opn->Asn]: CURLOPT_RESOLVE not defined
Edit report at https://bugs.php.net/bug.php?id=63488&edit=1 ID: 63488 Updated by: fel...@php.net Reported by:kf at sumptuouscapital dot com Summary:CURLOPT_RESOLVE not defined -Status: Open +Status: Assigned Type: Bug Package:HTTP related Operating System: GNU/Linux PHP Version:5.4.8 -Assigned To: +Assigned To:pierrick Block user comment: N Private report: N New Comment: Such feature has been implemented in master branch only. Previous Comments: [2012-11-11 18:27:52] kf at sumptuouscapital dot com Please disregard the part about the functionality working as expected, it does not use the provided information, just worked out in earlier testing due to circumstance. Due to this I'm flagging it as a bug rather than a RFE [2012-11-11 18:01:45] kf at sumptuouscapital dot com Description: Since curl 7.21.3 curl_easy_setopt has an option CURLOPT_RESOLVE [0]. Using this option from within PHP results in the following NOTICE and WARNING. Usage of this functionality is necessary for proper Sever Name Indication for verifying CA Certs in certain scenarios. The actual functionality presented by this option seems to work despite the notice and warning. The notice is: PHP Notice: Use of undefined constant CURLOPT_RESOLVE - assumed 'CURLOPT_RESOLVE' in /var/www/localhost/htdocs/status-srv/sks_get_peer_data.php on line 351 This Notice can be removed by explicitly setting a string rather than using it as a constant, however, the following Warning is still presented in both scenarios: Warning: curl_setopt() expects parameter 2 to be long, string given in /var/www/localhost/htdocs/status-srv/sks_get_peer_data.php on line 351 [0] http://curl.haxx.se/libcurl/c/curl_easy_setopt.html Test script: --- https://www.google.com:80/";); curl_setopt($ch, CURLOPT_RESOLVE, "google.com:80:173.194.32.5"); curl_exec($ch); ?> Expected result: No warning Actual result: -- works, but with notice and warning output. -- Edit this bug report at https://bugs.php.net/bug.php?id=63488&edit=1
Bug #63481 [Asn]: Segmentation fault caused by unserialize()
Edit report at https://bugs.php.net/bug.php?id=63481&edit=1
ID: 63481
Updated by: larue...@php.net
Reported by:aurelijus at astdev dot lt
Summary:Segmentation fault caused by unserialize()
Status: Assigned
Type: Bug
Package:Reproducible crash
Operating System: RHEL 6 & Mac OS X 10.7.4
PHP Version:5.4.8
Assigned To:mike
Block user comment: N
Private report: N
New Comment:
did you generated the "serialize data" by two PHP process?
like:
1. serializer($xxx) then write to a temporary file like /tmp/xxx.txt
2. then in another PHP script,
$data[2]= file_get_contents("/tmp/xxx.txt");
then you got your serialization data by:
$result = serialize($data); ?
thanks
Previous Comments:
[2012-11-11 16:52:42] aurelijus at astdev dot lt
Getting serialization code might be complicated, cause it's mostly 3rd pary
framework code + DB, but I'll try.
String was generated with 5.4.8.
[2012-11-11 08:41:52] m...@php.net
Please show the code, which does the
serialisation.
Which PHP version did the serialisation?
Serialized strings are not portable
between PHP versions, thea are just
meant to be used as temporary
representation.
[2012-11-11 07:45:16] larue...@php.net
mike,do you have time to look at this?
seems due to the unserialize hash level.
I tried BG(seralize_lock)++ before calling zend_user_unserliaze, the problem
gone.
but that break test #63481.
I am keeping dig this, but it's better if you can look at this
[2012-11-10 17:15:44] larue...@php.net
assigned by accident.
[2012-11-10 17:10:04] larue...@php.net
I can reproduce it.
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=63481
--
Edit this bug report at https://bugs.php.net/bug.php?id=63481&edit=1
