#48930 [NEW]: __COMPILER_HALT_OFFSET__ incorrect in PHP>=5.3
From: adam-phpbugs at adam dot gs Operating system: Any PHP version: 5.3.0 PHP Bug Type: Scripting Engine problem Bug description: __COMPILER_HALT_OFFSET__ incorrect in PHP>=5.3 Description: Starting in PHP 5.3.0, php no longer includes the shebang when calculating the __COMPILER_HALT_OFFSET__. Reproduce code: --- #!/usr/bin/php http://bugs.php.net/?id=48930&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48930&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48930&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48930&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48930&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48930&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48930&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48930&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48930&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48930&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48930&r=support Expected behavior: http://bugs.php.net/fix.php?id=48930&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48930&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48930&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48930&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48930&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48930&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48930&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48930&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48930&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48930&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48930&r=mysqlcfg
#48930 [Asn]: __COMPILER_HALT_OFFSET__ incorrect in PHP>=5.3
ID: 48930 User updated by: adam-phpbugs at adam dot gs Reported By: adam-phpbugs at adam dot gs Status: Assigned Bug Type: Scripting Engine problem Operating System: * PHP Version: 5.3.0 Assigned To: scottmac New Comment: anyone? Previous Comments: [2009-07-16 00:23:45] ka...@php.net Scott, you worked on the re2c switch, any chance you can clarrify this one? [2009-07-15 17:40:49] adam-phpbugs at adam dot gs Description: Starting in PHP 5.3.0, php no longer includes the shebang when calculating the __COMPILER_HALT_OFFSET__. Reproduce code: --- #!/usr/bin/php http://bugs.php.net/?id=48930&edit=1
#48930 [Ana]: __COMPILER_HALT_OFFSET__ incorrect in PHP>=5.3
ID: 48930 User updated by: adam-phpbugs at adam dot gs Reported By: adam-phpbugs at adam dot gs Status: Analyzed Bug Type: Scripting Engine problem Operating System: * PHP Version: 5.3.0 Assigned To: scottmac New Comment: 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. Previous Comments: [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. [2009-07-16 00:23:45] ka...@php.net Scott, you worked on the re2c switch, any chance you can clarrify this one? [2009-07-15 17:40:49] adam-phpbugs at adam dot gs Description: Starting in PHP 5.3.0, php no longer includes the shebang when calculating the __COMPILER_HALT_OFFSET__. Reproduce code: --- #!/usr/bin/php http://bugs.php.net/?id=48930&edit=1
#38613 [Com]: SNMP issues via Apache but ok via PHP CLI
ID: 38613
Comment by: adam-phpbugs at adam dot gs
Reported By: neil at fissure dot net
Status: No Feedback
Bug Type: SNMP related
Operating System: CentOS release 4.3
PHP Version: 5.1.5
New Comment:
Hello,
This bug is still in PHP-5.2.9 and PHP-5.3.0.
I can confirm that disabling snmp_shutdown() in
PHP_MSHUTDOWN_FUNCTION(snmp) corrects the issue with no apparent side
effects.
Previous Comments:
[2008-07-29 09:57:51] cinek at xo dot pl
This bug is still in PHP 5.2.6
Works perfectly with commented line, in the
PHP_MSHUTDOWN_FUNCTION(snmp) function of:
ext/snmp/snmp.c
[2007-04-10 01:00:00] 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".
[2007-04-02 22:07:29] sni...@php.net
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-08-30 17:52:38] neil at fissure dot net
Commenting out this line, in the
PHP_MSHUTDOWN_FUNCTION(snmp) function of:
src/web/php-5.1.6/ext/snmp/snmp.c
diff snmp.c snmp.c.orig
223c223
< /*snmp_shutdown("snmpapp"); */
---
> snmp_shutdown("snmpapp");
but possibly at the risk of re-introducing the memory
leak it was added to combat?
[2006-08-30 16:56:20] neil at fissure dot net
I figured it was a PHP issue as it matched a similar bug
report which was acknowledged to be due to a code change
in PHP.
In that bug, sniper AT php.net, who make the change,
said they were using Apache 2 (and would test with
Apache 1.x if they got a chance). So I'm figuring this
issue lies with PHP and Apache 1.x
I'm happy to do any requested testing/diagnostics if you
can give me some pointers.
I'm getting the same errors as in bug 32680 (which was
acknowledged to be a PHP issue, not say an Apache
issue).
Thanks for your time, Neil.
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/38613
--
Edit this bug report at http://bugs.php.net/?id=38613&edit=1
#44462 [Com]: Can't compile embed sapi on OSX
ID: 44462
Comment by: adam-phpbugs at adam dot gs
Reported By: graham+php at nexopia dot com
Status: Open
Bug Type: Compile Failure
Operating System: OSX
PHP Version: 5.2CVS-2008-03-18
New Comment:
this issue is still existent in PHP5.2.6 latest release as well as the
latest 5.2 sources any idea if this bug will ever be fixed?
Previous Comments:
[2008-04-25 17:56:46] cthompson at nexopia dot com
I just sent the following to the php-install mailing list for
feedback.
Modify php-5.2.5/Zend/zend_ini_scanner.c:
--- /Users/cthompson/php-5.2.5.clean/Zend/zend_ini_scanner.c
2007-11-08 09:36:37.0 -0600
+++ ./zend_ini_scanner.c2008-04-25 10:16:27.0 -0600
@@ -478,7 +478,7 @@
#define yymore() yymore_used_but_not_detected
#define YY_MORE_ADJ 0
#define YY_RESTORE_YY_MORE_OFFSET
-char *yytext;
+//char *yytext;
#define INITIAL 0
/*
+--+
Modify php-5.2.5/Zend/zend_language_scanner.c:
--- /Users/cthompson/php-5.2.5.clean/Zend/zend_language_scanner.c
2007-11-08 09:36:37.0 -0600
+++ ./zend_language_scanner.c2008-04-25 10:17:15.0 -0600
@@ -3009,7 +3009,7 @@
#define yymore() (yy_more_flag = 1)
#define YY_MORE_ADJ yy_more_len
#define YY_RESTORE_YY_MORE_OFFSET
-char *yytext;
+//char *yytext;
#define INITIAL 0
/*
This REMOVES the definition of yytext. I think this is okay because
the various defines in those files actually end up using the yy_text in
zend_global.h, at least as far as I can see.
Certainly, this allows PHP to compile but I am not at all sure if this
is going to cause other problems. Could someone please give me some
feedback?
Additionally, I believe php-5.2.5/sapi/cli/config.m4 should be modified
to compile using libtool on OS X:
--- /Users/cthompson/php-5.2.5.clean/sapi/cli/config.m42007-07-11
17:20:36.0 -0600
+++ ./config.m42008-04-25 11:51:57.0 -0600
@@ -17,7 +17,7 @@
BUILD_CLI="echo '\#! .' > php.sym && echo >>php.sym && nm -BCpg
\`echo \$(PHP_GLOBAL_OBJS) \$(PHP_CLI_OBJS) | sed
's/\([A-Za-z0-9_]*\)\.lo/\1.o/g'\` | \$(AWK) '{ if (((\$\$2 == \"T\") ||
(\$\$2 == \"D\") || (\$\$2 == \"B\")) && (substr(\$\$3,1,1) != \".\")) {
print \$\$3 } }' | sort -u >> php.sym && \$(LIBTOOL) --mode=link \$(CC)
-export-dynamic \$(CFLAGS_CLEAN) \$(EXTRA_CFLAGS)
\$(EXTRA_LDFLAGS_PROGRAM) \$(LDFLAGS) -Wl,-brtl -Wl,-bE:php.sym
\$(PHP_RPATHS) \$(PHP_GLOBAL_OBJS) \$(PHP_CLI_OBJS) \$(EXTRA_LIBS)
\$(ZEND_EXTRA_LIBS) -o \$(SAPI_CLI_PATH)"
;;
*darwin*)
-BUILD_CLI="\$(CC) \$(CFLAGS_CLEAN) \$(EXTRA_CFLAGS)
\$(EXTRA_LDFLAGS_PROGRAM) \$(LDFLAGS) \$(NATIVE_RPATHS)
\$(PHP_GLOBAL_OBJS:.lo=.o) \$(PHP_CLI_OBJS:.lo=.o) \$(PHP_FRAMEWORKS)
\$(EXTRA_LIBS) \$(ZEND_EXTRA_LIBS) -o \$(SAPI_CLI_PATH)"
+BUILD_CLI="\$(LIBTOOL) --mode=link \$(CC) \$(CFLAGS_CLEAN)
\$(EXTRA_CFLAGS) \$(EXTRA_LDFLAGS_PROGRAM) \$(LDFLAGS) \$(NATIVE_RPATHS)
\$(PHP_GLOBAL_OBJS) \$(PHP_CLI_OBJS) \$(PHP_FRAMEWORKS) \$(EXTRA_LIBS)
\$(ZEND_EXTRA_LIBS) -o \$(SAPI_CLI_PATH)"
;;
*netware*)
BUILD_CLI="\$(LIBTOOL) --mode=link \$(CC) -export-dynamic
\$(CFLAGS_CLEAN) \$(EXTRA_CFLAGS) \$(EXTRA_LDFLAGS_PROGRAM) \$(LDFLAGS)
\$(PHP_RPATHS) \$(PHP_CLI_OBJS) \$(EXTRA_LIBS) \$(ZEND_EXTRA_LIBS)
-Lnetware -lphp5lib -o \$(SAPI_CLI_PATH)"
Of course, the shipping version of PHP 5.2.5 would then also need the
php-5.2.5/configure file changing, though presumably this is
autogenerated from the fragments:
--- /Users/cthompson/php-5.2.5.clean/configure2007-11-08
09:36:28.0 -0600
+++ ./configure2008-04-25 11:27:46.0 -0600
@@ -9180,7 +9180,7 @@
BUILD_CLI="echo '\#! .' > php.sym && echo >>php.sym && nm -BCpg
\`echo \$(PHP_GLOBAL_OBJS) \$(PHP_CLI_OBJS) | sed
's/\([A-Za-z0-9_]*\)\.lo/\1.o/g'\` | \$(AWK) '{ if (((\$\$2 == \"T\") ||
(\$\$2 == \"D\") || (\$\$2 == \"B\")) && (substr(\$\$3,1,1) != \".\")) {
print \$\$3 } }' | sort -u >> php.sym && \$(LIBTOOL) --mode=link \$(CC)
-export-dynamic \$(CFLAGS_CLEAN) \$(EXTRA_CFLAGS)
\$(EXTRA_LDFLAGS_PROGRAM) \$(LDFLAGS) -Wl,-brtl -Wl,-bE:php.sym
\$(PHP_RPATHS) \$(PHP_GLOBAL_OBJS) \$(PHP_CLI_OBJS) \$(EXTRA_LIBS)
\$(ZEND_EXTRA_LIBS) -o \$(SAPI_CLI_PATH)"
;;
*darwin*)
-BUILD_CLI="\$(CC) \$(CFLAGS_CLEAN) \$(EXTRA_CFLAGS)
\$(EXTRA_LDFLAGS_PROGRAM) \$(LDFLAGS) \$(NATIVE_RPATHS)
\$(PHP_GLOBAL_OBJS:.lo=.o) \$(PHP_CLI_OBJS:.lo=.o) \$(PHP_FRAMEWORKS)
\$(EXTRA_LIBS) \$(ZEND_EXTRA_LIBS) -o \$(SAPI_CLI_PATH)"
+BUILD_CLI="\$(LIBTOOL) --mode=link \$(CC) \$(CFLAGS_CLEAN)
\$(EXTRA_CFLAGS) \$(EXTRA_LDFLAGS_PROGRAM) \$(LDFLAGS) \$
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 #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: Thats awesome Previous Comments: [2010-06-29 13:54:04] fel...@php.net The fix has been reverted for 5.3 branch because it breaks binary compatibility. [2010-06-29 13:37:15] fel...@php.net Automatic comment from SVN on behalf of felipe Revision: http://svn.php.net/viewvc/?view=revision&revision=300854 Log: - Reverted fix for bug #48930 (due binary compatibility breakage) [2010-06-28 00:41:28] adam-phpbugs at adam dot gs 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! -------- [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) 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: Can you fix the status of this bug then, its not closed nor is it resolved. Previous Comments: [2010-06-29 18:44:17] adam-phpbugs at adam dot gs Thats awesome [2010-06-29 13:54:04] fel...@php.net The fix has been reverted for 5.3 branch because it breaks binary compatibility. [2010-06-29 13:37:15] fel...@php.net Automatic comment from SVN on behalf of felipe Revision: http://svn.php.net/viewvc/?view=revision&revision=300854 Log: - Reverted fix for bug #48930 (due binary compatibility breakage) [2010-06-28 00:41:28] adam-phpbugs at adam dot gs 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! -------- [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://bugs.php.net/bug.php?id=48930 -- Edit this bug report at http://bugs.php.net/bug.php?id=48930&edit=1
[PHP-BUG] Bug #53431 [NEW]: strtotime/DateTime object return incorrect results for invalid date/times
From:
Operating system: ALL
PHP version: Irrelevant
Package: Date/time related
Bug Type: Bug
Bug description:strtotime/DateTime object return incorrect results for invalid
date/times
Description:
When given an invalid date/time both strtotime and the DateTime object
returns the
current day at midnight instead
Test script:
---
[a...@nighe]$ php -r '$x=strtotime("2011-00-00");printf("%s\n",date("Y-m-d
H:i:s",$x));'
2010-11-30 00:00:00
[a...@nighe]$ php -r '$x=new DateTime("2011-00-00");var_dump($x);'
object(DateTime)#1 (3) {
["date"]=>
string(19) "2010-11-30 00:00:00"
["timezone_type"]=>
int(3)
["timezone"]=>
string(16) "America/New_York"
}
Expected result:
returns current day at midnight
Actual result:
--
strtotime should return FALSE
DateTime should throw an Exception.
--
Edit bug report at http://bugs.php.net/bug.php?id=53431&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53431&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53431&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53431&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53431&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53431&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53431&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53431&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53431&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53431&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53431&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53431&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53431&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53431&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53431&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53431&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53431&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53431&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53431&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53431&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53431&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53431&r=mysqlcfg
Bug #53431 [Opn]: strtotime/DateTime object return incorrect results for invalid date/times
Edit report at http://bugs.php.net/bug.php?id=53431&edit=1
ID: 53431
User updated by:adam-phpbugs at adam dot gs
Reported by:adam-phpbugs at adam dot gs
Summary:strtotime/DateTime object return incorrect results
for invalid date/times
Status: Open
Type: Bug
Package:Date/time related
Operating System: ALL
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
I, obviously, swapped expected and actual here.
Previous Comments:
[2010-12-01 03:33:49] adam-phpbugs at adam dot gs
Description:
When given an invalid date/time both strtotime and the DateTime object
returns the
current day at midnight instead
Test script:
---
[a...@nighe]$ php -r
'$x=strtotime("2011-00-00");printf("%s\n",date("Y-m-d H:i:s",$x));'
2010-11-30 00:00:00
[a...@nighe]$ php -r '$x=new DateTime("2011-00-00");var_dump($x);'
object(DateTime)#1 (3) {
["date"]=>
string(19) "2010-11-30 00:00:00"
["timezone_type"]=>
int(3)
["timezone"]=>
string(16) "America/New_York"
}
Expected result:
returns current day at midnight
Actual result:
--
strtotime should return FALSE
DateTime should throw an Exception.
--
Edit this bug report at http://bugs.php.net/bug.php?id=53431&edit=1
#42424 [NEW]: PHP5/PCRE fails to match long strings when ungreedy
From: adam-phpbugs at adam dot gs
Operating system: Any
PHP version: 5.2.3
PHP Bug Type: PCRE related
Bug description: PHP5/PCRE fails to match long strings when ungreedy
Description:
PHP5/PCRE will fail to match on long strings when UNGREEDY, the boundary
is around 100k of data.
FWIW, same results if you change x* to x+ down there.
Reproduce code:
---
%s",str_repeat("x",6));
var_dump(preg_match("#(x*?)#",$data));
$data=sprintf("%s",str_repeat("x",7));
var_dump(preg_match("#(x*?)#",$data));
$data=sprintf("%s",str_repeat("x",7));
var_dump(preg_match("#(x*)#U",$data));
$data=sprintf("%s",str_repeat("x",7));
var_dump(preg_match("#(x*)#",$data));
?>
Expected result:
all 4 expressions should match, this is what occurs with PHP 4.4.7.
Actual result:
--
under PHP 5.2.3:
only the first and 4th expression match
under PHP 4.4.7:
all 4 match.
--
Edit bug report at http://bugs.php.net/?id=42424&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42424&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42424&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42424&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42424&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42424&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42424&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42424&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42424&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42424&r=support
Expected behavior:http://bugs.php.net/fix.php?id=42424&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42424&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42424&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42424&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42424&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42424&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42424&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42424&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42424&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42424&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42424&r=mysqlcfg
#40633 [NEW]: disk_free_space returns a bad result on filesystems with negative free space
From: adam-phpbugs at adam dot gs
Operating system: *BSD (at least)
PHP version: 5.2.1
PHP Bug Type: Filesystem function related
Bug description: disk_free_space returns a bad result on filesystems with
negative free space
Description:
on a filesystem with a negative amount of free space (this
can happen on at least FreeBSD) disk_free_space returns
unreasonable results.
-=[/some/path]=- -=[Sun Feb 25]=- -=[19:51:55]=-
[EMAIL PROTECTED] php -r 'print disk_free_space(".")."\n";'
3.77789318629E+22
-=[/some/path]=- -=[Sun Feb 25]=- -=[19:51:57]=-
[EMAIL PROTECTED] df -h .
FilesystemSizeUsed Avail Capacity Mounted on
/dev/ad7 289G289G-23G 109%/some/path
-=[/some/path]=- -=[Sun Feb 25]=- -=[19:51:58]=-
[EMAIL PROTECTED] df .
Filesystem 1K-blocks Used Avail Capacity Mounted
on
/dev/ad7 302732078 302699550 -24186038 109%/some/
path
Reproduce code:
---
php -r 'print disk_free_space(".")."\n";'
Expected result:
-24186038
Actual result:
--
3.77789318629E+22
--
Edit bug report at http://bugs.php.net/?id=40633&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=40633&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=40633&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=40633&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40633&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=40633&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=40633&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40633&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40633&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=40633&r=support
Expected behavior:http://bugs.php.net/fix.php?id=40633&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=40633&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=40633&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40633&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40633&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40633&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40633&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=40633&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=40633&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=40633&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40633&r=mysqlcfg
#40633 [Fbk->Opn]: disk_free_space returns a bad result on filesystems with negative free space
ID: 40633
User updated by: adam-phpbugs at adam dot gs
Reported By: adam-phpbugs at adam dot gs
-Status: Feedback
+Status: Open
Bug Type: Filesystem function related
Operating System: *BSD (at least)
PHP Version: 5.2.1
New Comment:
This was FreeBSD
if you look at the FreeBSD manpage for tunefs(8), this is
the intended behaviour.
http://www.freebsd.org/cgi/man.cgi?
query=tunefs&apropos=0&sektion=0&manpath=FreeBSD+6.2-
RELEASE&format=html
Basically, in FreeBSD (under UFS2 at least) avaliable space
is calculated as total minus used minus reserved. A small %
(8 by default) is reserved.
So, this is not really a bug, but actually an intended
feature.
Previous Comments:
[2007-02-26 09:33:41] [EMAIL PROTECTED]
What kind of BSD is that and don't you think that negative free space
is a BSD bug?
[2007-02-26 00:55:02] adam-phpbugs at adam dot gs
Description:
on a filesystem with a negative amount of free space (this
can happen on at least FreeBSD) disk_free_space returns
unreasonable results.
-=[/some/path]=- -=[Sun Feb 25]=- -=[19:51:55]=-
[EMAIL PROTECTED] php -r 'print disk_free_space(".")."\n";'
3.77789318629E+22
-=[/some/path]=- -=[Sun Feb 25]=- -=[19:51:57]=-
[EMAIL PROTECTED] df -h .
FilesystemSizeUsed Avail Capacity Mounted on
/dev/ad7 289G289G-23G 109%/some/path
-=[/some/path]=- -=[Sun Feb 25]=- -=[19:51:58]=-
[EMAIL PROTECTED] df .
Filesystem 1K-blocks Used Avail Capacity Mounted
on
/dev/ad7 302732078 302699550 -24186038 109%/some/
path
Reproduce code:
---
php -r 'print disk_free_space(".")."\n";'
Expected result:
-24186038
Actual result:
--
3.77789318629E+22
--
Edit this bug report at http://bugs.php.net/?id=40633&edit=1
#40633 [Opn]: disk_free_space returns a bad result on filesystems with negative free space
ID: 40633
User updated by: adam-phpbugs at adam dot gs
Reported By: adam-phpbugs at adam dot gs
Status: Open
Bug Type: Filesystem function related
-Operating System: *BSD (at least)
+Operating System: FreeBSD
PHP Version: 5.2.1
New Comment:
changing OS to FreeBSD
Previous Comments:
[2007-02-26 13:32:36] adam-phpbugs at adam dot gs
This was FreeBSD
if you look at the FreeBSD manpage for tunefs(8), this is
the intended behaviour.
http://www.freebsd.org/cgi/man.cgi?
query=tunefs&apropos=0&sektion=0&manpath=FreeBSD+6.2-
RELEASE&format=html
Basically, in FreeBSD (under UFS2 at least) avaliable space
is calculated as total minus used minus reserved. A small %
(8 by default) is reserved.
So, this is not really a bug, but actually an intended
feature.
[2007-02-26 09:33:41] [EMAIL PROTECTED]
What kind of BSD is that and don't you think that negative free space
is a BSD bug?
[2007-02-26 00:55:02] adam-phpbugs at adam dot gs
Description:
on a filesystem with a negative amount of free space (this
can happen on at least FreeBSD) disk_free_space returns
unreasonable results.
-=[/some/path]=- -=[Sun Feb 25]=- -=[19:51:55]=-
[EMAIL PROTECTED] php -r 'print disk_free_space(".")."\n";'
3.77789318629E+22
-=[/some/path]=- -=[Sun Feb 25]=- -=[19:51:57]=-
[EMAIL PROTECTED] df -h .
FilesystemSizeUsed Avail Capacity Mounted on
/dev/ad7 289G289G-23G 109%/some/path
-=[/some/path]=- -=[Sun Feb 25]=- -=[19:51:58]=-
[EMAIL PROTECTED] df .
Filesystem 1K-blocks Used Avail Capacity Mounted
on
/dev/ad7 302732078 302699550 -24186038 109%/some/
path
Reproduce code:
---
php -r 'print disk_free_space(".")."\n";'
Expected result:
-24186038
Actual result:
--
3.77789318629E+22
--
Edit this bug report at http://bugs.php.net/?id=40633&edit=1
#40633 [Sus]: disk_free_space returns a bad result on filesystems with negative free space
ID: 40633
User updated by: adam-phpbugs at adam dot gs
Reported By: adam-phpbugs at adam dot gs
Status: Suspended
Bug Type: Filesystem function related
Operating System: FreeBSD
PHP Version: 5.2.1
Assigned To: tony2001
New Comment:
For some reason I didn't get any notification of stas's message.
this is FreeBSD 6.2-STABLE
struct statvfs {
fsblkcnt_t f_bavail; /* Number of blocks */
fsblkcnt_t f_bfree;
fsblkcnt_t f_blocks;
fsfilcnt_t f_favail; /* Number of files (e.g.,
inodes) */
fsfilcnt_t f_ffree;
fsfilcnt_t f_files;
unsigned long f_bsize;/* Size of blocks counted above
*/
unsigned long f_flag;
unsigned long f_frsize; /* Size of fragments */
unsigned long f_fsid; /* Not meaningful */
unsigned long f_namemax; /* Same as
pathconf(_PC_NAME_MAX) */
};
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/statvfs.h for
cvs/changelog (make sure your looking at 6.2-RELEASE) branch, there may
be differences.
Previous Comments:
[2007-04-10 20:58:25] [EMAIL PROTECTED]
Funny thing is that PHP doesn't use any unsigned numbers on the way -
it translates it directly from system call int64 to double. I guess
version of the system and header file defining struct statvfs would be
useful.
[2007-02-26 15:44:08] [EMAIL PROTECTED]
Please provide an SSH account on a machine where I can reproduce it.
[2007-02-26 13:33:03] adam-phpbugs at adam dot gs
changing OS to FreeBSD
[2007-02-26 13:32:36] adam-phpbugs at adam dot gs
This was FreeBSD
if you look at the FreeBSD manpage for tunefs(8), this is
the intended behaviour.
http://www.freebsd.org/cgi/man.cgi?
query=tunefs&apropos=0&sektion=0&manpath=FreeBSD+6.2-
RELEASE&format=html
Basically, in FreeBSD (under UFS2 at least) avaliable space
is calculated as total minus used minus reserved. A small %
(8 by default) is reserved.
So, this is not really a bug, but actually an intended
feature.
[2007-02-26 09:33:41] [EMAIL PROTECTED]
What kind of BSD is that and don't you think that negative free space
is a BSD bug?
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/40633
--
Edit this bug report at http://bugs.php.net/?id=40633&edit=1
