Bug #51860 [Com]: Include fails with toplevel symlink to /
Edit report at http://bugs.php.net/bug.php?id=51860&edit=1
ID: 51860
Comment by: rainer at hosting-ist-mein-leben dot de
Reported by: stephan dot suerken at 1und1 dot de
Summary: Include fails with toplevel symlink to /
Status: Open
Type:Bug
Package: Scripting Engine problem
PHP Version: 5.3.2
New Comment:
Hi,
we got this problem too. We need a fix for this. Plz. thx.
cu
Rainer
Previous Comments:
[2010-05-21 14:04:12] stephan dot suerken at 1und1 dot de
> [2010-05-21 09:37 UTC] the...@php.net
> Wait:
> So if the executed script itself is inside the symlink'd directory,
> VCWD_REALPATH() does not correctly work (used by both include /
require and
> realpath(), that's why I'm using the latter here)
Great, thanks, that sounds much like what I expected ;).
If it might be helpful, I already stepped through the code with gdb
(breaking in some top level *resolve_path (cant remeber exaytly right
now) function ), finding the bug does _not_ occur then; maybe this hints
to some strange race condition.
Thx,
Stephan
[2010-05-21 13:58:12] the...@php.net
Here's the simplest way to reproduce:
xpsrv / # ln -s / phptest
xpsrv / # echo "OK" > /phpfile
xpsrv / # echo ' /phpinc
Works:
xpsrv / # php532 /phpinc
OK
Breaks:
xpsrv / # php532 /phptest/phpinc
Warning: include(/phptest/phpfile): failed to open stream: No such file
or directory in /phpinc on line 1
Warning: include(): Failed opening '/phptest/phpfile' for inclusion
(include_path='.:') in /phpinc on line 1
xpsrv / # php532 -v | head -1
PHP 5.3.2 (cli) (built: May 21 2010 12:18:37)
[2010-05-21 13:44:33] stephan dot suerken at 1und1 dot de
> [2010-05-21 09:12 UTC] the...@php.net
Your "simplified" way does not produce the bug; did you do it with the
exact settings in the tarball (really, it does not harm!)? Thing is, the
slightest change in the "setup" make the bug go away, and the exact
setup described in the tarball reproduces it.
For what I know, you _need_ the extra include dir under / to reproduce,
and you _must_ call php as described in the "fail" script in the
tarball, i.e. with the full path _including_ the symlink. Both is not in
your simplified way to reproduce it.
Thanks!
Stephan
[2010-05-21 13:37:53] the...@php.net
Wait:
# /opt/php/php-5.3.2/sapi/cli/php -r
'var_dump(realpath("/phplink/phpinclude/inc123.php"));'
string(22) "/phpinclude/inc123.php"
...and:
# echo '
test.php
# /opt/php/php-5.3.2/sapi/cli/php test.php
string(22) "/phpinclude/inc123.php"
But:
# echo '
/phplink/phptest/test.php
# /opt/php/php-5.3.2/sapi/cli/php /phplink/phptest/test.php
bool(false)
So if the executed script itself is inside the symlink'd directory,
VCWD_REALPATH() does not correctly work (used by both include / require
and realpath(), that's why I'm using the latter here)
This does not occur with PHP 5.2.X (or PHP4, btw)
[2010-05-21 13:12:21] the...@php.net
Cannot reproduce on Gentoo with 5.3.2-RELEASE.
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=51860
--
Edit this bug report at http://bugs.php.net/bug.php?id=51860&edit=1
Bug #52191 [Fbk->Opn]: any PHP version above 5.3.0 causes Apache above 2.2.11 to die on start
Edit report at http://bugs.php.net/bug.php?id=52191&edit=1 ID: 52191 User updated by: therealloonylion at yahoo dot co dot uk Reported by: therealloonylion at yahoo dot co dot uk Summary: any PHP version above 5.3.0 causes Apache above 2.2.11 to die on start -Status: Feedback +Status: Open Type: Bug Package: Reproducible crash Operating System: Windows XP/2003 PHP Version: 5.3.2 New Comment: The only information in the backtraces that I didn't paste was: Type of Analysis Performed Crash Analysis Machine Name SARABI Operating System Windows XP Service Pack 3 Number Of Processors 2 Process ID 516 Process Image C:\Program Files\Apache Software Foundation\Apache2.2\bin\httpd.exe System Up-Time 05:46:54 Process Up-Time 00:00:03 There's an entry point in the backtraces (already pasted) but nothing about main() Previous Comments: [2010-06-26 23:17:19] ka...@php.net Hi, your backtrace doesn't seem to include all of it, like the application entry point at main(), is there any chance you can get those remaining trace bits? [2010-06-26 19:13:37] therealloonylion at yahoo dot co dot uk It seems to no longer occur with PHP 5.3.2 although it did last time I tried it (a month or so ago) and when it first was released (tested on Apache 2.2.13 and 2.2.14 at the time). It still occurs with 5.3.1, however, so I have attached backtraces from tests with that version and the following version matrix: Apache 2.2.11 2.2.13 2.2.14 2.2.15 PHP 5.3.0W W W W 5.3.1NWNW NW NW 5.3.2W W W W W = working NW = not working Apache 2.2.11: apache log: [Sat Jun 26 15:43:39 2010] [notice] Child 5332: All worker threads have exited. [Sat Jun 26 15:43:39 2010] [notice] Child 5332: Child process is exiting [Sat Jun 26 15:44:23 2010] [crit] (OS 6)The handle is invalid. : master_main: create child process failed. Exiting. [Sat Jun 26 15:44:23 2010] [notice] Parent: Forcing termination of child process 36 backtrace: Thread 0 - System ID 1208 Entry point httpd+1ecf Create time 26/06/2010 15:55:10 Time spent in user mode 0 Days 0:0:0.46 Time spent in kernel mode 0 Days 0:0:0.203 Function Arg 1 Arg 2 Arg 3 Source php5ts!php_date_get_timezone_ce+39c 0134 7c90d99a 7c810f63 kernel32!CreateFileA+30 0003 0134 0x8000` 77c61aa0 0006facc 77c2c16e msvcrt!_unlock+15 0004 77c2c215 005bbc80 msvcrt!calloc+ab 0020 00ca6924 php5ts!zend_error+498 77c47660 77c47660 0020 php5ts!spprintf+19 0020 00ca68d4 012b2288 php5ts!php_verror+554 PHP5TS!PHP_DATE_GET_TIMEZONE_CE+39CWARNING - DebugDiag was not able to locate debug symbols for php5ts.dll, so the information below may be incomplete. In httpd__PID__3272__Date__06_26_2010__Time_03_55_46PM__671__Second_Chance_Exception_C005.dmp the assembly instruction at php5ts!php_date_get_timezone_ce+39c in W:\PHP\php5ts.dll from The PHP Group has caused an access violation exception (0xC005) when trying to read from memory location 0x0045 on thread 0 Module Information Image Name: W:\PHP\php5ts.dll Symbol Type: Export Base address: 0x0097 Time Stamp: Thu Nov 19 10:17:25 2009 Checksum: 0x Comments: COM DLL: False Company Name: The PHP Group ISAPIExtension: False File Description: PHP Script Interpreter ISAPIFilter: False File Version: 5.3.1 Managed DLL: False Internal Name: PHP Script Interpreter VB DLL: False Legal Copyright: Copyright © 1997-2009 The PHP Group Loaded Image Name: php5ts.dll Legal Trademarks: PHP Mapped Image Name: W:\PHP\php5ts.dll Original filename: php5ts.dll Module name: php5ts Private Build: Single Threaded: False Product Name: PHP Module Size: 5.45 MBytes Product Version: 5.3.1 Symbol File Name: php5ts.dll Special Build: & Apache 2.2.13 apache log: [Sat Jun 26 16:25:38 2010] [warn] pid file C:/Program Files/Apache Software Foundation/Apache2.2/logs/httpd.pid overwritten -- Unclean shutdown of previous Apache run? backtrace: Thread 0 - System ID 3396 Entry point httpd+1ecf Create time 26/06/2010 16:25:38 Time spent in user mode 0 Days 0:0:0.15 Time spent in kernel mode 0 Days 0:0:0.265 Function Arg 1 Arg 2 Arg 3 Source php5ts!php_date_get_timezone_ce+39c 012c 7c90d99a 7c810f63 kernel32!CreateFileA+30 0003 012c 0x8000`
Bug #51759 [Com]: Same as bug #45150 (localhost -> 127.0.0.1)
Edit report at http://bugs.php.net/bug.php?id=51759&edit=1 ID: 51759 Comment by: therealloonylion at yahoo dot co dot uk Reported by: sed at sed dot is Summary: Same as bug #45150 (localhost -> 127.0.0.1) Status: Open Type: Bug Package: MySQL related Operating System: Windows 7 Ultimate 64bit PHP Version: 5.3.2 New Comment: I have the same issue as falcon_ia at hotmail dot com. I upgraded 5.3.0 to 5.3.2 and php is no longer able to connect to Mysql. Mysql is working fine and my hosts file is correct. Previous Comments: [2010-05-09 17:46:17] falcon_ia at hotmail dot com After I updated php from 5.3.0 to 5.3.2, mysql_connect cannot connect localhost but 127.0.0.1. It shows: Warning: mysql_connect() [function.mysql-connect]: [2002] A connection attempt failed because the connected party did not (trying to connect via tcp://localhost:3306) in And drivers\etc\hosts seems good. [2010-05-06 21:43:33] sed at sed dot is Description: Same as bug #45150. I was not able to connect to MySQL via localhost though PHP found the mysql extension etc. Finally, after 20 hours work, I found a website through Google that let me to a solution. To fix this I'll have to use "127.0.0.1" instead of "localhost" I'm using IIS7.5 on Windows 7 Ultimate 64bit FastCGI (PHP 5.2.13 installer [20,929Kb] - 25 February 2010, md5: 891e3262428851ebe71d5432a97be6d5, with my own php.ini aftertouch) MySQL 5.1.46-winx64 Using both IPv4 and IPv6 I can use localhost within MySQL command prompt, but not with PHP. Test script: --- // timeout $host = "localhost"; $user = "root"; $password = "**"; $database = "**"; $mysql_link = mysql_connect( $host, $user, $password ); // timeout fixed $host = "127.0.0.1"; $user = "root"; $password = "**"; $database = "**"; $mysql_link = mysql_connect( $host, $user, $password ); Expected result: Normal connection with mysql without timeout. Actual result: -- Timeout trying to connect via mysql_connect (Error: 2002) -- Edit this bug report at http://bugs.php.net/bug.php?id=51759&edit=1
Bug #52187 [Fbk->Opn]: apache2handler build error
Edit report at http://bugs.php.net/bug.php?id=52187&edit=1 ID: 52187 User updated by: maxim dot novozhilov at gmail dot com Reported by: maxim dot novozhilov at gmail dot com Summary: apache2handler build error -Status: Feedback +Status: Open Type: Bug Package: Apache2 related Operating System: FreeBSD 7.3-RELEASE (amd64) PHP Version: 5.2.13 New Comment: > Does this happen on 5.3.x? No, I compiled 5.3.2 from source w/o any problems. Previous Comments: [2010-06-26 23:24:00] ka...@php.net Does this happen on 5.3.x? Just wondering since we don't bundle the regex lib in the root anymore [2010-06-26 23:23:08] ka...@php.net Would something as simple as adding, between the two #include statements in mod_php5.c: #undef regoff_t [2010-06-26 00:12:06] maxim dot novozhilov at gmail dot com Description: Try ./configure --with-apxs2=/usr/local/sbin/apxs then `make` and you get always build error: previous declaration of 'regoff_t' was here The same for 5.2.14RC1 I have apache-2.0.63 installed on x64 system Actual result: -- /bin/sh /usr/home/max/dist/php-5.2.13/libtool --silent --preserve-dup-deps -- mode=compile gcc -DBIG_SECURITY_HOLE -I/usr/local/include/apache2 -D_REENTRANT -D_THREAD_SAFE -I/usr/local/include/apr-0 -I/usr/local/include/apr-0 - I/usr/local/include -I/usr/local/include/db42 -Isapi/apache2handler/ - I/usr/home/max/dist/php-5.2.13/sapi/apache2handler/ -DPHP_ATOM_INC - I/usr/home/max/dist/php-5.2.13/include -I/usr/home/max/dist/php-5.2.13/main - I/usr/home/max/dist/php-5.2.13 -I/usr/home/max/dist/php-5.2.13/ext/date/lib - I/usr/local/include/libxml2 -I/usr/local/include -I/usr/home/max/dist/php- 5.2.13/TSRM -I/usr/home/max/dist/php-5.2.13/Zend-I/usr/local/include -g -O2 -c /usr/home/max/dist/php-5.2.13/sapi/apache2handler/mod_php5.c -o sapi/apache2handler/mod_php5.lo In file included from /usr/local/include/apache2/httpd.h:44, from /usr/home/max/dist/php- 5.2.13/sapi/apache2handler/php_apache.h:24, from /usr/home/max/dist/php- 5.2.13/sapi/apache2handler/mod_php5.c:26: /usr/local/include/apache2/ap_regex.h:90: error: conflicting types for 'regoff_t' /usr/home/max/dist/php-5.2.13/regex/regex.h:17: error: previous declaration of 'regoff_t' was here *** Error code 1 -- Edit this bug report at http://bugs.php.net/bug.php?id=52187&edit=1
Bug #52192 [Fbk->Opn]: PHP 5.3 not working against OpenSSL 0.9.6
Edit report at http://bugs.php.net/bug.php?id=52192&edit=1 ID: 52192 User updated by: news at onastick dot clara dot co dot uk Reported by: news at onastick dot clara dot co dot uk Summary: PHP 5.3 not working against OpenSSL 0.9.6 -Status: Feedback +Status: Open Type: Bug Package: Compile Failure Operating System: Linux PHP Version: 5.3.2 New Comment: Using latest snapshot makes no difference. Same errors are generated. Previous Comments: [2010-06-26 16:09:56] paj...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2010-06-26 15:23:49] news at onastick dot clara dot co dot uk Description: "configure" states that OpenSSL 0.9.6 is required as a minimum for build however the compilation process fails on line 4560 building ext/openssl/openssl. It seems that newer versions of SSL return a status from 'EVP_DigestFinal' whereas in 0.9.6 is it a void. This is relatively easily hacked out however at final link fatal errors are produced - see actual result below. For me, yes I'd like it to work with my existing version however this probably isn't realistic going forward so the build should probably be updated to give a new minimum version of SSL that it will work with. Test script: --- ./configure --with-openssl make Expected result: Build completes successfully Actual result: -- ext/openssl/.libs/openssl.o: In function `php_openssl_generate_private_key': /home/jon/php/php-5.3.2/ext/openssl/openssl.c:2778: undefined reference to `DH_get_default_method' ext/openssl/.libs/openssl.o: In function `zif_openssl_sign': /home/jon/php/php-5.3.2/ext/openssl/openssl.c:4006: undefined reference to `EVP_MD_CTX_cleanup' ext/openssl/.libs/openssl.o: In function `zif_openssl_verify': /home/jon/php/php-5.3.2/ext/openssl/openssl.c:4057: undefined reference to `EVP_MD_CTX_cleanup' ext/openssl/.libs/openssl.o: In function `zif_openssl_get_md_methods': /home/jon/php/php-5.3.2/ext/openssl/openssl.c:4512: undefined reference to `OBJ_NAME_do_all_sorted' ext/openssl/.libs/openssl.o: In function `zif_openssl_get_cipher_methods': /home/jon/php/php-5.3.2/ext/openssl/openssl.c:4528: undefined reference to `OBJ_NAME_do_all_sorted' collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 1 -- Edit this bug report at http://bugs.php.net/bug.php?id=52192&edit=1
Bug #52192 [Opn->Asn]: PHP 5.3 not working against OpenSSL 0.9.6
Edit report at http://bugs.php.net/bug.php?id=52192&edit=1 ID: 52192 Updated by: paj...@php.net Reported by: news at onastick dot clara dot co dot uk Summary: PHP 5.3 not working against OpenSSL 0.9.6 -Status: Open +Status: Assigned Type: Bug Package: Compile Failure Operating System: Linux PHP Version: 5.3.2 -Assigned To: +Assigned To: pajoye New Comment: Have you ever considered to update? 0.9.6 is 7 years old and many critical fixes have been done since. I don't have a box with this version, but can check to see if it is easily fixable. If not, this bug will be marked as won't fix. Previous Comments: [2010-06-27 21:33:10] news at onastick dot clara dot co dot uk Using latest snapshot makes no difference. Same errors are generated. [2010-06-26 16:09:56] paj...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2010-06-26 15:23:49] news at onastick dot clara dot co dot uk Description: "configure" states that OpenSSL 0.9.6 is required as a minimum for build however the compilation process fails on line 4560 building ext/openssl/openssl. It seems that newer versions of SSL return a status from 'EVP_DigestFinal' whereas in 0.9.6 is it a void. This is relatively easily hacked out however at final link fatal errors are produced - see actual result below. For me, yes I'd like it to work with my existing version however this probably isn't realistic going forward so the build should probably be updated to give a new minimum version of SSL that it will work with. Test script: --- ./configure --with-openssl make Expected result: Build completes successfully Actual result: -- ext/openssl/.libs/openssl.o: In function `php_openssl_generate_private_key': /home/jon/php/php-5.3.2/ext/openssl/openssl.c:2778: undefined reference to `DH_get_default_method' ext/openssl/.libs/openssl.o: In function `zif_openssl_sign': /home/jon/php/php-5.3.2/ext/openssl/openssl.c:4006: undefined reference to `EVP_MD_CTX_cleanup' ext/openssl/.libs/openssl.o: In function `zif_openssl_verify': /home/jon/php/php-5.3.2/ext/openssl/openssl.c:4057: undefined reference to `EVP_MD_CTX_cleanup' ext/openssl/.libs/openssl.o: In function `zif_openssl_get_md_methods': /home/jon/php/php-5.3.2/ext/openssl/openssl.c:4512: undefined reference to `OBJ_NAME_do_all_sorted' ext/openssl/.libs/openssl.o: In function `zif_openssl_get_cipher_methods': /home/jon/php/php-5.3.2/ext/openssl/openssl.c:4528: undefined reference to `OBJ_NAME_do_all_sorted' collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 1 -- Edit this bug report at http://bugs.php.net/bug.php?id=52192&edit=1
Bug #48930 [Asn->Csd]: __COMPILER_HALT_OFFSET__ incorrect in PHP>=5.3
Edit report at http://bugs.php.net/bug.php?id=48930&edit=1 ID: 48930 Updated by: fel...@php.net Reported by: adam-phpbugs at adam dot gs Summary: __COMPILER_HALT_OFFSET__ incorrect in PHP>=5.3 -Status: Assigned +Status: Closed Type: Bug Package: Scripting Engine problem Operating System: * PHP Version: 5.3, 6 Assigned To: scottmac New Comment: 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/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2010-05-26 11:32:44] daniel dot haas at cn-consult dot eu We also hit this bug, because we have a custom php-based installer that uses __halt_compiler() and __COMPILER_HALT_OFFSET__ to extract a tar.gz portion of the installer. Since PHP 5.3 our installers do not work anymore! :-( Is a fix not even planned at this stage?? [2009-09-09 20:02:00] j...@php.net Nevermind, of course it's still borked since the check is NOT done in scanner. :) [2009-09-09 19:56:40] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Since the shebang check was removed from scanner, isn't this issue solved then? (please try :) [2009-08-30 22:56:02] adam-phpbugs at adam dot gs Understandably this might be a bit hackish to have use a global variable here, but perhaps thats preferable to what i'd consider a major regression? I attempted to patch this so I could just submit a patch here, but unfortunately my c-fu and my understanding of PHP internals is lacking. [2009-08-03 03:06:47] scott...@php.net The sapi/cli/php_cli.c code will read forward when it see's a shebang to the next line. The file is already seeked by the time the scanner gets a change to look at it. The zend_get_scanned_file_offset() doesn't know about this because by the time the scanner is started the bytes are already long gone. Short of a global variable I'm not seeing a clean way to fix this. 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=48930 -- Edit this bug report at http://bugs.php.net/bug.php?id=48930&edit=1
Bug #48930 [Csd]: __COMPILER_HALT_OFFSET__ incorrect in PHP>=5.3
Edit report at http://bugs.php.net/bug.php?id=48930&edit=1 ID: 48930 User updated by: adam-phpbugs at adam dot gs Reported by: adam-phpbugs at adam dot gs Summary: __COMPILER_HALT_OFFSET__ incorrect in PHP>=5.3 Status: Closed Type: Bug Package: Scripting Engine problem Operating System: * PHP Version: 5.3, 6 Assigned To: felipe New Comment: Hi felipe, Thanks for taking a look at this bug, its languished for (what i'd consider) far too long. Unfortunately it doesn't seem to fix the issue: -=[~/Scripts/compile/php5.3-201006272030]=- -=[Sun Jun 27]=- -=[18:14:16]=- [a...@nighe]$ ./sapi/cli/php -v PHP 5.3.3RC2-dev (cli) (built: Jun 27 2010 17:54:04) Copyright (c) 1997-2010 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies -=[~/Scripts/compile/php5.3-201006272030]=- -=[Sun Jun 27]=- -=[18:15:11]=- [a...@nighe]$ php -v PHP 5.3.1 (cli) (built: Dec 26 2009 19:21:45) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies -=[~/Scripts/compile/php5.3-201006272030]=- -=[Sun Jun 27]=- -=[18:15:15]=- [a...@nighe]$ ./sapi/cli/php test-without-shebang.php string(19) " this is test data " -=[~/Scripts/compile/php5.3-201006272030]=- -=[Sun Jun 27]=- -=[18:15:30]=- [a...@nighe]$ ./sapi/cli/php test-with-shebang.php string(40) "); __halt_compiler(); this is test data " -=[~/Scripts/compile/php5.3-201006272030]=- -=[Sun Jun 27]=- -=[18:15:34]=- [a...@nighe]$ php test-with-shebang.php string(40) "); __halt_compiler(); this is test data " -=[~/Scripts/compile/php5.3-201006272030]=- -=[Sun Jun 27]=- -=[18:15:38]=- [a...@nighe]$ php test-without-shebang.php string(19) " this is test data " -=[~/Scripts/compile/php5.3-201006272030]=- -=[Sun Jun 27]=- -=[18:15:44]=- [a...@nighe]$ cat test-without-shebang.php http://svn.php.net/viewvc/?view=revision&revision=300789 Log: - Fixed bug #48930 (__COMPILER_HALT_OFFSET__ incorrect in PHP >= 5.3) [2010-06-27 23:46:12] fel...@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/. Thank you for the report, and for helping us make PHP better. [2010-05-26 11:32:44] daniel dot haas at cn-consult dot eu We also hit this bug, because we have a custom php-based installer that uses __halt_compiler() and __COMPILER_HALT_OFFSET__ to extract a tar.gz portion of the installer. Since PHP 5.3 our installers do not work anymore! :-( Is a fix not even planned at this stage?? [2009-09-09 20:02:00] j...@php.net Nevermind, of course it's still borked since the check is NOT done in scanner. :) [2009-09-09 19:56:40] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Since the shebang check was removed from scanner, isn't this issue solved then? (please try :) 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=48930 -- Edit this bug report at http://bugs.php.net/bug.php?id=48930&edit=1
Bug #48930 [Csd]: __COMPILER_HALT_OFFSET__ incorrect in PHP>=5.3
Edit report at http://bugs.php.net/bug.php?id=48930&edit=1 ID: 48930 User updated by: adam-phpbugs at adam dot gs Reported by: adam-phpbugs at adam dot gs Summary: __COMPILER_HALT_OFFSET__ incorrect in PHP>=5.3 Status: Closed Type: Bug Package: Scripting Engine problem Operating System: * PHP Version: 5.3, 6 Assigned To: felipe New Comment: I lied, It just hasn't hit the snapshots yet, works from SVN sources! -=[~/Scripts/compile/php-src-5.3]=- -=[Sun Jun 27]=- -=[18:40:12]=- [a...@nighe]$ ./sapi/cli/php test-with-shebang.php string(19) " this is test data " -=[~/Scripts/compile/php-src-5.3]=- -=[Sun Jun 27]=- -=[18:40:17]=- [a...@nighe]$ ./sapi/cli/php test-without-shebang.php string(19) " this is test data " Thanks very much felipe! Previous Comments: [2010-06-28 00:16:40] adam-phpbugs at adam dot gs Hi felipe, Thanks for taking a look at this bug, its languished for (what i'd consider) far too long. Unfortunately it doesn't seem to fix the issue: -=[~/Scripts/compile/php5.3-201006272030]=- -=[Sun Jun 27]=- -=[18:14:16]=- [a...@nighe]$ ./sapi/cli/php -v PHP 5.3.3RC2-dev (cli) (built: Jun 27 2010 17:54:04) Copyright (c) 1997-2010 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies -=[~/Scripts/compile/php5.3-201006272030]=- -=[Sun Jun 27]=- -=[18:15:11]=- [a...@nighe]$ php -v PHP 5.3.1 (cli) (built: Dec 26 2009 19:21:45) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies -=[~/Scripts/compile/php5.3-201006272030]=- -=[Sun Jun 27]=- -=[18:15:15]=- [a...@nighe]$ ./sapi/cli/php test-without-shebang.php string(19) " this is test data " -=[~/Scripts/compile/php5.3-201006272030]=- -=[Sun Jun 27]=- -=[18:15:30]=- [a...@nighe]$ ./sapi/cli/php test-with-shebang.php string(40) "); __halt_compiler(); this is test data " -=[~/Scripts/compile/php5.3-201006272030]=- -=[Sun Jun 27]=- -=[18:15:34]=- [a...@nighe]$ php test-with-shebang.php string(40) "); __halt_compiler(); this is test data " -=[~/Scripts/compile/php5.3-201006272030]=- -=[Sun Jun 27]=- -=[18:15:38]=- [a...@nighe]$ php test-without-shebang.php string(19) " this is test data " -=[~/Scripts/compile/php5.3-201006272030]=- -=[Sun Jun 27]=- -=[18:15:44]=- [a...@nighe]$ cat test-without-shebang.php http://svn.php.net/viewvc/?view=revision&revision=300789 Log: - Fixed bug #48930 (__COMPILER_HALT_OFFSET__ incorrect in PHP >= 5.3) [2010-06-27 23:46:12] fel...@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/. Thank you for the report, and for helping us make PHP better. [2010-05-26 11:32:44] daniel dot haas at cn-consult dot eu We also hit this bug, because we have a custom php-based installer that uses __halt_compiler() and __COMPILER_HALT_OFFSET__ to extract a tar.gz portion of the installer. Since PHP 5.3 our installers do not work anymore! :-( Is a fix not even planned at this stage?? [2009-09-09 20:02:00] j...@php.net Nevermind, of course it's still borked since the check is NOT done in scanner. :) 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=48930 -- Edit this bug report at http://bugs.php.net/bug.php?id=48930&edit=1
Bug #51091 [Com]: Persistent PDO Connections Crash
Edit report at http://bugs.php.net/bug.php?id=51091&edit=1 ID: 51091 Comment by: dxm007 at gmail dot com Reported by: achristianson at yakabod dot com Summary: Persistent PDO Connections Crash Status: Feedback Type: Bug Package: Reproducible crash Operating System: CentOS 5.4 PHP Version: 5.3.1 Assigned To: dmitry New Comment: Hi, I've been trying to setup Menalto Gallery and after I got through entire setup of a fresh installation (to verify php, MSSQL, IIS were working fine), I pointed the gallery to my existing database and flat files. Because my data came from an older version of the Gallery, it invokes upgrade wizard which dies every single time on step 2. I've created a crash dump with adplus and it appears to be exactly the same bug as what's reported here. This is 100% repeatable on my machine. I'm using PHP 5.3.2 with Windows 2008 Server R2, IIS7 and MSSQL 2008 R2. I've also been able to get past the crash by adding "zend.enable_gc = Off" to php.ini Previous Comments: [2010-04-20 18:11:48] dmi...@php.net I'm not able to reproduce it. May be it's already fixed. Could you verify? [2010-02-19 16:47:46] johan...@php.net -Status: Open +Status: Assigned -Assigned To: +Assigned To: dmitry Dmitry, can you take a look? - Thanks. [2010-02-19 16:09:24] achristianson at yakabod dot com I gave it a try with zend.enable_gc = Off The segmentation fault no longer occurs [2010-02-19 15:34:36] ras...@php.net Looks like a gc issue. Confirm by setting: zend.enable_gc = Off in your php.ini [2010-02-19 15:29:20] achristianson at yakabod dot com Description: * create persistent connection to database; store it to a variable * create an additional persistent connection to database: store it in the same variable * allocate a bunch of memory * PHP segfaults Reproduce code: --- ;dbname=', '', '', array( PDO::ATTR_PERSISTENT => true )); } Expected result: no segmentation fault Actual result: -- [New Thread 0xb7f396c0 (LWP 3416)] Program received signal SIGSEGV, Segmentation fault. 0x0853a746 in zobj_mark_grey (obj=0xb7b8e07c, pz=0xbfd1f0c8) at /root/php-5.3.1/Zend/zend_gc.c:383 383 p = Z_OBJPROP_P(pz)->pListHead; (gdb) bt #0 0x0853a746 in zobj_mark_grey (obj=0xb7b8e07c, pz=0xbfd1f0c8) at /root/php-5.3.1/Zend/zend_gc.c:383 #1 0x0853a81e in gc_mark_roots () at /root/php- 5.3.1/Zend/zend_gc.c:410 #2 0x0853af64 in gc_collect_cycles () at /root/php- 5.3.1/Zend/zend_gc.c:628 #3 0x0853a1a9 in gc_zobj_possible_root (zv=0xa06bac8) at /root/php- 5.3.1/Zend/zend_gc.c:221 #4 0x08539f78 in gc_zval_possible_root (zv=0xa06bac8) at /root/php- 5.3.1/Zend/zend_gc.c:143 #5 0x08508570 in _zval_ptr_dtor (zval_ptr=0xbfd1f1ec, __zend_filename=0x88fb070 "/root/php-5.3.1/Zend/zend_vm_execute.h", __zend_lineno=28199) at /root/php-5.3.1/Zend/zend_gc.h:183 #6 0x085d7d24 in ZEND_ASSIGN_DIM_SPEC_CV_UNUSED_HANDLER (execute_data=0x9cccd20) at /root/php- 5.3.1/Zend/zend_vm_execute.h:28199 #7 0x08543e68 in execute (op_array=0x9d12f70) at /root/php- 5.3.1/Zend/zend_vm_execute.h:104 #8 0x08518b68 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /root/php-5.3.1/Zend/zend.c:1194 #9 0x084aecdb in php_execute_script (primary_file=0xbfd216a4) at /root/php-5.3.1/main/main.c:2225 #10 0x085e4fa0 in main (argc=2, argv=0xbfd21804) at /root/php- 5.3.1/sapi/cli/php_cli.c:1190 -- Edit this bug report at http://bugs.php.net/bug.php?id=51091&edit=1
