Bug #54646 [Com]: segmentation fault
Edit report at https://bugs.php.net/bug.php?id=54646&edit=1 ID: 54646 Comment by: public at grik dot net Reported by:public at grik dot net Summary:segmentation fault Status: No Feedback Type: Bug Package:MySQLi related Operating System: linux PHP Version:5.3.6 Block user comment: N Private report: N New Comment: Well, after almost 2 years and complete migtation to mysqlnd, I can't reproduce a bug because it involves libmysql. I don't see much sence in compiling old PHP and MySQL versions just to reproduce this error. Let's close it. Previous Comments: [2013-02-18 00:34:50] php-bugs at lists dot php dot 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. [2011-05-11 11:07:33] johan...@php.net Let's keep the state at feedback till there is some. -------- [2011-05-10 18:26:59] public at grik dot net I'll try with the last MySQL 5.5.11 [2011-05-10 16:58:16] u...@php.net Glad to hear mysqlnd works fine. Its impossible to tell what could be going on with libmysql by just checking the backtrace. You seem to be using an older version of MySQL/libmysql. Could you try a recent version of libmysql? Also, as hard as it is, it would be most helpful to get a reproducible test script. -------- [2011-05-01 21:14:07] public at grik dot net Sorry, I meant backtrace. Or you need some other one? 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=54646 -- Edit this bug report at https://bugs.php.net/bug.php?id=54646&edit=1
Bug #60840 [Asn]: undefined symbol: mysqlnd_debug_std_no_trace_funcs
Edit report at https://bugs.php.net/bug.php?id=60840&edit=1 ID: 60840 User updated by:public at grik dot net Reported by:public at grik dot net Summary:undefined symbol: mysqlnd_debug_std_no_trace_funcs Status: Assigned Type: Bug Package:PDO related Operating System: linux PHP Version:5.4SVN-2012-01-22 (snap) Assigned To:mysql Block user comment: N Private report: N New Comment: Johannes, thanks for the response, but according to http://php.net/ChangeLog-5.php "ext/mysql, mysqli and pdo_mysql now use mysqlnd by default." in 5.4 So the issues are: 1. Why should we explicitly enable the feature used by default? 2. How can we NOT use mysqlnd in debug mode, if it issues an error for missing mysqlnd_debug_std_no_trace_funcs? Previous Comments: [2012-06-14 09:57:57] fausten at pw-internet dot de Hi, the package is going to build with mysqlnd by default: # cd /usr/ports/databases/php5-pdo_mysql && make config MYSQLND - Use MySQL Native Driver (Is selected by default) # make install clean After installation: The following line has been added to your /usr/local/etc/php/extensions.ini configuration file to automatically load the installed extension: extension=pdo_mysql.so So the extension sholud be loaded after restarting php. [2012-06-14 09:41:44] johan...@php.net When building the MySQL extensions you explicitly have to enable mysqlnd. i.e. --enable-mysqlnd=shared. If you build mysqlnd shared you have to remember to load it, too. I will look whether the build system can be made smarter and at least warn. I don't want to make the decision in there whether to build shared or static. If I'd make that decision I'd default to static mysqlnd. [2012-06-14 09:32:56] fausten at pw-internet dot de Hi, same problem here: # cd /usr/ports/database/php5-pdo_mysql && make install clean Build is successfully. % php foo.php PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20100525-debug/pdo_mysql.so' - /usr/local/lib/php/20100525-debug/pdo_mysql.so: Undefined symbol "mysqlnd_debug_std_no_trace_funcs" in Unknown on line 0 OS: FreeBSD 9.0 amd64 PHP: 5.4.3 builded from ports (# cd /usr/ports/lang/php5 %% make install clean) [2012-05-02 09:30:30] u...@php.net Don't assign to individuals if you mean "mysql". [2012-04-03 05:46:53] luiz dot fk at gmail dot com Hi... same here: PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/extensions/debug-non-zts-20100525/pdo_mysql.so' - /usr/lib64/extensions/debug-non-zts-20100525/pdo_mysql.so: undefined symbol: mysqlnd_debug_std_no_trace_funcs in Unknown on line 0 Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/extensions/debug-non-zts-20100525/pdo_mysql.so' - /usr/lib64/extensions/debug-non-zts-20100525/pdo_mysql.so: undefined symbol: mysqlnd_debug_std_no_trace_funcs in Unknown on line 0 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=60840 -- Edit this bug report at https://bugs.php.net/bug.php?id=60840&edit=1
[PHP-BUG] Bug #60848 [NEW]: php -r works differently
From:
Operating system: linux
PHP version: 5.4.0RC6
Package: CGI/CLI related
Bug Type: Bug
Bug description:php -r works differently
Description:
PHP behaves differently with the code given in a file and in a parameter
provided
with -r
php -r ignores variables, partially recognizes scalar type hinting.
Test script:
---
[root@devel data]# php -r "echo 1;"
1[root@devel data]# php -r "$x=3;"
Parse error: syntax error, unexpected '=' in Command line code on line 1
# php -r "var_dump($x);"
Warning: Wrong parameter count for var_dump() in Command line code on line
1
# php -r "function foo(int $a){}"
Parse error: syntax error, unexpected '(int )' (int) (T_INT_CAST),
expecting '(' in Command line code on line 1
Expected result:
1
Actual result:
--
Parse errors
--
Edit bug report at https://bugs.php.net/bug.php?id=60848&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60848&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60848&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60848&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60848&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60848&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60848&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60848&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60848&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60848&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60848&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60848&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60848&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60848&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60848&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60848&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60848&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60848&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60848&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60848&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60848&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60848&r=mysqlcfg
Bug #60840 [Asn]: undefined symbol: mysqlnd_debug_std_no_trace_funcs
Edit report at https://bugs.php.net/bug.php?id=60840&edit=1 ID: 60840 User updated by:public at grik dot net Reported by:public at grik dot net Summary:undefined symbol: mysqlnd_debug_std_no_trace_funcs Status: Assigned Type: Bug Package:PDO related Operating System: linux PHP Version:5.4SVN-2012-01-22 (snap) Assigned To:uw Block user comment: N Private report: N New Comment: I tried to compile without mysqlnd driver: # cd ext/pdo_mysql # ./configure --with-pdo-mysql=/usr checking for mysql_config... /usr/bin/mysql_config # make; make install #php undefined symbol: mysqlnd_debug_std_no_trace_funcs same issue, even when mysqlnd is not used Previous Comments: [2012-01-22 18:58:33] public at grik dot net Description: I built PHP 5.4 from sources in debug mode with pdo_mysql extension as shared, compiled successfully, but when I starting php I get the startup warning. My configure command: './configure' \ '--prefix=/usr/local' \ '--sysconfdir=/etc' \ '--with-config-file-path=/etc' \ '--with-mysql=shared,mysqlnd' \ '--with-mysqli=shared,mysqlnd' \ '--with-pdo-mysql=shared,mysqlnd' \ --enable-fpm \ --enable-debug Test script: --- just running from command line Actual result: -- # php Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/extensions/debug-non-zts-20100525/pdo_mysql.so' - /usr/local/lib/php/extensions/debug-non-zts-20100525/pdo_mysql.so: undefined symbol: mysqlnd_debug_std_no_trace_funcs in Unknown on line 0 -- Edit this bug report at https://bugs.php.net/bug.php?id=60840&edit=1
[PHP-BUG] Bug #60840 [NEW]: undefined symbol: mysqlnd_debug_std_no_trace_funcs
From: Operating system: linux PHP version: 5.4SVN-2012-01-22 (snap) Package: PDO related Bug Type: Bug Bug description:undefined symbol: mysqlnd_debug_std_no_trace_funcs Description: I built PHP 5.4 from sources in debug mode with pdo_mysql extension as shared, compiled successfully, but when I starting php I get the startup warning. My configure command: './configure' \ '--prefix=/usr/local' \ '--sysconfdir=/etc' \ '--with-config-file-path=/etc' \ '--with-mysql=shared,mysqlnd' \ '--with-mysqli=shared,mysqlnd' \ '--with-pdo-mysql=shared,mysqlnd' \ --enable-fpm \ --enable-debug Test script: --- just running from command line Actual result: -- # php Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/extensions/debug-non-zts-20100525/pdo_mysql.so' - /usr/local/lib/php/extensions/debug-non-zts-20100525/pdo_mysql.so: undefined symbol: mysqlnd_debug_std_no_trace_funcs in Unknown on line 0 -- Edit bug report at https://bugs.php.net/bug.php?id=60840&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60840&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60840&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60840&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60840&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60840&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60840&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60840&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60840&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60840&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60840&r=support Expected behavior: https://bugs.php.net/fix.php?id=60840&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60840&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60840&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60840&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60840&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60840&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60840&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60840&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60840&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60840&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60840&r=mysqlcfg
Req #55181 [Com]: Enhance security by limiting the script extension
Edit report at https://bugs.php.net/bug.php?id=55181&edit=1 ID: 55181 Comment by: public at grik dot net Reported by:f...@php.net Summary:Enhance security by limiting the script extension Status: Closed Type: Feature/Change Request Package:FPM related Operating System: any PHP Version:5.3.6 Assigned To:fat Block user comment: N Private report: N New Comment: it would be MUCH better if you do the same way it's done with date.timezone: if the setting is not defined, it gives a warning on PHP start now everyone blindly upgrading to a minor release with the same php-fpm.conf are shooting their feet Previous Comments: [2012-01-13 08:57:15] laph at gmx dot net This is a massive functionality change, breaking every application that doesn't stick to the ".php" File-Extension when upgrading from 5.3.8 to 5.3.9 since if "security.limit_extensions" is unset, it's limited to ".php". Additionally this new configuration setting is not documented in the FPM-Docs. Please, don't do such changes in minor releases. Or at lease document them properly! [2011-10-08 19:52:26] f...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. [2011-10-08 13:42:08] f...@php.net Automatic comment from SVN on behalf of fat Revision: http://svn.php.net/viewvc/?view=revision&revision=317894 Log: - Backported FR #55181 from 5.4 branch (Enhance security by limiting access to user defined extensions) [2011-07-12 19:01:21] f...@php.net Commited on 5.4. Waiting to 5.3.7 to be released to backport this to 5.3. [2011-07-12 19:00:39] f...@php.net Automatic comment from SVN on behalf of fat Revision: http://svn.php.net/viewvc/?view=revision&revision=313186 Log: - Implemented FR #55181 (Enhance security by limiting access to user defined extensions) 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=55181 -- Edit this bug report at https://bugs.php.net/bug.php?id=55181&edit=1
Bug #54646 [Fbk->Opn]: segmentation fault
Edit report at http://bugs.php.net/bug.php?id=54646&edit=1 ID: 54646 User updated by:public at grik dot net Reported by:public at grik dot net Summary:segmentation fault -Status: Feedback +Status: Open Type: Bug Package:MySQLi related Operating System: linux PHP Version:5.3.6 Block user comment: N Private report: N New Comment: I'll try with the last MySQL 5.5.11 Previous Comments: [2011-05-10 16:58:16] u...@php.net Glad to hear mysqlnd works fine. Its impossible to tell what could be going on with libmysql by just checking the backtrace. You seem to be using an older version of MySQL/libmysql. Could you try a recent version of libmysql? Also, as hard as it is, it would be most helpful to get a reproducible test script. [2011-05-01 21:14:07] public at grik dot net Sorry, I meant backtrace. Or you need some other one? [2011-05-01 21:06:41] public at grik dot net I am sorry, but the bugtrace is already posted in the report. [2011-05-01 14:27:55] paj...@php.net Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2011-05-01 14:26:47] public at grik dot net Description: I observe a segfault when running a xenforo package in debug mode. The configuration of the server is Fedora Core 8, MySQL 5.0.45 I recompiled PHP with debug mode and turned off all extensions not from the standard archive. I found a way to avoid it by recompiling the mysqli extension with mysqlnd driver. I am not really sure if it was worth to open this report as I don't know how you can reproduce it, but at least you'll hear about the issue. Test script: --- I am not sure I can make a minimal reproducable case. Xenforo is a large package based on Zend Framework. any call to the xenforo scripts in debug mode crashes php, both fcgi and cli Actual result: -- backtrace: Core was generated by `php index.php'. Program terminated with signal 11, Segmentation fault. #0 0x083ccebc in add_property_string_ex (arg=0xa62c714, key=0x7a6fb4 "catalog", key_len=8, str=0x665f696b , duplicate=1) at /usr/src/web/php-5.3.6/Zend/zend_API.c:1524 1524 ZVAL_STRING(tmp, str, duplicate); (gdb) bt #0 0x083ccebc in add_property_string_ex (arg=0xa62c714, key=0x7a6fb4 "catalog", key_len=8, str=0x665f696b , duplicate=1) at /usr/src/web/php-5.3.6/Zend/zend_API.c:1524 #1 0x00799f0c in php_add_field_properties (value=0xa62c714, field=0xa2aea28) at /usr/src/web/php-5.3.6/ext/mysqli/mysqli_api.c:1056 #2 0x0079a29b in zif_mysqli_fetch_fields (ht=0, return_value=0xa4b8584, return_value_ptr=0x0, this_ptr=0xa5c9ca0, return_value_used=1) at /usr/src/web/php-5.3.6/ext/mysqli/mysqli_api.c:1114 #3 0x083f3f03 in zend_do_fcall_common_helper_SPEC (execute_data=0xa055c50) at /usr/src/web/php-5.3.6/Zend/zend_vm_execute.h:316 #4 0x083f4b3f in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xa055c50) at /usr/src/web/php-5.3.6/Zend/zend_vm_execute.h:421 #5 0x083f32d2 in execute (op_array=0xa2743b4) at /usr/src/web/php-5.3.6/Zend/zend_vm_execute.h:107 #6 0x083c7718 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/web/php-5.3.6/Zend/zend.c:1194 #7 0x0835bd0c in php_execute_script (primary_file=0xbf889e14) at /usr/src/web/php-5.3.6/main/main.c:2268 #8 0x0849121c in main (argc=2, argv=0xbf889f74) at /usr/src/web/php-5.3.6/sapi/cli/php_cli.c:1193 Missing separate debuginfos, use: debuginfo-install keyutils.i386 (gdb) -- Edit this bug report at http://bugs.php.net/bug.php?id=54646&edit=1
Bug #54644 [Asn->Csd]: wrong pathes in php_pdo_mysql_int.h
Edit report at http://bugs.php.net/bug.php?id=54644&edit=1 ID: 54644 User updated by:public at grik dot net Reported by:public at grik dot net Summary:wrong pathes in php_pdo_mysql_int.h -Status: Assigned +Status: Closed Type: Bug Package:PDO related Operating System: unix PHP Version:5.3.6 Assigned To:mysql Block user comment: N Private report: N New Comment: thanks! I am sorry for the wrong initial description, complaining at # include "ext/mysqlnd/mysqlnd.h" while the error clearly told about "ext/mysql/mysql_mysqlnd.h" Previous Comments: [2011-05-02 21:20:36] tony2...@php.net There's also another issue: you can't install mysqlnd itself, you have to install one of the extensions using it. So in order to build shared version of PDO_MYSQL with myslnd you have to build ext/mysql with myslnd *statically*. I believe ext/mysqlND should be full-grown extension with its own --enable-mysqlnd option, this was you could build it separately AND still be able to use your automagic with $PHP_MYSQLND_ENABLED. [2011-05-02 21:12:41] tony2...@php.net The problem is quite weird. I guess this line: # include "ext/mysql/mysql_mysqlnd.h" ..is some kind of leftover from the good ol' times when mysqlnd was a part of ext/mysql/; at least nothing breaks if I remove it. So the patch is as easy as this: --- php_pdo_mysql_int.h (revision 307861) +++ php_pdo_mysql_int.h (working copy) @@ -25,7 +25,6 @@ #if defined(PDO_USE_MYSQLND) # include "ext/mysqlnd/mysqlnd.h" -# include "ext/mysql/mysql_mysqlnd.h" # include "ext/mysqlnd/mysqlnd_libmysql_compat.h" # define PDO_MYSQL_PARAM_BIND MYSQLND_PARAM_BIND #else ---------------- [2011-05-02 20:19:11] public at grik dot net There is one phpize in the system, and I reinstalled PHP to ensure the error persists. mysqlnd.h exists and is present in the proper folder [root@devel php-5.3.6]# whereis phpize phpize: /usr/local/bin/phpize [root@devel php-5.3.6]# phpize -v Configuring for: PHP Api Version: 20090626 Zend Module Api No: 20090626 Zend Extension Api No: 220090626 [root@devel php-5.3.6]# locate mysqlnd.h /usr/local/include/php/ext/mysqlnd/mysqlnd.h /usr/local/include/php/ext/mysqlnd/php_mysqlnd.h /usr/src/web/php-5.3.6/ext/mysql/mysql_mysqlnd.h /usr/src/web/php-5.3.6/ext/mysqli/mysqli_mysqlnd.h /usr/src/web/php-5.3.6/ext/mysqlnd/mysqlnd.h /usr/src/web/php-5.3.6/ext/mysqlnd/php_mysqlnd.h [root@devel php-5.3.6]# ll /usr/local/include/php/ext/mysqlnd/mysqlnd.h -rw-r--r-- 1 root root 17088 2011-05-02 20:49 /usr/local/include/php/ext/mysqlnd/mysqlnd.h [root@devel php-5.3.6]# php-config --includes -I/usr/local/include/php -I/usr/local/include/php/main - I/usr/local/include/php/TSRM -I/usr/local/include/php/Zend - I/usr/local/include/php/ext -I/usr/local/include/php/ext/date/lib ---------------- [2011-05-02 19:11:42] public at grik dot net Look: # tar -xjf php-5.3.6.tar.bz2 mysqli]# cd php-5.3.6/ext/mysqli/ mysqli]# phpize; ./configure --with-mysqli=mysqlnd; make ... Build complete. Don't forget to run 'make test'. mysqli]# cd ../pdo_mysql/ pdo_mysql]# phpize;./configure --with-pdo-mysql=mysqlnd;make ... In file included from /usr/src/web/php-5.3.6/ext/pdo_mysql/pdo_mysql.c:32: /usr/src/web/php-5.3.6/ext/pdo_mysql/php_pdo_mysql_int.h:28:38: error: ext/mysql/mysql_mysqlnd.h: No such file or directory make: *** [pdo_mysql.lo] Error 1 # php -v PHP 5.3.6 (cli) (built: Apr 30 2011 21:21:49) (DEBUG) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies pdo_mysql]# cd ../.. php-5.3.6]# ./configure --with-pdo-mysql=mysqlnd;make Build complete. Don't forget to run 'make test'. What else can I show you? [2011-05-02 14:43:08] johan...@php.net The mysqlnd.h file inside the distribution is *not* the file you are looking for. You are looking for a file installed on your system. The installation where "phpize" is coming from. 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/bug.php?id=54644 -- Edit this bug report at http://bugs.php.net/bug.php?id=54644&edit=1
Bug #54644 [Asn]: wrong pathes in php_pdo_mysql_int.h
Edit report at http://bugs.php.net/bug.php?id=54644&edit=1 ID: 54644 User updated by:public at grik dot net Reported by:public at grik dot net Summary:wrong pathes in php_pdo_mysql_int.h Status: Assigned Type: Bug Package:PDO related Operating System: unix PHP Version:5.3.6 Assigned To:mysql Block user comment: N Private report: N New Comment: There is one phpize in the system, and I reinstalled PHP to ensure the error persists. mysqlnd.h exists and is present in the proper folder [root@devel php-5.3.6]# whereis phpize phpize: /usr/local/bin/phpize [root@devel php-5.3.6]# phpize -v Configuring for: PHP Api Version: 20090626 Zend Module Api No: 20090626 Zend Extension Api No: 220090626 [root@devel php-5.3.6]# locate mysqlnd.h /usr/local/include/php/ext/mysqlnd/mysqlnd.h /usr/local/include/php/ext/mysqlnd/php_mysqlnd.h /usr/src/web/php-5.3.6/ext/mysql/mysql_mysqlnd.h /usr/src/web/php-5.3.6/ext/mysqli/mysqli_mysqlnd.h /usr/src/web/php-5.3.6/ext/mysqlnd/mysqlnd.h /usr/src/web/php-5.3.6/ext/mysqlnd/php_mysqlnd.h [root@devel php-5.3.6]# ll /usr/local/include/php/ext/mysqlnd/mysqlnd.h -rw-r--r-- 1 root root 17088 2011-05-02 20:49 /usr/local/include/php/ext/mysqlnd/mysqlnd.h [root@devel php-5.3.6]# php-config --includes -I/usr/local/include/php -I/usr/local/include/php/main - I/usr/local/include/php/TSRM -I/usr/local/include/php/Zend - I/usr/local/include/php/ext -I/usr/local/include/php/ext/date/lib Previous Comments: [2011-05-02 19:11:42] public at grik dot net Look: # tar -xjf php-5.3.6.tar.bz2 mysqli]# cd php-5.3.6/ext/mysqli/ mysqli]# phpize; ./configure --with-mysqli=mysqlnd; make ... Build complete. Don't forget to run 'make test'. mysqli]# cd ../pdo_mysql/ pdo_mysql]# phpize;./configure --with-pdo-mysql=mysqlnd;make ... In file included from /usr/src/web/php-5.3.6/ext/pdo_mysql/pdo_mysql.c:32: /usr/src/web/php-5.3.6/ext/pdo_mysql/php_pdo_mysql_int.h:28:38: error: ext/mysql/mysql_mysqlnd.h: No such file or directory make: *** [pdo_mysql.lo] Error 1 # php -v PHP 5.3.6 (cli) (built: Apr 30 2011 21:21:49) (DEBUG) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies pdo_mysql]# cd ../.. php-5.3.6]# ./configure --with-pdo-mysql=mysqlnd;make Build complete. Don't forget to run 'make test'. What else can I show you? [2011-05-02 14:43:08] johan...@php.net The mysqlnd.h file inside the distribution is *not* the file you are looking for. You are looking for a file installed on your system. The installation where "phpize" is coming from. ---------------- [2011-05-02 13:40:20] public at grik dot net yes, I have it installed. It was a re-compilation of an extension due to another error: http://bugs.php.net/bug.php?id=54646 I understand you are busy and abused by reports, but this is not that case. I managed to recompile it after patching the header file. Please re-read the description. [2011-05-02 13:32:13] johan...@php.net To compile the extension stand-alone you need an installed PHP. I was asking about that. ---------------- [2011-05-02 13:26:33] public at grik dot net yes, I am sure, I download PHP archive from this site and compile it manually always; It does not matter how I compile. Just open php- 5.3.6/ext/pdo_mysql/php_pdo_mysql_int.h and look at lines 27-29 You can compile only from the root folder of the archive, but if you want to build the extension separately with phpize, you need to edit the source. 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/bug.php?id=54644 -- Edit this bug report at http://bugs.php.net/bug.php?id=54644&edit=1
Bug #54644 [Fbk->Asn]: wrong pathes in php_pdo_mysql_int.h
Edit report at http://bugs.php.net/bug.php?id=54644&edit=1 ID: 54644 User updated by:public at grik dot net Reported by:public at grik dot net Summary:wrong pathes in php_pdo_mysql_int.h -Status: Feedback +Status: Assigned Type: Bug Package:PDO related Operating System: unix PHP Version:5.3.6 Assigned To:mysql Block user comment: N Private report: N New Comment: Look: # tar -xjf php-5.3.6.tar.bz2 mysqli]# cd php-5.3.6/ext/mysqli/ mysqli]# phpize; ./configure --with-mysqli=mysqlnd; make ... Build complete. Don't forget to run 'make test'. mysqli]# cd ../pdo_mysql/ pdo_mysql]# phpize;./configure --with-pdo-mysql=mysqlnd;make ... In file included from /usr/src/web/php-5.3.6/ext/pdo_mysql/pdo_mysql.c:32: /usr/src/web/php-5.3.6/ext/pdo_mysql/php_pdo_mysql_int.h:28:38: error: ext/mysql/mysql_mysqlnd.h: No such file or directory make: *** [pdo_mysql.lo] Error 1 # php -v PHP 5.3.6 (cli) (built: Apr 30 2011 21:21:49) (DEBUG) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies pdo_mysql]# cd ../.. php-5.3.6]# ./configure --with-pdo-mysql=mysqlnd;make Build complete. Don't forget to run 'make test'. What else can I show you? Previous Comments: [2011-05-02 14:43:08] johan...@php.net The mysqlnd.h file inside the distribution is *not* the file you are looking for. You are looking for a file installed on your system. The installation where "phpize" is coming from. ---------------- [2011-05-02 13:40:20] public at grik dot net yes, I have it installed. It was a re-compilation of an extension due to another error: http://bugs.php.net/bug.php?id=54646 I understand you are busy and abused by reports, but this is not that case. I managed to recompile it after patching the header file. Please re-read the description. [2011-05-02 13:32:13] johan...@php.net To compile the extension stand-alone you need an installed PHP. I was asking about that. ---------------- [2011-05-02 13:26:33] public at grik dot net yes, I am sure, I download PHP archive from this site and compile it manually always; It does not matter how I compile. Just open php- 5.3.6/ext/pdo_mysql/php_pdo_mysql_int.h and look at lines 27-29 You can compile only from the root folder of the archive, but if you want to build the extension separately with phpize, you need to edit the source. [2011-05-02 11:41:32] johan...@php.net How did you compile and install PHP? Are you sure you have a clean installation and not a mixture of different PHPs? It works for me properly. Also: what kind of Unix are you using? 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/bug.php?id=54644 -- Edit this bug report at http://bugs.php.net/bug.php?id=54644&edit=1
Bug #54644 [Fbk->Asn]: wrong pathes in php_pdo_mysql_int.h
Edit report at http://bugs.php.net/bug.php?id=54644&edit=1 ID: 54644 User updated by:public at grik dot net Reported by:public at grik dot net Summary:wrong pathes in php_pdo_mysql_int.h -Status: Feedback +Status: Assigned Type: Bug Package:PDO related Operating System: unix PHP Version:5.3.6 Assigned To:mysql Block user comment: N Private report: N New Comment: yes, I have it installed. It was a re-compilation of an extension due to another error: http://bugs.php.net/bug.php?id=54646 I understand you are busy and abused by reports, but this is not that case. I managed to recompile it after patching the header file. Please re-read the description. Previous Comments: [2011-05-02 13:32:13] johan...@php.net To compile the extension stand-alone you need an installed PHP. I was asking about that. [2011-05-02 13:26:33] public at grik dot net yes, I am sure, I download PHP archive from this site and compile it manually always; It does not matter how I compile. Just open php- 5.3.6/ext/pdo_mysql/php_pdo_mysql_int.h and look at lines 27-29 You can compile only from the root folder of the archive, but if you want to build the extension separately with phpize, you need to edit the source. [2011-05-02 11:41:32] johan...@php.net How did you compile and install PHP? Are you sure you have a clean installation and not a mixture of different PHPs? It works for me properly. Also: what kind of Unix are you using? [2011-05-01 14:15:34] public at grik dot net Description: in ext/pdo_mysql/php_pdo_mysql_int.h you have #if defined(PDO_USE_MYSQLND) # include "ext/mysqlnd/mysqlnd.h" # include "ext/mysql/mysql_mysqlnd.h" # include "ext/mysqlnd/mysqlnd_libmysql_compat.h" ... #if defined(PDO_USE_MYSQLND) #include "ext/mysqlnd/mysqlnd_debug.h" so when I tried to re-compile the pdo_mysql extension from the extension folder using `phpize;configure--with-pdo-mysql=mysqlnd;make`, it barkled that can't find "ext/mysqlnd/mysqlnd.h" I changed to #include "../../ext/mysqlnd/mysqlnd_debug.h" and compiled the extension, but that's obviously not a solution. Test script: --- none Expected result: Build complete. Don't forget to run 'make test'. Actual result: -- In file included from /usr/src/web/php-5.3.6/ext/pdo_mysql/pdo_mysql.c:32: /usr/src/web/php-5.3.6/ext/pdo_mysql/php_pdo_mysql_int.h:28:38: error: ext/mysql/mysql_mysqlnd.h: No such file or directory -- Edit this bug report at http://bugs.php.net/bug.php?id=54644&edit=1
Bug #54644 [Fbk->Asn]: wrong pathes in php_pdo_mysql_int.h
Edit report at http://bugs.php.net/bug.php?id=54644&edit=1 ID: 54644 User updated by:public at grik dot net Reported by:public at grik dot net Summary:wrong pathes in php_pdo_mysql_int.h -Status: Feedback +Status: Assigned Type: Bug Package:PDO related Operating System: unix PHP Version:5.3.6 Assigned To:mysql Block user comment: N Private report: N New Comment: yes, I am sure, I download PHP archive from this site and compile it manually always; It does not matter how I compile. Just open php- 5.3.6/ext/pdo_mysql/php_pdo_mysql_int.h and look at lines 27-29 You can compile only from the root folder of the archive, but if you want to build the extension separately with phpize, you need to edit the source. Previous Comments: [2011-05-02 11:41:32] johan...@php.net How did you compile and install PHP? Are you sure you have a clean installation and not a mixture of different PHPs? It works for me properly. Also: what kind of Unix are you using? [2011-05-01 14:15:34] public at grik dot net Description: in ext/pdo_mysql/php_pdo_mysql_int.h you have #if defined(PDO_USE_MYSQLND) # include "ext/mysqlnd/mysqlnd.h" # include "ext/mysql/mysql_mysqlnd.h" # include "ext/mysqlnd/mysqlnd_libmysql_compat.h" ... #if defined(PDO_USE_MYSQLND) #include "ext/mysqlnd/mysqlnd_debug.h" so when I tried to re-compile the pdo_mysql extension from the extension folder using `phpize;configure--with-pdo-mysql=mysqlnd;make`, it barkled that can't find "ext/mysqlnd/mysqlnd.h" I changed to #include "../../ext/mysqlnd/mysqlnd_debug.h" and compiled the extension, but that's obviously not a solution. Test script: --- none Expected result: Build complete. Don't forget to run 'make test'. Actual result: -- In file included from /usr/src/web/php-5.3.6/ext/pdo_mysql/pdo_mysql.c:32: /usr/src/web/php-5.3.6/ext/pdo_mysql/php_pdo_mysql_int.h:28:38: error: ext/mysql/mysql_mysqlnd.h: No such file or directory -- Edit this bug report at http://bugs.php.net/bug.php?id=54644&edit=1
Bug #54646 [Fbk->Opn]: segmentation fault
Edit report at http://bugs.php.net/bug.php?id=54646&edit=1 ID: 54646 User updated by:public at grik dot net Reported by:public at grik dot net Summary:segmentation fault -Status: Feedback +Status: Open Type: Bug Package:MySQLi related Operating System: linux PHP Version:5.3.6 Block user comment: N Private report: N New Comment: Sorry, I meant backtrace. Or you need some other one? Previous Comments: [2011-05-01 21:06:41] public at grik dot net I am sorry, but the bugtrace is already posted in the report. [2011-05-01 14:27:55] paj...@php.net Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2011-05-01 14:26:47] public at grik dot net Description: I observe a segfault when running a xenforo package in debug mode. The configuration of the server is Fedora Core 8, MySQL 5.0.45 I recompiled PHP with debug mode and turned off all extensions not from the standard archive. I found a way to avoid it by recompiling the mysqli extension with mysqlnd driver. I am not really sure if it was worth to open this report as I don't know how you can reproduce it, but at least you'll hear about the issue. Test script: --- I am not sure I can make a minimal reproducable case. Xenforo is a large package based on Zend Framework. any call to the xenforo scripts in debug mode crashes php, both fcgi and cli Actual result: -- backtrace: Core was generated by `php index.php'. Program terminated with signal 11, Segmentation fault. #0 0x083ccebc in add_property_string_ex (arg=0xa62c714, key=0x7a6fb4 "catalog", key_len=8, str=0x665f696b , duplicate=1) at /usr/src/web/php-5.3.6/Zend/zend_API.c:1524 1524 ZVAL_STRING(tmp, str, duplicate); (gdb) bt #0 0x083ccebc in add_property_string_ex (arg=0xa62c714, key=0x7a6fb4 "catalog", key_len=8, str=0x665f696b , duplicate=1) at /usr/src/web/php-5.3.6/Zend/zend_API.c:1524 #1 0x00799f0c in php_add_field_properties (value=0xa62c714, field=0xa2aea28) at /usr/src/web/php-5.3.6/ext/mysqli/mysqli_api.c:1056 #2 0x0079a29b in zif_mysqli_fetch_fields (ht=0, return_value=0xa4b8584, return_value_ptr=0x0, this_ptr=0xa5c9ca0, return_value_used=1) at /usr/src/web/php-5.3.6/ext/mysqli/mysqli_api.c:1114 #3 0x083f3f03 in zend_do_fcall_common_helper_SPEC (execute_data=0xa055c50) at /usr/src/web/php-5.3.6/Zend/zend_vm_execute.h:316 #4 0x083f4b3f in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xa055c50) at /usr/src/web/php-5.3.6/Zend/zend_vm_execute.h:421 #5 0x083f32d2 in execute (op_array=0xa2743b4) at /usr/src/web/php-5.3.6/Zend/zend_vm_execute.h:107 #6 0x083c7718 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/web/php-5.3.6/Zend/zend.c:1194 #7 0x0835bd0c in php_execute_script (primary_file=0xbf889e14) at /usr/src/web/php-5.3.6/main/main.c:2268 #8 0x0849121c in main (argc=2, argv=0xbf889f74) at /usr/src/web/php-5.3.6/sapi/cli/php_cli.c:1193 Missing separate debuginfos, use: debuginfo-install keyutils.i386 (gdb) -- Edit this bug report at http://bugs.php.net/bug.php?id=54646&edit=1
Bug #54646 [Com]: segmentation fault
Edit report at http://bugs.php.net/bug.php?id=54646&edit=1 ID: 54646 Comment by: public at grik dot net Reported by:public at grik dot net Summary:segmentation fault Status: Feedback Type: Bug Package:MySQLi related Operating System: linux PHP Version:5.3.6 Block user comment: N Private report: N New Comment: I am sorry, but the bugtrace is already posted in the report. Previous Comments: [2011-05-01 14:27:55] paj...@php.net Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2011-05-01 14:26:47] public at grik dot net Description: I observe a segfault when running a xenforo package in debug mode. The configuration of the server is Fedora Core 8, MySQL 5.0.45 I recompiled PHP with debug mode and turned off all extensions not from the standard archive. I found a way to avoid it by recompiling the mysqli extension with mysqlnd driver. I am not really sure if it was worth to open this report as I don't know how you can reproduce it, but at least you'll hear about the issue. Test script: --- I am not sure I can make a minimal reproducable case. Xenforo is a large package based on Zend Framework. any call to the xenforo scripts in debug mode crashes php, both fcgi and cli Actual result: -- backtrace: Core was generated by `php index.php'. Program terminated with signal 11, Segmentation fault. #0 0x083ccebc in add_property_string_ex (arg=0xa62c714, key=0x7a6fb4 "catalog", key_len=8, str=0x665f696b , duplicate=1) at /usr/src/web/php-5.3.6/Zend/zend_API.c:1524 1524 ZVAL_STRING(tmp, str, duplicate); (gdb) bt #0 0x083ccebc in add_property_string_ex (arg=0xa62c714, key=0x7a6fb4 "catalog", key_len=8, str=0x665f696b , duplicate=1) at /usr/src/web/php-5.3.6/Zend/zend_API.c:1524 #1 0x00799f0c in php_add_field_properties (value=0xa62c714, field=0xa2aea28) at /usr/src/web/php-5.3.6/ext/mysqli/mysqli_api.c:1056 #2 0x0079a29b in zif_mysqli_fetch_fields (ht=0, return_value=0xa4b8584, return_value_ptr=0x0, this_ptr=0xa5c9ca0, return_value_used=1) at /usr/src/web/php-5.3.6/ext/mysqli/mysqli_api.c:1114 #3 0x083f3f03 in zend_do_fcall_common_helper_SPEC (execute_data=0xa055c50) at /usr/src/web/php-5.3.6/Zend/zend_vm_execute.h:316 #4 0x083f4b3f in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xa055c50) at /usr/src/web/php-5.3.6/Zend/zend_vm_execute.h:421 #5 0x083f32d2 in execute (op_array=0xa2743b4) at /usr/src/web/php-5.3.6/Zend/zend_vm_execute.h:107 #6 0x083c7718 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/web/php-5.3.6/Zend/zend.c:1194 #7 0x0835bd0c in php_execute_script (primary_file=0xbf889e14) at /usr/src/web/php-5.3.6/main/main.c:2268 #8 0x0849121c in main (argc=2, argv=0xbf889f74) at /usr/src/web/php-5.3.6/sapi/cli/php_cli.c:1193 Missing separate debuginfos, use: debuginfo-install keyutils.i386 (gdb) -- Edit this bug report at http://bugs.php.net/bug.php?id=54646&edit=1
[PHP-BUG] Bug #54646 [NEW]: segmentation fault
From: Operating system: linux PHP version: 5.3.6 Package: MySQLi related Bug Type: Bug Bug description:segmentation fault Description: I observe a segfault when running a xenforo package in debug mode. The configuration of the server is Fedora Core 8, MySQL 5.0.45 I recompiled PHP with debug mode and turned off all extensions not from the standard archive. I found a way to avoid it by recompiling the mysqli extension with mysqlnd driver. I am not really sure if it was worth to open this report as I don't know how you can reproduce it, but at least you'll hear about the issue. Test script: --- I am not sure I can make a minimal reproducable case. Xenforo is a large package based on Zend Framework. any call to the xenforo scripts in debug mode crashes php, both fcgi and cli Actual result: -- backtrace: Core was generated by `php index.php'. Program terminated with signal 11, Segmentation fault. #0 0x083ccebc in add_property_string_ex (arg=0xa62c714, key=0x7a6fb4 "catalog", key_len=8, str=0x665f696b , duplicate=1) at /usr/src/web/php-5.3.6/Zend/zend_API.c:1524 1524 ZVAL_STRING(tmp, str, duplicate); (gdb) bt #0 0x083ccebc in add_property_string_ex (arg=0xa62c714, key=0x7a6fb4 "catalog", key_len=8, str=0x665f696b , duplicate=1) at /usr/src/web/php-5.3.6/Zend/zend_API.c:1524 #1 0x00799f0c in php_add_field_properties (value=0xa62c714, field=0xa2aea28) at /usr/src/web/php-5.3.6/ext/mysqli/mysqli_api.c:1056 #2 0x0079a29b in zif_mysqli_fetch_fields (ht=0, return_value=0xa4b8584, return_value_ptr=0x0, this_ptr=0xa5c9ca0, return_value_used=1) at /usr/src/web/php-5.3.6/ext/mysqli/mysqli_api.c:1114 #3 0x083f3f03 in zend_do_fcall_common_helper_SPEC (execute_data=0xa055c50) at /usr/src/web/php-5.3.6/Zend/zend_vm_execute.h:316 #4 0x083f4b3f in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xa055c50) at /usr/src/web/php-5.3.6/Zend/zend_vm_execute.h:421 #5 0x083f32d2 in execute (op_array=0xa2743b4) at /usr/src/web/php-5.3.6/Zend/zend_vm_execute.h:107 #6 0x083c7718 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/web/php-5.3.6/Zend/zend.c:1194 #7 0x0835bd0c in php_execute_script (primary_file=0xbf889e14) at /usr/src/web/php-5.3.6/main/main.c:2268 #8 0x0849121c in main (argc=2, argv=0xbf889f74) at /usr/src/web/php-5.3.6/sapi/cli/php_cli.c:1193 Missing separate debuginfos, use: debuginfo-install keyutils.i386 (gdb) -- Edit bug report at http://bugs.php.net/bug.php?id=54646&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54646&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54646&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54646&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54646&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54646&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54646&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54646&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54646&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54646&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54646&r=support Expected behavior: http://bugs.php.net/fix.php?id=54646&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54646&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54646&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54646&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54646&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54646&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54646&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54646&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54646&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54646&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54646&r=mysqlcfg
[PHP-BUG] Bug #54644 [NEW]: wrong pathes in php_pdo_mysql_int.h
From: Operating system: unix PHP version: 5.3.6 Package: PDO related Bug Type: Bug Bug description:wrong pathes in php_pdo_mysql_int.h Description: in ext/pdo_mysql/php_pdo_mysql_int.h you have #if defined(PDO_USE_MYSQLND) # include "ext/mysqlnd/mysqlnd.h" # include "ext/mysql/mysql_mysqlnd.h" # include "ext/mysqlnd/mysqlnd_libmysql_compat.h" ... #if defined(PDO_USE_MYSQLND) #include "ext/mysqlnd/mysqlnd_debug.h" so when I tried to re-compile the pdo_mysql extension from the extension folder using `phpize;configure--with-pdo-mysql=mysqlnd;make`, it barkled that can't find "ext/mysqlnd/mysqlnd.h" I changed to #include "../../ext/mysqlnd/mysqlnd_debug.h" and compiled the extension, but that's obviously not a solution. Test script: --- none Expected result: Build complete. Don't forget to run 'make test'. Actual result: -- In file included from /usr/src/web/php-5.3.6/ext/pdo_mysql/pdo_mysql.c:32: /usr/src/web/php-5.3.6/ext/pdo_mysql/php_pdo_mysql_int.h:28:38: error: ext/mysql/mysql_mysqlnd.h: No such file or directory -- Edit bug report at http://bugs.php.net/bug.php?id=54644&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54644&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54644&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54644&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54644&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54644&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54644&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54644&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54644&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54644&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54644&r=support Expected behavior: http://bugs.php.net/fix.php?id=54644&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54644&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54644&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54644&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54644&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54644&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54644&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54644&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54644&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54644&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54644&r=mysqlcfg
Bug #53394 [Com]: ARRAY_AS_PROPS flag is ignored when used with PDOStatement::fetchObject
Edit report at http://bugs.php.net/bug.php?id=53394&edit=1
ID: 53394
Comment by: public at grik dot net
Reported by:public at grik dot net
Summary:ARRAY_AS_PROPS flag is ignored when used with
PDOStatement::fetchObject
Status: Bogus
Type: Bug
Package:SPL related
PHP Version:5.3.3
Assigned To:felipe
Block user comment: N
Private report: N
New Comment:
It's not bogus. It is a documentation issue at least.
I guess, it needs to be described somewhere beyond the bugtracker.
all I see in docs is:
PDO::FETCH_PROPS_LATE ( integer )
Available since PHP 5.2.0
Previous Comments:
[2010-11-24 22:16:34] fel...@php.net
Hi, there was a discussion about this, see bug #49521
You could do something like this:
$a = $PDO->query('select id from links');
$a->setFetchMode(PDO::FETCH_CLASS|PDO::FETCH_PROPS_LATE, 'ArraySlice');
$a = $a->fetch();
var_dump($a->id, $a['id']);
Thanks.
[2010-11-24 15:27:19] tony2...@php.net
Felipe, could you check this out plz?
[2010-11-24 15:25:58] tony2...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2010-11-24 13:54:20] crocodile2u at gmail dot com
Or possibly it would be better to change the PDO's behaviour? It seems
very
strange and unnatural that constructor is called after the properties
are set. It
only makes developers write unobvious code for the only purpose of
workaround for
this PDO's feature (personally, I would consider it a bug).
----------------
[2010-11-24 13:46:58] public at grik dot net
I was hinted that PDO sets the fields before calling a constructor.
It makes everything clear.
parent::__construct($array,ArrayObject::ARRAY_AS_PROPS);
is called after setting object fields, and they don't get processed by
ArrayObject::offsetSet.
ArrayObject::оffsetGet after changing mode to ARRAY_AS_PROPS doesn't
see the fields set by the PDO hack.
оffsetGet can process existing fields after changing the mode, I
suppose.
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/bug.php?id=53394
--
Edit this bug report at http://bugs.php.net/bug.php?id=53394&edit=1
Bug #53394 [Com]: ARRAY_AS_PROPS flag is ignored when used with PDOStatement::fetchObject
Edit report at http://bugs.php.net/bug.php?id=53394&edit=1
ID: 53394
Comment by: public at grik dot net
Reported by:public at grik dot net
Summary:ARRAY_AS_PROPS flag is ignored when used with
PDOStatement::fetchObject
Status: Open
Type: Bug
Package:SPL related
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
I was hinted that PDO sets the fields before calling a constructor.
It makes everything clear.
parent::__construct($array,ArrayObject::ARRAY_AS_PROPS);
is called after setting object fields, and they don't get processed by
ArrayObject::offsetSet.
ArrayObject::оffsetGet after changing mode to ARRAY_AS_PROPS doesn't
see the fields set by the PDO hack.
оffsetGet can process existing fields after changing the mode, I
suppose.
Previous Comments:
[2010-11-24 04:13:05] public at grik dot net
Description:
If the object is created and filled by PDOStatement::fetchObject, the
ArrayObject::ARRAY_AS_PROPS is ignored.
Seems like PDO sets the fields values directly around ArrayObject magic
setters, and breaks the ArrayObject native behaviour.
Test script:
---
class ArraySlice extends ArrayObject{
function __construct(array $array=array()){
parent::__construct($array,ArrayObject::ARRAY_AS_PROPS);
}
}
$PDO = new PDO($dsn, $user, $password);
$a = $PDO->query('select id from links')->fetchObject('ArraySlice');
echo $a->id; //works
echo $a['id'];//Notice occured ... Undefined index: id
Expected result:
value of the id field
Actual result:
--
Notice
--
Edit this bug report at http://bugs.php.net/bug.php?id=53394&edit=1
[PHP-BUG] Bug #53394 [NEW]: ARRAY_AS_PROPS flag is ignored when used with PDOStatement::fetchObject
From:
Operating system:
PHP version: 5.3.3
Package: SPL related
Bug Type: Bug
Bug description:ARRAY_AS_PROPS flag is ignored when used with
PDOStatement::fetchObject
Description:
If the object is created and filled by PDOStatement::fetchObject, the
ArrayObject::ARRAY_AS_PROPS is ignored.
Seems like PDO sets the fields values directly around ArrayObject magic
setters, and breaks the ArrayObject native behaviour.
Test script:
---
class ArraySlice extends ArrayObject{
function __construct(array $array=array()){
parent::__construct($array,ArrayObject::ARRAY_AS_PROPS);
}
}
$PDO = new PDO($dsn, $user, $password);
$a = $PDO->query('select id from links')->fetchObject('ArraySlice');
echo $a->id; //works
echo $a['id'];//Notice occured ... Undefined index: id
Expected result:
value of the id field
Actual result:
--
Notice
--
Edit bug report at http://bugs.php.net/bug.php?id=53394&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53394&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53394&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53394&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53394&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53394&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53394&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53394&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53394&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53394&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53394&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53394&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53394&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53394&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53394&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53394&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53394&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53394&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53394&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53394&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53394&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53394&r=mysqlcfg
Bug #53362 [Opn]: Segmentation fault when extending SplFixedArray
Edit report at http://bugs.php.net/bug.php?id=53362&edit=1 ID: 53362 User updated by:public at grik dot net Reported by:public at grik dot net Summary:Segmentation fault when extending SplFixedArray Status: Open Type: Bug Package:SPL related Operating System: Linux, Windows PHP Version:5.3.3 Block user comment: N Private report: N New Comment: Program received signal SIGSEGV, Segmentation fault. 0x005cbfcf in spl_fixedarray_object_write_dimension (object=0x80232c818, offset=0x0, value=0x8023310a8) at /usr/ports/lang/php5/work/php-5.3.3/ext/spl/spl_fixedarray.c:409 409 in /usr/ports/lang/php5/work/php-5.3.3/ext/spl/spl_fixedarray.c Previous Comments: [2010-11-19 20:15:39] public at grik dot net Description: Segmentation fault when extending SplFixedArray and working with it as with an array. Test script: --- http://bugs.php.net/bug.php?id=53362&edit=1
[PHP-BUG] Bug #53362 [NEW]: Segmentation fault when extending SplFixedArray
From: Operating system: Linux, Windows PHP version: 5.3.3 Package: SPL related Bug Type: Bug Bug description:Segmentation fault when extending SplFixedArray Description: Segmentation fault when extending SplFixedArray and working with it as with an array. Test script: --- http://bugs.php.net/bug.php?id=53362&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53362&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53362&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53362&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53362&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53362&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53362&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53362&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53362&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53362&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53362&r=support Expected behavior: http://bugs.php.net/fix.php?id=53362&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53362&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53362&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53362&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53362&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53362&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53362&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53362&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53362&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53362&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53362&r=mysqlcfg
#38118 [Fbk->Opn]: unrelated error when using reference
ID: 38118
User updated by: public at grik dot net
Reported By: public at grik dot net
-Status: Feedback
+Status: Open
Bug Type: Feature/Change Request
Operating System: *
-PHP Version: 5.1.4
+PHP Version: 5.2.0
New Comment:
exactly the same error
[EMAIL PROTECTED] www]# php -v
PHP 5.2.0-dev (cli) (built: Jul 24 2006 02:54:55)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2006 Zend Technologies
[EMAIL PROTECTED] www]# php test.php
Fatal error: Objects used as arrays in post/pre increment/decrement
must return values by reference in /www/test.php on line 27
Previous Comments:
[2006-07-17 06:36:04] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
[2006-07-17 00:42:47] public at grik dot net
Thank you.
The problem of using reference in ArrayAccess class is pure practical.
I have a set of rules and data fields - each field should be checked
against it's rule (e.g. min, max).
I write the hierarchy of classes implementing the exact logic for each
rule. The class instance should get the set of rule parameters and the
data reference.
Then I interate over the management object (extends ArrayObject) with
foreach and get the checking object as a value.
As result, I can make the rules to check the data regardless of it's
type and source - scalar, array, resource. All I need is to write
another class with the check logic.
The data may be large, and inability to use references may lead either
to
- memory overconsumption
- DDOS-insecure issue
- having to refuse from abstration and write more code
[2006-07-16 23:55:43] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
The '&' is because of inhereitance rules.
The second thing you encounter, the '&=' is an engine limitation.
Btw, both are pure engine issues, nothing todo with SPL.
Maybe you want this reopened as feature request. But then i suggest you
provide at least some ideas where and how to document that ArayAccess
cannot be used in modifying operators like '&='.
Either way you should try 5.2/HEAD first as we've put some work to get
you a better error message.
--------------------
[2006-07-16 23:43:09] public at grik dot net
P.S.
I am not allowed to define function offsetGet($key)as
"function &offsetGet($key){...}"
to return the value by reference due to the requirements of the
ArrayAccess interface.
----------------
[2006-07-16 23:37:34] public at grik dot net
Description:
Slightly modifying a Harry Fuecks's sample from sitepoint.com on
implemening the ArrayAccess interface, I get some unrelated error.
Maybe it's a documentation bug again...
Reproduce code:
---
title = $title;
}
function offsetSet($key, $value){
$this->{$key} = &$value;
}
function offsetGet($key){
return $this->{$key};
}
function offsetUnset($key){
unset($this->{$key});
}
function offsetExists($offset) {
return array_key_exists($offset,get_object_vars($this));
}
}
// Create the object
$A = new Article('SPL Rocks');
// Change the title using array syntax using reference
$str = 'SPL _really_ rocks';
$A['title'] =&$str;
// Check what it looks like again
print_r($A);
?>
Expected result:
Article Object
(
[title] => SPL _really_ rocks
)
Actual result:
--
Fatal error: Objects used as arrays in post/pre increment/decrement
must return values by reference in test.php on line 27
There was no increment/decrement operations used.
It would be _much_ better if it would be allowed to write
function offsetSet($key, &$value){...}
--
Edit this bug report at http://bugs.php.net/?id=38118&edit=1
#38121 [Bgs->Opn]: class is considered not defined before it is declared
ID: 38121 User updated by: public at grik dot net Reported By: public at grik dot net -Status: Bogus +Status: Open -Bug Type: SPL related +Bug Type: Feature/Change Request Operating System: * PHP Version: 5.1.4 New Comment: Thank you! "It's not a bug - it's a feature" :-) Actually, it is a documentation issue and I'll comment it. May I convert it to a feature request? Previous Comments: [2006-07-17 07:57:27] [EMAIL PROTECTED] It doesn't depend on SPL, that happens with all interfaces and it's expected. [2006-07-17 07:05:19] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php . -------- [2006-07-17 01:36:33] public at grik dot net Description: I am not sure already what is it related to, but it's getting interesting :) The engine does not recognise the class that implements the ArrayAccess interface as declared in the code written before the class declaration is placed. Reproduce code: --- Expected result: bool(true) bool(true) Actual result: -- bool(false) bool(true) -- Edit this bug report at http://bugs.php.net/?id=38121&edit=1
#38121 [NEW]: class is considered not defined before it is declared
From: public at grik dot net Operating system: * PHP version: 5.1.4 PHP Bug Type: SPL related Bug description: class is considered not defined before it is declared Description: I am not sure already what is it related to, but it's getting interesting :) The engine does not recognise the class that implements the ArrayAccess interface as declared in the code written before the class declaration is placed. Reproduce code: --- Expected result: bool(true) bool(true) Actual result: -- bool(false) bool(true) -- Edit bug report at http://bugs.php.net/?id=38121&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38121&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38121&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38121&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38121&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38121&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38121&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38121&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38121&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38121&r=support Expected behavior:http://bugs.php.net/fix.php?id=38121&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38121&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38121&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38121&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38121&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38121&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38121&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38121&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38121&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38121&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38121&r=mysqlcfg
#38118 [Bgs->Opn]: unrelated error when using reference
ID: 38118
User updated by: public at grik dot net
Reported By: public at grik dot net
-Status: Bogus
+Status: Open
-Bug Type: Scripting Engine problem
+Bug Type: Feature/Change Request
Operating System: *
PHP Version: 5.1.4
New Comment:
Thank you.
The problem of using reference in ArrayAccess class is pure practical.
I have a set of rules and data fields - each field should be checked
against it's rule (e.g. min, max).
I write the hierarchy of classes implementing the exact logic for each
rule. The class instance should get the set of rule parameters and the
data reference.
Then I interate over the management object (extends ArrayObject) with
foreach and get the checking object as a value.
As result, I can make the rules to check the data regardless of it's
type and source - scalar, array, resource. All I need is to write
another class with the check logic.
The data may be large, and inability to use references may lead either
to
- memory overconsumption
- DDOS-insecure issue
- having to refuse from abstration and write more code
Previous Comments:
[2006-07-16 23:55:43] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
The '&' is because of inhereitance rules.
The second thing you encounter, the '&=' is an engine limitation.
Btw, both are pure engine issues, nothing todo with SPL.
Maybe you want this reopened as feature request. But then i suggest you
provide at least some ideas where and how to document that ArayAccess
cannot be used in modifying operators like '&='.
Either way you should try 5.2/HEAD first as we've put some work to get
you a better error message.
--------------------
[2006-07-16 23:43:09] public at grik dot net
P.S.
I am not allowed to define function offsetGet($key)as
"function &offsetGet($key){...}"
to return the value by reference due to the requirements of the
ArrayAccess interface.
----------------
[2006-07-16 23:37:34] public at grik dot net
Description:
Slightly modifying a Harry Fuecks's sample from sitepoint.com on
implemening the ArrayAccess interface, I get some unrelated error.
Maybe it's a documentation bug again...
Reproduce code:
---
title = $title;
}
function offsetSet($key, $value){
$this->{$key} = &$value;
}
function offsetGet($key){
return $this->{$key};
}
function offsetUnset($key){
unset($this->{$key});
}
function offsetExists($offset) {
return array_key_exists($offset,get_object_vars($this));
}
}
// Create the object
$A = new Article('SPL Rocks');
// Change the title using array syntax using reference
$str = 'SPL _really_ rocks';
$A['title'] =&$str;
// Check what it looks like again
print_r($A);
?>
Expected result:
Article Object
(
[title] => SPL _really_ rocks
)
Actual result:
--
Fatal error: Objects used as arrays in post/pre increment/decrement
must return values by reference in test.php on line 27
There was no increment/decrement operations used.
It would be _much_ better if it would be allowed to write
function offsetSet($key, &$value){...}
--
Edit this bug report at http://bugs.php.net/?id=38118&edit=1
#38118 [NEW]: unrelated error when using reference
From: public at grik dot net
Operating system: *
PHP version: 5.1.4
PHP Bug Type: SPL related
Bug description: unrelated error when using reference
Description:
Slightly modifying a Harry Fuecks's sample from sitepoint.com on
implemening the ArrayAccess interface, I get some unrelated error.
Maybe it's a documentation bug again...
Reproduce code:
---
title = $title;
}
function offsetSet($key, $value){
$this->{$key} = &$value;
}
function offsetGet($key){
return $this->{$key};
}
function offsetUnset($key){
unset($this->{$key});
}
function offsetExists($offset) {
return array_key_exists($offset,get_object_vars($this));
}
}
// Create the object
$A = new Article('SPL Rocks');
// Change the title using array syntax using reference
$str = 'SPL _really_ rocks';
$A['title'] =&$str;
// Check what it looks like again
print_r($A);
?>
Expected result:
Article Object
(
[title] => SPL _really_ rocks
)
Actual result:
--
Fatal error: Objects used as arrays in post/pre increment/decrement must
return values by reference in test.php on line 27
There was no increment/decrement operations used.
It would be _much_ better if it would be allowed to write
function offsetSet($key, &$value){...}
--
Edit bug report at http://bugs.php.net/?id=38118&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38118&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38118&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38118&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38118&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38118&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38118&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38118&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38118&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38118&r=support
Expected behavior:http://bugs.php.net/fix.php?id=38118&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38118&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38118&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38118&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38118&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38118&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38118&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38118&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38118&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38118&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38118&r=mysqlcfg
#38118 [Opn]: unrelated error when using reference
ID: 38118
User updated by: public at grik dot net
Reported By: public at grik dot net
Status: Open
Bug Type: SPL related
Operating System: *
PHP Version: 5.1.4
New Comment:
P.S.
I am not allowed to define function offsetGet($key)as
"function &offsetGet($key){...}"
to return the value by reference due to the requirements of the
ArrayAccess interface.
Previous Comments:
[2006-07-16 23:37:34] public at grik dot net
Description:
Slightly modifying a Harry Fuecks's sample from sitepoint.com on
implemening the ArrayAccess interface, I get some unrelated error.
Maybe it's a documentation bug again...
Reproduce code:
---
title = $title;
}
function offsetSet($key, $value){
$this->{$key} = &$value;
}
function offsetGet($key){
return $this->{$key};
}
function offsetUnset($key){
unset($this->{$key});
}
function offsetExists($offset) {
return array_key_exists($offset,get_object_vars($this));
}
}
// Create the object
$A = new Article('SPL Rocks');
// Change the title using array syntax using reference
$str = 'SPL _really_ rocks';
$A['title'] =&$str;
// Check what it looks like again
print_r($A);
?>
Expected result:
Article Object
(
[title] => SPL _really_ rocks
)
Actual result:
--
Fatal error: Objects used as arrays in post/pre increment/decrement
must return values by reference in test.php on line 27
There was no increment/decrement operations used.
It would be _much_ better if it would be allowed to write
function offsetSet($key, &$value){...}
--
Edit this bug report at http://bugs.php.net/?id=38118&edit=1
#38109 [Bgs]: visibility of property is processed incorrectly
ID: 38109
User updated by: public at grik dot net
Reported By: public at grik dot net
Status: Bogus
Bug Type: SPL related
Operating System: *
PHP Version: *
Assigned To: helly
New Comment:
Thanks, then it's a documentation bug.
In the documentation there is no mention that it is about _not_visible_
properties only.
http://www.php.net/~helly/php/ext/spl/classArrayObject.html#f4077c9cb0ca99a6fc4d5da841443224
"Array indices can be accessed as properties in read/write."
Previous Comments:
[2006-07-15 09:42:39] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
The ",2" in the constructor call means
ArrayObject::SPL_ARRAY_ARRAY_AS_PROPS which means use the array as
properties if there is no conflict with visible properties. That is in
case A) the property len is visible outside hence the property can be
used. In case B) the property len is not used so that the array is
being used instead. You will see an interesting behavior if you provide
a class method in case B that dumps the contents.
----
[2006-07-15 02:50:13] public at grik dot net
Description:
When I declare a property as "public", it's being ignored.
When I declare it as protected or private it is processed and visible
from outside of the object.
Reproduce code:
---
A)
class Rules extends ArrayObject {
public $len;
function __construct($array){
parent::__construct($array,2);
$this['len'] = 2;
}
}
$x = new Rules(array(1,2));
var_dump($x->len);
B)
class Rules extends ArrayObject {
protected $len;
function __construct($array){
parent::__construct($array,2);
$this['len'] = 2;
}
}
$x = new Rules(array(1,2));
var_dump($x->len);
Expected result:
A) int(2)
B) Fatal error: Cannot access protected property Rules::$len
Actual result:
--
A) NULL
B) int(2)
--
Edit this bug report at http://bugs.php.net/?id=38109&edit=1
#38109 [NEW]: visibility of property is processed incorrectly
From: public at grik dot net
Operating system: Linux, Windows
PHP version: 5.1.4
PHP Bug Type: SPL related
Bug description: visibility of property is processed incorrectly
Description:
When I declare a property as "public", it's being ignored.
When I declare it as protected or private it is processed and visible from
outside of the object.
Reproduce code:
---
A)
class Rules extends ArrayObject {
public $len;
function __construct($array){
parent::__construct($array,2);
$this['len'] = 2;
}
}
$x = new Rules(array(1,2));
var_dump($x->len);
B)
class Rules extends ArrayObject {
protected $len;
function __construct($array){
parent::__construct($array,2);
$this['len'] = 2;
}
}
$x = new Rules(array(1,2));
var_dump($x->len);
Expected result:
A) int(2)
B) Fatal error: Cannot access protected property Rules::$len
Actual result:
--
A) NULL
B) int(2)
--
Edit bug report at http://bugs.php.net/?id=38109&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38109&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38109&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38109&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38109&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38109&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38109&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38109&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38109&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38109&r=support
Expected behavior:http://bugs.php.net/fix.php?id=38109&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38109&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38109&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38109&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38109&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38109&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38109&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38109&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38109&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38109&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38109&r=mysqlcfg
#33222 [Fbk->Opn]: segmentation fault when trying to run curl_close from the handler function
ID: 33222 User updated by: public at grik dot net Reported By: public at grik dot net -Status: Feedback +Status: Open Bug Type: cURL related Operating System: Linux RH9 PHP Version: 5.0.4 New Comment: Segmentation fault persists curl_version(): Array ( [version_number] => 462336 [age] => 2 [features] => 540 [ssl_version_number] => 0 [version] => 7.14.0 [host] => i686-pc-linux-gnu [ssl_version] => OpenSSL/0.9.7a [libz_version] => 1.1.4 [protocols] => Array ( [0] => ftp [1] => gopher [2] => telnet [3] => dict [4] => ldap [5] => http [6] => file [7] => https [8] => ftps ) ) Previous Comments: [2005-06-02 18:45:03] [EMAIL PROTECTED] Ok, waiting for you to provide info. ---------------- [2005-06-02 18:40:53] public at grik dot net CURL Informationlibcurl/7.12.0 it's not old, I upgraded it not so long ago, and manual says PHP5 requires 7.10.5 trying to upgrade to CURL 7.14 [2005-06-02 18:07:19] [EMAIL PROTECTED] What is the version of cURL used? What if you try to upgrade it to the latest available from http://curl.haxx.se/download.html ? ---------------- [2005-06-02 17:20:47] public at grik dot net Program received signal SIGSEGV, Segmentation fault. 0x403a9d84 in Curl_readwrite (conn=0x81f584c, done=0xbfffc39f "") at transfer.c:890 890 } -------------------- [2005-06-02 17:17:18] public at grik dot net backtrace: (gdb) bt #0 0x403a9d84 in Curl_readwrite (conn=0x81f584c, done=0xbfffc39f "") at transfer.c:890 #1 0x403aaf56 in Transfer (conn=0x81f584c) at transfer.c:1480 #2 0x403ab94a in Curl_perform (data=0x81f7b7c) at transfer.c:1985 #3 0x403ac175 in curl_easy_perform (curl=0x81f7b7c) at easy.c:378 #4 0x4002c3d2 in zif_curl_exec (ht=1, return_value=0x81f55dc, this_ptr=0x0, return_value_used=0) at /usr/src/web/php5-STABLE-200505161036/ext/curl/interface.c:1261 #5 0x0814a267 in zend_do_fcall_common_helper (execute_data=0xbfffc610, opline=0x81f5068, op_array=0x81f09a4) at /usr/src/web/php5-STABLE-200505161036/Zend/zend_execute.c:2747 #6 0x0814a8c8 in zend_do_fcall_handler (execute_data=0xbfffc610, opline=0x81f5068, op_array=0x81f09a4) at /usr/src/web/php5-STABLE-200505161036/Zend/zend_execute.c:2881 #7 0x08147188 in execute (op_array=0x81f09a4) at /usr/src/web/php5-STABLE-200505161036/Zend/zend_execute.c:1417 #8 0x081239fe in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/web/php5-STABLE-200505161036/Zend/zend.c:1080 #9 0x080e5323 in php_execute_script (primary_file=0xbfffe9e0) at /usr/src/web/php5-STABLE-200505161036/main/main.c:1646 #10 0x08153187 in main (argc=4, argv=0xbfffea84) at /usr/src/web/php5-STABLE-200505161036/sapi/cgi/cgi_main.c:1582 #11 0x42015574 in __libc_start_main () from /lib/tls/libc.so.6 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/33222 -- Edit this bug report at http://bugs.php.net/?id=33222&edit=1
#33222 [Fbk->Opn]: segmentation fault when trying to run curl_close from the handler function
ID: 33222
User updated by: public at grik dot net
Reported By: public at grik dot net
-Status: Feedback
+Status: Open
Bug Type: cURL related
Operating System: Linux RH9
PHP Version: 5.0.4
New Comment:
CURL Informationlibcurl/7.12.0
it's not old, I upgraded it not so long ago, and manual says PHP5
requires 7.10.5
trying to upgrade to CURL 7.14
Previous Comments:
[2005-06-02 18:07:19] [EMAIL PROTECTED]
What is the version of cURL used?
What if you try to upgrade it to the latest available from
http://curl.haxx.se/download.html ?
[2005-06-02 17:20:47] public at grik dot net
Program received signal SIGSEGV, Segmentation fault.
0x403a9d84 in Curl_readwrite (conn=0x81f584c, done=0xbfffc39f "")
at transfer.c:890
890 }
[2005-06-02 17:17:18] public at grik dot net
backtrace:
(gdb) bt
#0 0x403a9d84 in Curl_readwrite (conn=0x81f584c, done=0xbfffc39f "")
at transfer.c:890
#1 0x403aaf56 in Transfer (conn=0x81f584c) at transfer.c:1480
#2 0x403ab94a in Curl_perform (data=0x81f7b7c) at transfer.c:1985
#3 0x403ac175 in curl_easy_perform (curl=0x81f7b7c) at easy.c:378
#4 0x4002c3d2 in zif_curl_exec (ht=1, return_value=0x81f55dc,
this_ptr=0x0,
return_value_used=0)
at /usr/src/web/php5-STABLE-200505161036/ext/curl/interface.c:1261
#5 0x0814a267 in zend_do_fcall_common_helper
(execute_data=0xbfffc610,
opline=0x81f5068, op_array=0x81f09a4)
at /usr/src/web/php5-STABLE-200505161036/Zend/zend_execute.c:2747
#6 0x0814a8c8 in zend_do_fcall_handler (execute_data=0xbfffc610,
opline=0x81f5068, op_array=0x81f09a4)
at /usr/src/web/php5-STABLE-200505161036/Zend/zend_execute.c:2881
#7 0x08147188 in execute (op_array=0x81f09a4)
at /usr/src/web/php5-STABLE-200505161036/Zend/zend_execute.c:1417
#8 0x081239fe in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /usr/src/web/php5-STABLE-200505161036/Zend/zend.c:1080
#9 0x080e5323 in php_execute_script (primary_file=0xbfffe9e0)
at /usr/src/web/php5-STABLE-200505161036/main/main.c:1646
#10 0x08153187 in main (argc=4, argv=0xbfffea84)
at /usr/src/web/php5-STABLE-200505161036/sapi/cgi/cgi_main.c:1582
#11 0x42015574 in __libc_start_main () from /lib/tls/libc.so.6
----
[2005-06-02 16:55:14] public at grik dot net
Description:
When I try to close CURL connection from the function, registered as a
handler for the output (header or body), PHP crashes.
Reproduce code:
---
http://www.yahoo.com/";);
curl_setopt($ch, CURLOPT_HEADERFUNCTION, 'header_callback');
curl_exec($ch);
curl_close($ch);
function header_callback($ch, $string){
echo $string;
curl_close($ch);
return strlen($string);
}
?>
Expected result:
HTTP/1.1 200 OK
Actual result:
--
HTTP/1.1 200 OK
Segmentation fault
--
Edit this bug report at http://bugs.php.net/?id=33222&edit=1
#33222 [Opn]: segmentation fault when trying to run curl_close from the handler function
ID: 33222
User updated by: public at grik dot net
Reported By: public at grik dot net
Status: Open
Bug Type: cURL related
Operating System: Linux RH9
PHP Version: 5.0.4
New Comment:
Program received signal SIGSEGV, Segmentation fault.
0x403a9d84 in Curl_readwrite (conn=0x81f584c, done=0xbfffc39f "")
at transfer.c:890
890 }
Previous Comments:
[2005-06-02 17:17:18] public at grik dot net
backtrace:
(gdb) bt
#0 0x403a9d84 in Curl_readwrite (conn=0x81f584c, done=0xbfffc39f "")
at transfer.c:890
#1 0x403aaf56 in Transfer (conn=0x81f584c) at transfer.c:1480
#2 0x403ab94a in Curl_perform (data=0x81f7b7c) at transfer.c:1985
#3 0x403ac175 in curl_easy_perform (curl=0x81f7b7c) at easy.c:378
#4 0x4002c3d2 in zif_curl_exec (ht=1, return_value=0x81f55dc,
this_ptr=0x0,
return_value_used=0)
at /usr/src/web/php5-STABLE-200505161036/ext/curl/interface.c:1261
#5 0x0814a267 in zend_do_fcall_common_helper
(execute_data=0xbfffc610,
opline=0x81f5068, op_array=0x81f09a4)
at /usr/src/web/php5-STABLE-200505161036/Zend/zend_execute.c:2747
#6 0x0814a8c8 in zend_do_fcall_handler (execute_data=0xbfffc610,
opline=0x81f5068, op_array=0x81f09a4)
at /usr/src/web/php5-STABLE-200505161036/Zend/zend_execute.c:2881
#7 0x08147188 in execute (op_array=0x81f09a4)
at /usr/src/web/php5-STABLE-200505161036/Zend/zend_execute.c:1417
#8 0x081239fe in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /usr/src/web/php5-STABLE-200505161036/Zend/zend.c:1080
#9 0x080e5323 in php_execute_script (primary_file=0xbfffe9e0)
at /usr/src/web/php5-STABLE-200505161036/main/main.c:1646
#10 0x08153187 in main (argc=4, argv=0xbfffea84)
at /usr/src/web/php5-STABLE-200505161036/sapi/cgi/cgi_main.c:1582
#11 0x42015574 in __libc_start_main () from /lib/tls/libc.so.6
[2005-06-02 16:55:14] public at grik dot net
Description:
When I try to close CURL connection from the function, registered as a
handler for the output (header or body), PHP crashes.
Reproduce code:
---
http://www.yahoo.com/";);
curl_setopt($ch, CURLOPT_HEADERFUNCTION, 'header_callback');
curl_exec($ch);
curl_close($ch);
function header_callback($ch, $string){
echo $string;
curl_close($ch);
return strlen($string);
}
?>
Expected result:
HTTP/1.1 200 OK
Actual result:
--
HTTP/1.1 200 OK
Segmentation fault
--
Edit this bug report at http://bugs.php.net/?id=33222&edit=1
#33222 [NEW]: segmentation fault when trying to run curl_close from the handler function
From: public at grik dot net
Operating system: Linux RH9
PHP version: 5.0.4
PHP Bug Type: cURL related
Bug description: segmentation fault when trying to run curl_close from the
handler function
Description:
When I try to close CURL connection from the function, registered as a
handler for the output (header or body), PHP crashes.
Reproduce code:
---
http://www.yahoo.com/";);
curl_setopt($ch, CURLOPT_HEADERFUNCTION, 'header_callback');
curl_exec($ch);
curl_close($ch);
function header_callback($ch, $string){
echo $string;
curl_close($ch);
return strlen($string);
}
?>
Expected result:
HTTP/1.1 200 OK
Actual result:
--
HTTP/1.1 200 OK
Segmentation fault
--
Edit bug report at http://bugs.php.net/?id=33222&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33222&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33222&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33222&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33222&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33222&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33222&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33222&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33222&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33222&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33222&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33222&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33222&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33222&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33222&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33222&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33222&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33222&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33222&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33222&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33222&r=mysqlcfg
#33222 [Opn]: segmentation fault when trying to run curl_close from the handler function
ID: 33222
User updated by: public at grik dot net
Reported By: public at grik dot net
Status: Open
Bug Type: cURL related
Operating System: Linux RH9
PHP Version: 5.0.4
New Comment:
backtrace:
(gdb) bt
#0 0x403a9d84 in Curl_readwrite (conn=0x81f584c, done=0xbfffc39f "")
at transfer.c:890
#1 0x403aaf56 in Transfer (conn=0x81f584c) at transfer.c:1480
#2 0x403ab94a in Curl_perform (data=0x81f7b7c) at transfer.c:1985
#3 0x403ac175 in curl_easy_perform (curl=0x81f7b7c) at easy.c:378
#4 0x4002c3d2 in zif_curl_exec (ht=1, return_value=0x81f55dc,
this_ptr=0x0,
return_value_used=0)
at /usr/src/web/php5-STABLE-200505161036/ext/curl/interface.c:1261
#5 0x0814a267 in zend_do_fcall_common_helper
(execute_data=0xbfffc610,
opline=0x81f5068, op_array=0x81f09a4)
at /usr/src/web/php5-STABLE-200505161036/Zend/zend_execute.c:2747
#6 0x0814a8c8 in zend_do_fcall_handler (execute_data=0xbfffc610,
opline=0x81f5068, op_array=0x81f09a4)
at /usr/src/web/php5-STABLE-200505161036/Zend/zend_execute.c:2881
#7 0x08147188 in execute (op_array=0x81f09a4)
at /usr/src/web/php5-STABLE-200505161036/Zend/zend_execute.c:1417
#8 0x081239fe in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /usr/src/web/php5-STABLE-200505161036/Zend/zend.c:1080
#9 0x080e5323 in php_execute_script (primary_file=0xbfffe9e0)
at /usr/src/web/php5-STABLE-200505161036/main/main.c:1646
#10 0x08153187 in main (argc=4, argv=0xbfffea84)
at /usr/src/web/php5-STABLE-200505161036/sapi/cgi/cgi_main.c:1582
#11 0x42015574 in __libc_start_main () from /lib/tls/libc.so.6
Previous Comments:
[2005-06-02 16:55:14] public at grik dot net
Description:
When I try to close CURL connection from the function, registered as a
handler for the output (header or body), PHP crashes.
Reproduce code:
---
http://www.yahoo.com/";);
curl_setopt($ch, CURLOPT_HEADERFUNCTION, 'header_callback');
curl_exec($ch);
curl_close($ch);
function header_callback($ch, $string){
echo $string;
curl_close($ch);
return strlen($string);
}
?>
Expected result:
HTTP/1.1 200 OK
Actual result:
--
HTTP/1.1 200 OK
Segmentation fault
--
Edit this bug report at http://bugs.php.net/?id=33222&edit=1
#29886 [NoF->Csd]: segment fault when processing curl output with "wrapper-registered" stream
ID: 29886 User updated by: public at grik dot net Reported By: public at grik dot net -Status: No Feedback +Status: Closed Bug Type: cURL related -Operating System: Linux +Operating System: Linux (not FreeBSD) PHP Version: 5CVS-2004-08-30 (dev) New Comment: I found out that the bug was in the PHP stream wrapper - the segmentation fault arized on Linux platform. That bug was recently fixed (thanx, Tony): http://bugs.php.net/?id=32742 Previous Comments: [2005-05-18 16:08:05] joel at joelstrellner dot com I am having the exact same problem in version 5.0.4. I have narrowed it down to curl, but I can't narrow it down any further. I tried using CURLOPT_BUFFERSIZE to overcome it but I am not sure that it is even working. I am pretty sure that it has to do with curl_multi_init and the related multi functions. The exact same code using one connection at a time does not cause an error of any kind. the options I am giving it are: $conn[$i] = curl_init($url); curl_setopt ($conn[$i], CURLOPT_BUFFERSIZE, 8192000); curl_setopt ($conn[$i], CURLOPT_RETURNTRANSFER, 1); curl_setopt ($conn[$i], CURLOPT_URL, "$url"); curl_setopt ($conn[$i], CURLOPT_USERAGENT, $user_agent); if (($referer!=NULL) AND ($referer!='')) curl_setopt ($conn[$i], CURLOPT_REFERER, $referer); curl_setopt ($conn[$i], CURLOPT_CONNECTTIMEOUT, $connecttimeout); curl_setopt ($conn[$i], CURLOPT_TIMEOUT, $timeout); curl_setopt ($conn[$i], CURLOPT_HEADER, 0); curl_setopt ($conn[$i], CURLOPT_FOLLOWLOCATION, 1); curl_setopt ($conn[$i], CURLOPT_MAXREDIRS, 3); curl_setopt ($conn[$i], CURLOPT_FAILONERROR, 1); curl_setopt ($conn[$i], CURLOPT_ENCODING, ''); curl_setopt ($conn[$i], CURLOPT_COOKIEJAR,"cookie.txt"); curl_setopt ($conn[$i], CURLOPT_COOKIEFILE,"cookie.txt"); curl_setopt ($conn[$i], CURLOPT_FOLLOWLOCATION,TRUE); curl_setopt ($conn[$i], CURLOPT_SSL_VERIFYPEER, FALSE); curl_setopt ($conn[$i], CURLOPT_SSL_VERIFYHOST, 1); curl_multi_add_handle ($mh,$conn[$i]); the error I am getting is a seg fault (11) then the script stops executing. [2005-03-16 01:00:07] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2005-03-08 10:44:17] [EMAIL PROTECTED] Set to feedback until real feedback has been provided. -------------------- [2005-03-08 09:35:39] public at grik dot net Thank you, I'll try with the new version today. [2005-03-07 21:33:34] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip I can't get it to crash.. 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/29886 -- Edit this bug report at http://bugs.php.net/?id=29886&edit=1
#32742 [Fbk->Opn]: segmentation fault when the stream with a wrapper is not closed (Linux RH only)
ID: 32742
User updated by: public at grik dot net
Reported By: public at grik dot net
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: Linux (RH7,RH9,Gentoo)
PHP Version: 5.0.4
Assigned To: tony2001
New Comment:
The segmentation fault is gone.
Tony, I owe you :-)
Previous Comments:
[2005-05-16 10:50:40] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
[2005-05-11 16:42:26] [EMAIL PROTECTED]
Reassigned to myself, patch pending..
[2005-04-18 16:39:36] [EMAIL PROTECTED]
Sara, you seem to be patching streams hard these days, please take a
look at it.
Looks like there is some memory corruption (but valgrind complains only
about invalid reads and tells nothing about invalid writes).
[2005-04-18 16:35:53] [EMAIL PROTECTED]
Here is the backtrace (pay attention to the last line):
(gdb) bt
#0 0x0018 in ?? ()
#1 0x0817f8a6 in _php_stream_free (stream=0x82b8cb4, close_options=11)
at /usr/src/dev/clean/php-src_5_0/main/streams/streams.c:351
#2 0x081814d8 in stream_resource_regular_dtor (rsrc=0x82b8d40) at
/usr/src/dev/clean/php-src_5_0/main/streams/streams.c:1361
#3 0x081b6e2f in list_entry_destructor (ptr=0x82b8d40) at
/usr/src/dev/clean/php-src_5_0/Zend/zend_list.c:178
#4 0x081b517a in zend_hash_del_key_or_index (ht=0x82372fc, arKey=0x0,
nKeyLength=0, h=6, flag=1) at
/usr/src/dev/clean/php-src_5_0/Zend/zend_hash.c:490
#5 0x081b6b8d in _zend_list_delete (id=6) at
/usr/src/dev/clean/php-src_5_0/Zend/zend_list.c:58
#6 0x081acff6 in _zval_dtor (zvalue=0x82b8998,
__zend_filename=0x8216844
"/usr/src/dev/clean/php-src_5_0/Zend/zend_execute_API.c",
__zend_lineno=392)
at /usr/src/dev/clean/php-src_5_0/Zend/zend_variables.c:69
#7 0x081a2d23 in _zval_ptr_dtor (zval_ptr=0x82b8bfc,
__zend_filename=0x8217570
"/usr/src/dev/clean/php-src_5_0/Zend/zend_variables.c",
__zend_lineno=193)
at /usr/src/dev/clean/php-src_5_0/Zend/zend_execute_API.c:392
#8 0x081ad275 in _zval_ptr_dtor_wrapper (zval_ptr=0x82b8bfc) at
/usr/src/dev/clean/php-src_5_0/Zend/zend_variables.c:193
#9 0x081b53b5 in zend_hash_apply_deleter (ht=0x82371d0, p=0x82b8bf0)
at /usr/src/dev/clean/php-src_5_0/Zend/zend_hash.c:574
#10 0x081b555f in zend_hash_graceful_reverse_destroy (ht=0x82371d0) at
/usr/src/dev/clean/php-src_5_0/Zend/zend_hash.c:640
#11 0x081a26ab in shutdown_executor () at
/usr/src/dev/clean/php-src_5_0/Zend/zend_execute_API.c:208
#12 0x081ae443 in zend_deactivate () at
/usr/src/dev/clean/php-src_5_0/Zend/zend.c:817
#13 0x081700a7 in php_request_shutdown (dummy=0x0) at
/usr/src/dev/clean/php-src_5_0/main/main.c:1214
#14 0x081dc2f6 in main (argc=2, argv=0xb154) at
/usr/src/dev/clean/php-src_5_0/sapi/cli/php_cli.c:1049
(gdb) f 1
#1 0x0817f8a6 in _php_stream_free (stream=0x82b8cb4, close_options=11)
at /usr/src/dev/clean/php-src_5_0/main/streams/streams.c:351
351
stream->wrapper->wops->stream_closer(stream->wrapper, stream
TSRMLS_CC);
(gdb) p *stream.wrapper.wops
$1 = {stream_opener = 0x4480, stream_closer = 0x18, stream_stat =
0x82a67b0, url_stat = 0, dir_opener = 0x1, label = 0x0, unlink = 0,
rename = 0x31,
stream_mkdir = 0x82a67c8, stream_rmdir = 0x2}
----
[2005-04-18 14:44:29] public at grik dot net
Description:
There is a problem with stream_wrapper_register() that appears on Linux
and not on the FreeBSD.
I open a stream with the registered wrapper and assing a handler to the
resource variable.
If a variable stays alive when the execution of the script reaches the
end, PHP gives the segmentation fault.
Attempt to close the resource from an object destructor does not help.
Platforms tested: 5 servers with Red Hat 7, 9 and gentoo 5.03 (kernels
2.4, 2.6, 2.6 hardened), PHP 5.03, 5.04, 4.3.7
In FreeBSD 5.3 there is no problem executing the script.
Reproduce code:
---
Expected result:
time with microseconds
Actual result:
--
When run from the command line - time with microseconds and words
"Segmentation fault",
when called from browser - no output.
--
Edit this bug report at http://bugs.php.net/?id=32742&edit=1
#32742 [Opn]: segmentation fault when the stream with a wrapper is not closed (Linux RH only)
ID: 32742
User updated by: public at grik dot net
Reported By: public at grik dot net
Status: Open
Bug Type: Reproducible crash
Operating System: Linux (RH7,RH9,Gentoo)
PHP Version: 5.0.4
New Comment:
The "reproduce code" disappeared (it was in the form, I checked). Here
it is:
class Wrapper{
function stream_open($path, $path, $options, &$opened_path){return
true;}
}
stream_wrapper_register("wr", 'Wrapper')
or die("Failed to register protocol");
$fp = fopen ('wr://example', 'w');
//fclose ($fp);
echo microtime();
Previous Comments:
----------------
[2005-04-18 14:44:29] public at grik dot net
Description:
There is a problem with stream_wrapper_register() that appears on Linux
and not on the FreeBSD.
I open a stream with the registered wrapper and assing a handler to the
resource variable.
If a variable stays alive when the execution of the script reaches the
end, PHP gives the segmentation fault.
Attempt to close the resource from an object destructor does not help.
Platforms tested: 5 servers with Red Hat 7, 9 and gentoo 5.03 (kernels
2.4, 2.6, 2.6 hardened), PHP 5.03, 5.04, 4.3.7
In FreeBSD 5.3 there is no problem executing the script.
Reproduce code:
---
Expected result:
time with microseconds
Actual result:
--
When run from the command line - time with microseconds and words
"Segmentation fault",
when called from browser - no output.
--
Edit this bug report at http://bugs.php.net/?id=32742&edit=1
#32742 [NEW]: segmentation fault when the stream with a wrapper is not closed (Linux RH only)
From: public at grik dot net Operating system: Linux (RH7,RH9,Gentoo) PHP version: 5.0.4 PHP Bug Type: Reproducible crash Bug description: segmentation fault when the stream with a wrapper is not closed (Linux RH only) Description: There is a problem with stream_wrapper_register() that appears on Linux and not on the FreeBSD. I open a stream with the registered wrapper and assing a handler to the resource variable. If a variable stays alive when the execution of the script reaches the end, PHP gives the segmentation fault. Attempt to close the resource from an object destructor does not help. Platforms tested: 5 servers with Red Hat 7, 9 and gentoo 5.03 (kernels 2.4, 2.6, 2.6 hardened), PHP 5.03, 5.04, 4.3.7 In FreeBSD 5.3 there is no problem executing the script. Reproduce code: --- Expected result: time with microseconds Actual result: -- When run from the command line - time with microseconds and words "Segmentation fault", when called from browser - no output. -- Edit bug report at http://bugs.php.net/?id=32742&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32742&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32742&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32742&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32742&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32742&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32742&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32742&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32742&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32742&r=support Expected behavior: http://bugs.php.net/fix.php?id=32742&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32742&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32742&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32742&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32742&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32742&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32742&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32742&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32742&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32742&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32742&r=mysqlcfg
#29886 [Fbk->Opn]: segment fault when processing curl output with "wrapper-registered" stream
ID: 29886 User updated by: public at grik dot net Reported By: public at grik dot net -Status: Feedback +Status: Open Bug Type: cURL related Operating System: Linux PHP Version: 5CVS-2004-08-30 (dev) New Comment: Thank you, I'll try with the new version today. Previous Comments: [2005-03-07 21:33:34] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip I can't get it to crash.. [2004-08-30 02:08:19] public at grik dot net Description: I register a wrapper, create a stream and pass the pointer to the curl_setopt to process CURL output. When amount of data returned by CURL exeeds 8192 bytes (size of the CURL buffer), PHP ends with Segmentation fault. I could not reach the crash using fwrite(). Similar problem was in PHP 4.3.3, in 4.3.7 everything works fine. I detected this problem again in 5.0.0 and replicated it in the latest stable CSV. I do not know if it happens upon shutdown and if it is relevant to bug #29358. This happens with CURL only. Reproduce code: --- The sample code can be found at: http://www.grik.net/sample.phps Can be run form command line: php -f sample.php Expected result: In PHP 4.3.7 this script would output the amount of bytes obtained from CURL: 8192 8192 ... Actual result: -- In PHP 5.0.0: 8192 8192 Segmentation fault Backtrace (I am not enough good with gdb, could not locate): (gdb) bt #0 0x081f714a in _zval_copy_ctor (zvalue=0x8344684, __zend_filename=0x8273780 "/usr/src/web/php5-STABLE-200408292230/Zend/zend_execute.c", __zend_lineno=3001) at /usr/src/web/php5-STABLE-200408292230/Zend/zend_variables.c:136 #1 0x08227ab6 in zend_send_by_var_helper (execute_data=0xbfffb210, opline=0x8349e38, op_array=0x834b0e4) at /usr/src/web/php5-STABLE-200408292230/Zend/zend_execute.c:3001 #2 0x08221824 in zend_send_var_handler (execute_data=0xbfffb210, opline=0x8349e38, op_array=0x834b0e4) at /usr/src/web/php5-STABLE-200408292230/Zend/zend_execute.c:3061 #3 0x0821cb76 in execute (op_array=0x834b0e4) at /usr/src/web/php5-STABLE-200408292230/Zend/zend_execute.c:1400 #4 0x081ed157 in zend_call_function (fci=0xbfffb370, fci_cache=0x0) at /usr/src/web/php5-STABLE-200408292230/Zend/zend_execute_API.c:835 #5 0x081ec1a9 in call_user_function_ex (function_table=0x0, object_pp=0x82e5f00, function_name=0xbfffb400, retval_ptr_ptr=0xbfffb3fc, param_count=1, params=0xbfffb3f0, no_separation=0, symbol_table=0x0) at /usr/src/web/php5-STABLE-200408292230/Zend/zend_execute_API.c:550 #6 0x081cd58c in php_userstreamop_write (stream=0x83446c4, buf=0x4003 "\n\n\n PHP: Hypertext Preprocessor\n http://static.php.net/www.php.net/style.css\"; />\n"..., count=8192) at /usr/src/web/php5-STABLE-200408292230/main/streams/userspace.c:459 #7 0x081c539d in _php_stream_write_buffer (stream=0x83446c4, buf=0x4003 "\n\n\n PHP: Hypertext Preprocessor\n http://static.php.net/www.php.net/style.css\"; />\n"..., count=8192) at /usr/src/web/php5-STABLE-200408292230/main/streams/streams.c:889 #8 0x081c561f in _php_stream_write (stream=0x83446c4, buf=0x4003 "\n\n\n PHP: Hypertext Preprocessor\n http://static.php.net/www.php.net/style.css\"; />\n"..., count=8192) at /usr/src/web/php5-STABLE-200408292230/main/streams/streams.c:1000 #9 0x081c7c66 in stream_cookie_writer (cookie=0x83446c4, buffer=0x4003 "\n\n\n PHP: Hypertext Preprocessor\n http://static.php.net/www.php.net/style.css\"; />\n"..., size=8192) at /usr/src/web/php5-STABLE-200408292230/main/streams/cast.c:96 #10 0x42062019 in _IO_cookie_write () from /lib/tls/libc.so.6 #11 0x4206d09e in new_do_write () from /lib/tls/libc.so.6 #12 0x4206d036 in _IO_new_do_write () from /lib/tls/libc.so.6 #13 0x4206d7b8 in _IO_new_file_overflow () from /lib/tls/libc.so.6 #14 0x4206e220 in _IO_new_file_xsputn () from /lib/tls/libc.so.6 #15 0x42062a62 in fwrite () from /lib/tls/libc.so.6 #16 0x40027de3 in last_use () from /usr/lib/20040412/curl.so #17 0x4064c139 in Curl_client_write (data=0x834c50c, type=1, ptr=0x834c7b8 ">\n The PHP Development Team would like to announce the immediate availability of PHP 5.0.1.\n This is a maintenance release that in addition to many non-critical bug fixes "..., len=1448) at sendf.c:337 #18 0x40663fcf in Curl_httpchunk_read (conn=0x8344f3c, datap=0x834c7b8 ">\n The PHP Development Team would like to announce the immediate availability of PHP 5.0.1.\n This is a maintenance release that in addition to many non-critical bug fixes "..., datalen=1448, wrotep=0xbfffb880) at http_
#31474 [Bgs]: calling of the parent class method leads to recursion and segmentation fault
ID: 31474
User updated by: public at grik dot net
Reported By: public at grik dot net
Status: Bogus
Bug Type: Class/Object related
Operating System: linux
PHP Version: 5.0.3
New Comment:
>you're nesting many levels of function calls
exactly
>which exhaust the stack.
why don't I get the "stack overflow" error?
or any error at all?
>That's why you get a segfault - the only case where it is acceptable
in PHP.
I just think the blank page is not the best way to reflect errors :-)
Previous Comments:
--------
[2005-01-10 21:23:22] public at grik dot net
I do not claim the :: and -> are thre same.
The bug is the segfault.
Could you please be more careful?
[2005-01-10 21:12:41] [EMAIL PROTECTED]
And for the record, you're nesting many levels of function calls, which
exhaust the stack. That's why you get a segfault - the only case where
it is acceptable in PHP.
[2005-01-10 21:08:21] [EMAIL PROTECTED]
:: and -> are not equivalent operators, please read the manual. This is
not a bug.
----------------
[2005-01-10 17:23:54] public at grik dot net
Description:
When I moved my classes hierarchy code from the PHP 4 to the PHP 5 and
renamed costructors from the class names to "__construct", I faced a
segmentation fault.
The constructor calls the parent's constructor.
Parent's constructor calls another method, overloaded in the child's
class.
That overloaded method from the child's class calls the constructor
that calls the parent's constructor again.
But instead of the endless loop I get the segfault.
Reproduce code:
---
class A{
function a1(){
echo ' class a ';
}
function a2(){
$this->a1();
}
}
class B extends A {
function a1(){
$this->a2();
}
function __construct(){
parent::a2();
}
}
$a= new B();
Expected result:
Really, I would like to see the output of " class a " string,
cause it's not convenient to rewrite all occurences of
$this->method() to self::method in the base classes.
But I understand there is a new paradigm of "final" methods now and I
will use it.
I would like to see the endless loop until script execution time
expires:
B::a1() calls A::a2() and vice versa
Actual result:
--
Segmentation fault
--
Edit this bug report at http://bugs.php.net/?id=31474&edit=1
#31474 [Bgs]: calling of the parent class method leads to recursion and segmentation fault
ID: 31474
User updated by: public at grik dot net
Reported By: public at grik dot net
Status: Bogus
Bug Type: Class/Object related
Operating System: linux
PHP Version: 5.0.3
New Comment:
I do not claim the :: and -> are thre same.
The bug is the segfault.
Could you please be more careful?
Previous Comments:
[2005-01-10 21:12:41] [EMAIL PROTECTED]
And for the record, you're nesting many levels of function calls, which
exhaust the stack. That's why you get a segfault - the only case where
it is acceptable in PHP.
[2005-01-10 21:08:21] [EMAIL PROTECTED]
:: and -> are not equivalent operators, please read the manual. This is
not a bug.
[2005-01-10 17:23:54] public at grik dot net
Description:
When I moved my classes hierarchy code from the PHP 4 to the PHP 5 and
renamed costructors from the class names to "__construct", I faced a
segmentation fault.
The constructor calls the parent's constructor.
Parent's constructor calls another method, overloaded in the child's
class.
That overloaded method from the child's class calls the constructor
that calls the parent's constructor again.
But instead of the endless loop I get the segfault.
Reproduce code:
---
class A{
function a1(){
echo ' class a ';
}
function a2(){
$this->a1();
}
}
class B extends A {
function a1(){
$this->a2();
}
function __construct(){
parent::a2();
}
}
$a= new B();
Expected result:
Really, I would like to see the output of " class a " string,
cause it's not convenient to rewrite all occurences of
$this->method() to self::method in the base classes.
But I understand there is a new paradigm of "final" methods now and I
will use it.
I would like to see the endless loop until script execution time
expires:
B::a1() calls A::a2() and vice versa
Actual result:
--
Segmentation fault
--
Edit this bug report at http://bugs.php.net/?id=31474&edit=1
#31475 [Bgs]: calling of the parent class method leads to recursion and segmentation fault
ID: 31475
User updated by: public at grik dot net
Reported By: public at grik dot net
Status: Bogus
Bug Type: Class/Object related
Operating System: linux
PHP Version: 5.0.3
New Comment:
Sorry, this is a repost from the #31474,
caused by my problem of the internet connection.
Sorry.
Previous Comments:
[2005-01-10 17:31:06] [EMAIL PROTECTED]
Submitted twice.
[2005-01-10 17:24:23] public at grik dot net
Description:
When I moved my classes hierarchy code from the PHP 4 to the PHP 5 and
renamed costructors from the class names to "__construct", I faced a
segmentation fault.
The constructor calls the parent's constructor.
Parent's constructor calls another method, overloaded in the child's
class.
That overloaded method from the child's class calls the constructor
that calls the parent's constructor again.
But instead of the endless loop I get the segfault.
Reproduce code:
---
class A{
function a1(){
echo ' class a ';
}
function a2(){
$this->a1();
}
}
class B extends A {
function a1(){
$this->a2();
}
function __construct(){
parent::a2();
}
}
$a= new B();
Expected result:
The endless loop until script execution time expires:
B::a1() calls A::a2() and vice versa
Actual result:
--
Segmentation fault
--
Edit this bug report at http://bugs.php.net/?id=31475&edit=1
#31475 [NEW]: calling of the parent class method leads to recursion and segmentation fault
From: public at grik dot net
Operating system: linux
PHP version: 5.0.3
PHP Bug Type: Class/Object related
Bug description: calling of the parent class method leads to recursion and
segmentation fault
Description:
When I moved my classes hierarchy code from the PHP 4 to the PHP 5 and
renamed costructors from the class names to "__construct", I faced a
segmentation fault.
The constructor calls the parent's constructor.
Parent's constructor calls another method, overloaded in the child's
class.
That overloaded method from the child's class calls the constructor that
calls the parent's constructor again.
But instead of the endless loop I get the segfault.
Reproduce code:
---
class A{
function a1(){
echo ' class a ';
}
function a2(){
$this->a1();
}
}
class B extends A {
function a1(){
$this->a2();
}
function __construct(){
parent::a2();
}
}
$a= new B();
Expected result:
The endless loop until script execution time expires:
B::a1() calls A::a2() and vice versa
Actual result:
--
Segmentation fault
--
Edit bug report at http://bugs.php.net/?id=31475&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31475&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=31475&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=31475&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=31475&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=31475&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=31475&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=31475&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=31475&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=31475&r=support
Expected behavior: http://bugs.php.net/fix.php?id=31475&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=31475&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=31475&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=31475&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31475&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=31475&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=31475&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=31475&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=31475&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=31475&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=31475&r=mysqlcfg
#31474 [NEW]: calling of the parent class method leads to recursion and segmentation fault
From: public at grik dot net
Operating system: linux
PHP version: 5.0.3
PHP Bug Type: Class/Object related
Bug description: calling of the parent class method leads to recursion and
segmentation fault
Description:
When I moved my classes hierarchy code from the PHP 4 to the PHP 5 and
renamed costructors from the class names to "__construct", I faced a
segmentation fault.
The constructor calls the parent's constructor.
Parent's constructor calls another method, overloaded in the child's
class.
That overloaded method from the child's class calls the constructor that
calls the parent's constructor again.
But instead of the endless loop I get the segfault.
Reproduce code:
---
class A{
function a1(){
echo ' class a ';
}
function a2(){
$this->a1();
}
}
class B extends A {
function a1(){
$this->a2();
}
function __construct(){
parent::a2();
}
}
$a= new B();
Expected result:
Really, I would like to see the output of " class a " string,
cause it's not convenient to rewrite all occurences of
$this->method() to self::method in the base classes.
But I understand there is a new paradigm of "final" methods now and I will
use it.
I would like to see the endless loop until script execution time expires:
B::a1() calls A::a2() and vice versa
Actual result:
--
Segmentation fault
--
Edit bug report at http://bugs.php.net/?id=31474&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31474&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=31474&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=31474&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=31474&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=31474&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=31474&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=31474&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=31474&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=31474&r=support
Expected behavior: http://bugs.php.net/fix.php?id=31474&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=31474&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=31474&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=31474&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31474&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=31474&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=31474&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=31474&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=31474&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=31474&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=31474&r=mysqlcfg
#29886 [NEW]: segment fault when processing curl output with "wrapper-registered" stream
From: public at grik dot net Operating system: Linux PHP version: 5CVS-2004-08-30 (dev) PHP Bug Type: cURL related Bug description: segment fault when processing curl output with "wrapper-registered" stream Description: I register a wrapper, create a stream and pass the pointer to the curl_setopt to process CURL output. When amount of data returned by CURL exeeds 8192 bytes (size of the CURL buffer), PHP ends with Segmentation fault. I could not reach the crash using fwrite(). Similar problem was in PHP 4.3.3, in 4.3.7 everything works fine. I detected this problem again in 5.0.0 and replicated it in the latest stable CSV. I do not know if it happens upon shutdown and if it is relevant to bug #29358. This happens with CURL only. Reproduce code: --- The sample code can be found at: http://www.grik.net/sample.phps Can be run form command line: php -f sample.php Expected result: In PHP 4.3.7 this script would output the amount of bytes obtained from CURL: 8192 8192 ... Actual result: -- In PHP 5.0.0: 8192 8192 Segmentation fault Backtrace (I am not enough good with gdb, could not locate): (gdb) bt #0 0x081f714a in _zval_copy_ctor (zvalue=0x8344684, __zend_filename=0x8273780 "/usr/src/web/php5-STABLE-200408292230/Zend/zend_execute.c", __zend_lineno=3001) at /usr/src/web/php5-STABLE-200408292230/Zend/zend_variables.c:136 #1 0x08227ab6 in zend_send_by_var_helper (execute_data=0xbfffb210, opline=0x8349e38, op_array=0x834b0e4) at /usr/src/web/php5-STABLE-200408292230/Zend/zend_execute.c:3001 #2 0x08221824 in zend_send_var_handler (execute_data=0xbfffb210, opline=0x8349e38, op_array=0x834b0e4) at /usr/src/web/php5-STABLE-200408292230/Zend/zend_execute.c:3061 #3 0x0821cb76 in execute (op_array=0x834b0e4) at /usr/src/web/php5-STABLE-200408292230/Zend/zend_execute.c:1400 #4 0x081ed157 in zend_call_function (fci=0xbfffb370, fci_cache=0x0) at /usr/src/web/php5-STABLE-200408292230/Zend/zend_execute_API.c:835 #5 0x081ec1a9 in call_user_function_ex (function_table=0x0, object_pp=0x82e5f00, function_name=0xbfffb400, retval_ptr_ptr=0xbfffb3fc, param_count=1, params=0xbfffb3f0, no_separation=0, symbol_table=0x0) at /usr/src/web/php5-STABLE-200408292230/Zend/zend_execute_API.c:550 #6 0x081cd58c in php_userstreamop_write (stream=0x83446c4, buf=0x4003 "\n\n\n PHP: Hypertext Preprocessor\n http://static.php.net/www.php.net/style.css\"; />\n"..., count=8192) at /usr/src/web/php5-STABLE-200408292230/main/streams/userspace.c:459 #7 0x081c539d in _php_stream_write_buffer (stream=0x83446c4, buf=0x4003 "\n\n\n PHP: Hypertext Preprocessor\n http://static.php.net/www.php.net/style.css\"; />\n"..., count=8192) at /usr/src/web/php5-STABLE-200408292230/main/streams/streams.c:889 #8 0x081c561f in _php_stream_write (stream=0x83446c4, buf=0x4003 "\n\n\n PHP: Hypertext Preprocessor\n http://static.php.net/www.php.net/style.css\"; />\n"..., count=8192) at /usr/src/web/php5-STABLE-200408292230/main/streams/streams.c:1000 #9 0x081c7c66 in stream_cookie_writer (cookie=0x83446c4, buffer=0x4003 "\n\n\n PHP: Hypertext Preprocessor\n http://static.php.net/www.php.net/style.css\"; />\n"..., size=8192) at /usr/src/web/php5-STABLE-200408292230/main/streams/cast.c:96 #10 0x42062019 in _IO_cookie_write () from /lib/tls/libc.so.6 #11 0x4206d09e in new_do_write () from /lib/tls/libc.so.6 #12 0x4206d036 in _IO_new_do_write () from /lib/tls/libc.so.6 #13 0x4206d7b8 in _IO_new_file_overflow () from /lib/tls/libc.so.6 #14 0x4206e220 in _IO_new_file_xsputn () from /lib/tls/libc.so.6 #15 0x42062a62 in fwrite () from /lib/tls/libc.so.6 #16 0x40027de3 in last_use () from /usr/lib/20040412/curl.so #17 0x4064c139 in Curl_client_write (data=0x834c50c, type=1, ptr=0x834c7b8 ">\n The PHP Development Team would like to announce the immediate availability of PHP 5.0.1.\n This is a maintenance release that in addition to many non-critical bug fixes "..., len=1448) at sendf.c:337 #18 0x40663fcf in Curl_httpchunk_read (conn=0x8344f3c, datap=0x834c7b8 ">\n The PHP Development Team would like to announce the immediate availability of PHP 5.0.1.\n This is a maintenance release that in addition to many non-critical bug fixes "..., datalen=1448, wrotep=0xbfffb880) at http_chunks.c:186 #19 0x40660fd7 in Curl_readwrite (conn=0x8344f3c, done=0xbfffb8df "") at transfer.c:980 #20 0x40661f56 in Transfer (conn=0x8344f3c) at transfer.c:1480 #21 0x4066294a in Curl_perform (data=0x834c50c) at transfer.c:1985 #22 0x40663175 in curl_easy_perform (curl=0x834c50c) at easy.c:378 #23 0x4002ab43 in last_use () from /usr/lib/20040412/curl.so #24 0x0822053b in zend_do_fcall_common_helper (execute_data=0xbfffbc20, opline=0x8348d90, op_array=0x834423c) at /usr/src/web/php5-STABLE-200408292230
