#44985 [NEW]: "bindec_basic.phpt" from "make test" depends on precision
From: twm at twmacinta dot com Operating system: Red Hat Enterprise Linux ES 3 PHP version: 5.2.6 PHP Bug Type: Math related Bug description: "bindec_basic.phpt" from "make test" depends on precision Description: After building PHP 5.2.6 on RHEL3, I ran "make test" to test the new build, and one of the tests that failed was "bindec_basic.phpt". I inspected the test's output, compared it to what was expected, and came up with a potential fix for it based on similar problems from other tests which have since been fixed. The problem appears to be that the expected output of the test is based on a "precision" configuration setting of 14, but my build is using ""php.ini-dist", which has a setting of 12. This looks like it is the same problem that occurred with the "make test" script "ext/json/tests/bug41567.phpt", which was fixed in revision "1.1.2.5". The fix was simply to specify the precision in an INI section. When I apply this same fix to "bindec_basic.phpt", the test then passes. Here's what I added: --INI-- precision=14 This is also the same problem (just in a different file) as bug #44920, which I also reported and which has since been fixed in the suggested manner: http://bugs.php.net/bug.php?id=44920 Reproduce code: --- 1) Copy "php.ini-dist", which comes with PHP, to "/etc/php.ini" 2) Run the test that comes with PHP: "ext/standard/tests/math/bindec_basic.phpt" Expected result: Number of tests :1 1 Tests skipped :0 ( 0.0%) Tests warned:0 ( 0.0%) ( 0.0%) Tests failed:0 ( 0.0%) ( 0.0%) Tests passed:1 (100.0%) (100.0%) Actual result: -- Number of tests :1 1 Tests skipped :0 ( 0.0%) Tests warned:0 ( 0.0%) ( 0.0%) Tests failed:1 (100.0%) (100.0%) Tests passed:0 ( 0.0%) ( 0.0%) -- Edit bug report at http://bugs.php.net/?id=44985&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44985&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44985&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44985&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44985&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44985&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44985&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44985&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44985&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44985&r=support Expected behavior:http://bugs.php.net/fix.php?id=44985&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44985&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44985&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44985&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44985&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44985&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44985&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44985&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44985&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44985&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44985&r=mysqlcfg
#44920 [NEW]: "vsprintf_variation8.phpt" from "make test" depends on precision
From: twm at twmacinta dot com Operating system: Red Hat Enterprise Linux ES 3 PHP version: 5.2.6 PHP Bug Type: Unknown/Other Function Bug description: "vsprintf_variation8.phpt" from "make test" depends on precision Description: After building PHP 5.2.6 on RHEL3, I ran "make test" to test the new build, and one of the tests that failed was "vsprintf_variation8.phpt". I inspected the test's output, compared it to what was expected, tracked down the problem, and came up with a potential fix for it. The problem appears to be that the expected output of the test is based on the default "precision" configuration setting of 14, but my "php.ini" file has it set to 12. This looks like it is the same problem that occurred with the "make test" script "ext/json/tests/bug41567.phpt", which was fixed in revision "1.1.2.5". The fix was simply to specify the precision in an INI section. When I apply this same fix to "vsprintf_variation8.phpt", the test then passes. Here's what I added: --INI-- precision=14 I had copied the file named "php.ini-dist" which came with the PHP source distribution to "/etc/php.ini", without modification. It sets the precision to 12. I looked at the CVS history for the test "vsprintf_variation8.phpt" and it appears to be fixed in PHP 5.3 in the same way I suggested above. I think that fix just needs to be applied to PHP 5.2 as well. Reproduce code: --- 1) Copy "php.ini-dist", which comes with PHP, to "/etc/php.ini" 2) Run the test that comes with PHP: "ext/standard/tests/strings/vsprintf_variation8.phpt" Expected result: Number of tests :1 1 Tests skipped :0 ( 0.0%) Tests warned:0 ( 0.0%) ( 0.0%) Tests failed:0 ( 0.0%) ( 0.0%) Tests passed:1 (100.0%) (100.0%) Actual result: -- Number of tests :1 1 Tests skipped :0 ( 0.0%) Tests warned:0 ( 0.0%) ( 0.0%) Tests failed:1 (100.0%) (100.0%) Tests passed:0 ( 0.0%) ( 0.0%) -- Edit bug report at http://bugs.php.net/?id=44920&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44920&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44920&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44920&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44920&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44920&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44920&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44920&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44920&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44920&r=support Expected behavior:http://bugs.php.net/fix.php?id=44920&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44920&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44920&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44920&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44920&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44920&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44920&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44920&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44920&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44920&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44920&r=mysqlcfg
#44862 [Fbk->Opn]: Invalid encoding in pspell_config_create() w/ pspell_new_config() causes abort
ID: 44862
User updated by: twm at twmacinta dot com
Reported By: twm at twmacinta dot com
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: Red Hat Enterprise Linux ES 3
PHP Version: 5.2.5
New Comment:
Here is a list of all of my 'aspell' and 'pspell' RPMs, with version
numbers:
aspell-0.33.7.1-25.3.rhel3.i386
aspell-config-0.33.7.1-25.3.rhel3.i386
aspell-da-1.4.22-7.i386
aspell-de-0.1.1-17.i386
aspell-devel-0.33.7.1-25.3.rhel3.i386
aspell-en-ca-0.33.7.1-25.3.rhel3.i386
aspell-en-gb-0.33.7.1-25.3.rhel3.i386
aspell-es-0.2-13.i386
aspell-fr-0.6-8.i386
aspell-it-0.1-16.i386
aspell-nl-0.1-17.i386
aspell-no-0.3-6.i386
aspell-pt-0.1-12.i386
aspell-pt_BR-2.4-12.i386
aspell-sv-1.3.8-4.i386
pspell-0.12.2-16.1.i386
pspell-devel-0.12.2-16.1.i386
It does appear to be dying because of a failed assertion, so maybe it
doesn't die for you because your 'pspell' library wasn't compiled to
enforce assertions?
Previous Comments:
[2008-04-30 00:01:18] [EMAIL PROTECTED]
Which version of aspell library are you using? here things work as
intended.
--------
[2008-04-29 17:18:41] twm at twmacinta dot com
Description:
When I pass an invalid encoding as the fourth argument to the function
pspell_config_create() and then pass that return value to
pspell_new_config(), PHP aborts and stops running. This is causing the
"make test" script named "ext/pspell/tests/003.phpt" to fail on my
system when I try to test my new build of PHP. I have created a simpler
test case for this bug report and also read through the code a bit more
to come up with an analysis which I think might be helpful.
My test script works as expected in older versions of PHP on the same
operating system. In particular, it works fine in PHP 4.3 on the same
OS. This applies to both my custom compiled version of PHP as well as
the most recent build from Red Hat. I believe that the problem was
introduced in revision 1.45.2.4.2.5. See line 405 below:
http://cvs.php.net/viewvc.cgi/php-src/ext/pspell/pspell.c?r1=1.45.2.4.2.4&r2=1.45.2.4.2.5&pathrev=PHP_5_2
The problem is that delete_pspell_manager() is called on a pointer
obtained from new_pspell_manager() which isn't necessarily a pspell
manager. It can either be an error or a pspell manager. Here is the
code from the pspell library - note that the first return statement can
result in PHP getting something which isn't a pspell manager (which is
what it incorrectly frees):
PspellCanHaveError * new_pspell_manager(PspellConfig * c)
{
PspellCanHaveError * possible_err = find_word_list(c);
if (possible_err->error_number() != 0)
return possible_err;
PspellConfig * config = (PspellConfig *)(possible_err);
possible_err = new_pspell_manager_class(config);
delete config;
return possible_err;
}
Perhaps this error isn't being triggered on your test systems since it
depends upon whether the system's pspell library was compiled to enforce
assertions.
Note that there were several other changes like this made in revision
1.45.2.4.2.5. There were other lines added which call
delete_pspell_*(), possibly with an invalid argument. I don't know if
they are a problem in reality - I only caught the line that I'm
reporting because "make test" failed for me. I was a little hesitant to
remove those lines in my own code since they were added without other
major changes, so there was presumably some reason for them, though the
revision comment and change log don't mention what it was.
I used "php -n" to run all of the tests, so as to rule out "php.ini" as
a problem. I tried the test script with both PHP 5.2.5 and the latest
CVS snapshot, php5.2-200804291230.
Reproduce code:
---
$cfg2 = pspell_config_create('en', 'british', '', 'b0rked');
$p2 = pspell_new_config($cfg2);
print("Done\n");
Expected result:
Warning: pspell_new_config(): PSPELL couldn't open the dictionary.
reason: The encoding "b0rked" is not known. This could also mean that
the file "/usr/share/pspell/b0rked.map" could not be opened for reading
or does not exist. in /tmp/timtest20080429.php on line 3
Done
Actual result:
--
Warning: pspell_new_config(): PSPELL couldn't open the dictionary.
reason: The encoding "b0rked" is not known. This could also mean that
the file "/usr/share/pspell/b0rked.map" could not be opened for reading
or does not exist. in /tmp/timtest20080429.php on line 3
php: manager_impl.cc:30: void free_lt_handle(void*): Assertion `s == 0'
failed.
Aborted
--
Edit this bug report at http://bugs.php.net/?id=44862&edit=1
#44862 [NEW]: Invalid encoding in pspell_config_create() w/ pspell_new_config() causes abort
From: twm at twmacinta dot com
Operating system: Red Hat Enterprise Linux ES 3
PHP version: 5.2.5
PHP Bug Type: Reproducible crash
Bug description: Invalid encoding in pspell_config_create() w/
pspell_new_config() causes abort
Description:
When I pass an invalid encoding as the fourth argument to the function
pspell_config_create() and then pass that return value to
pspell_new_config(), PHP aborts and stops running. This is causing the
"make test" script named "ext/pspell/tests/003.phpt" to fail on my system
when I try to test my new build of PHP. I have created a simpler test case
for this bug report and also read through the code a bit more to come up
with an analysis which I think might be helpful.
My test script works as expected in older versions of PHP on the same
operating system. In particular, it works fine in PHP 4.3 on the same OS.
This applies to both my custom compiled version of PHP as well as the most
recent build from Red Hat. I believe that the problem was introduced in
revision 1.45.2.4.2.5. See line 405 below:
http://cvs.php.net/viewvc.cgi/php-src/ext/pspell/pspell.c?r1=1.45.2.4.2.4&r2=1.45.2.4.2.5&pathrev=PHP_5_2
The problem is that delete_pspell_manager() is called on a pointer
obtained from new_pspell_manager() which isn't necessarily a pspell
manager. It can either be an error or a pspell manager. Here is the code
from the pspell library - note that the first return statement can result
in PHP getting something which isn't a pspell manager (which is what it
incorrectly frees):
PspellCanHaveError * new_pspell_manager(PspellConfig * c)
{
PspellCanHaveError * possible_err = find_word_list(c);
if (possible_err->error_number() != 0)
return possible_err;
PspellConfig * config = (PspellConfig *)(possible_err);
possible_err = new_pspell_manager_class(config);
delete config;
return possible_err;
}
Perhaps this error isn't being triggered on your test systems since it
depends upon whether the system's pspell library was compiled to enforce
assertions.
Note that there were several other changes like this made in revision
1.45.2.4.2.5. There were other lines added which call delete_pspell_*(),
possibly with an invalid argument. I don't know if they are a problem in
reality - I only caught the line that I'm reporting because "make test"
failed for me. I was a little hesitant to remove those lines in my own
code since they were added without other major changes, so there was
presumably some reason for them, though the revision comment and change log
don't mention what it was.
I used "php -n" to run all of the tests, so as to rule out "php.ini" as a
problem. I tried the test script with both PHP 5.2.5 and the latest CVS
snapshot, php5.2-200804291230.
Reproduce code:
---
$cfg2 = pspell_config_create('en', 'british', '', 'b0rked');
$p2 = pspell_new_config($cfg2);
print("Done\n");
Expected result:
Warning: pspell_new_config(): PSPELL couldn't open the dictionary. reason:
The encoding "b0rked" is not known. This could also mean that the file
"/usr/share/pspell/b0rked.map" could not be opened for reading or does not
exist. in /tmp/timtest20080429.php on line 3
Done
Actual result:
--
Warning: pspell_new_config(): PSPELL couldn't open the dictionary. reason:
The encoding "b0rked" is not known. This could also mean that the file
"/usr/share/pspell/b0rked.map" could not be opened for reading or does not
exist. in /tmp/timtest20080429.php on line 3
php: manager_impl.cc:30: void free_lt_handle(void*): Assertion `s == 0'
failed.
Aborted
--
Edit bug report at http://bugs.php.net/?id=44862&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44862&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44862&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44862&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44862&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44862&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44862&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44862&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44862&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44862&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44862&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44862&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44862&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44862&r=globals
#44801 [Fbk->Opn]: Invalid escaping for passthru() in CLI
ID: 44801
User updated by: twm at twmacinta dot com
Reported By: twm at twmacinta dot com
-Status: Feedback
+Status: Open
Bug Type: CGI related
Operating System: Red Hat Enterprise Linux ES 3
PHP Version: 5.2.5
Assigned To: fb-req-jani
New Comment:
OK, that's the problem. But given that it is the problem, the test
script "bug22414.phpt", which is part of "make test", is bound to fail
any time safe mode is compiled in. It makes nested calls to the PHP
binary with the "-n" option, which apparently causes safe mode to be
turned on since it ignores the test script's custom "php.ini" in that
case. So in that respect, maybe this is a bug in "bug22414.phpt"?
I'd like to suggest that the manual be annotated to reflect the
changing behavior of the safe mode default. Currently,
http://www.php.net/manual/en/ini.php says that default value for
"safe_mode" in "php.ini" is 0. There is no mention that the default
changes depending on how the binary was compiled. In fact, I had
assumed that the default of 0 only applied when safe mode was compiled
into the binary since it would be meaningless otherwise.
This page on safe mode also indicates that the safe mode features
aren't applied to command line scripts.
http://www.php.net/manual/en/features.safe-mode.php says "Warning: These
PHP restrictions are not valid in executed binaries, of course." That's
doesn't seem entirely correct given that it was affecting passthru() in
the command line scripts referenced in this bug.
Previous Comments:
[2008-04-25 16:29:04] [EMAIL PROTECTED]
Using --enable-safe-mode makes the default be "on". (without this
configure option it defaults to "off").
And in the manual it is mentioned that: "Warning:
With safe mode enabled, the command string is escaped with
escapeshellcmd(). Thus, echo y | echo x becomes echo y \| echo x."
The question remains: Did you really turn off safe-mode in php.ini and
was it really turned off? (check with phpinfo())
[2008-04-24 19:48:19] twm at twmacinta dot com
Aha, that set off a spark. I think I found something useful...
The test script actually worked when I tried this:
./configure --disable-all --disable-cgi
Then, I tried no flags at all, and it still worked:
./configure
So I went through all of the flags I used originally and discovered
that the problem appears when all I add is the safe-mode flag:
./configure --enable-safe-mode
Here's the output:
Before: 'Tim'\''s Test'
After: sh: line 1: /usr/local/php/bin/echo: No such file or directory
Note that it was looking for "echo" at a different path. When I
created the directory that it was looking for and copied "echo" there,
then I got the same incorrect output as before:
Before: 'Tim'\''s Test'
After: Tim\s Test'
So the problem occurs when safe-mode is compiled into the executable
even though I am not using safe mode when running the script. I'm using
"php -n" which should avoid safe mode (right?) and my "php.ini" also
turns safe mode off. I checked the other versions of PHP which I
reported on earlier, and the versions which behaved incorrectly had safe
mode compiled in but turned off, and those that behaved correctly did
not have safe mode compiled in at all.
[2008-04-24 18:01:39] [EMAIL PROTECTED]
Can you try with this instead:
# rm -f config.cache
# ./configure --disable-all --disable-cgi
ie. Eliminate everything but the core. :)
[2008-04-24 17:52:47] twm at twmacinta dot com
I was actually using the "-n" flag from the start, so that moving part
was already eliminated.
Here are my "./configure" and "make install" commands:
CONF_OLD_PREFIX=/usr
CONF_PREFIX=/var/tmp2/php5_take2/targ
CONF_SYSCONFDIR=${CONF_PREFIX}/etc
CONF_BINDIR=${CONF_PREFIX}/bin
./configure \
--prefix=${CONF_PREFIX} \
--with-config-file-path=${CONF_SYSCONFDIR} \
--enable-force-cgi-redirect \
--enable-fastcgi \
--disable-debug \
--enable-pic \
--disable-rpath \
--enable-inline-optimization \
--with-bz2 \
--with-curl \
--with-dom=${CONF_PREFIX} \
--with-exec-dir=${CONF_BINDIR} \
--with-freetype-dir=${CONF_PREFIX} \
--with-png-dir=${CONF_PREFIX} \
--with-gd \
--enable-gd-native-ttf \
--with-ttf \
--with-gdbm \
--with-gettext \
--with-db4
#44801 [Fbk->Opn]: Invalid escaping for passthru() in CLI
ID: 44801
User updated by: twm at twmacinta dot com
Reported By: twm at twmacinta dot com
-Status: Feedback
+Status: Open
Bug Type: CGI related
Operating System: Red Hat Enterprise Linux ES 3
PHP Version: 5.2.5
Assigned To: fb-req-jani
New Comment:
Aha, that set off a spark. I think I found something useful...
The test script actually worked when I tried this:
./configure --disable-all --disable-cgi
Then, I tried no flags at all, and it still worked:
./configure
So I went through all of the flags I used originally and discovered
that the problem appears when all I add is the safe-mode flag:
./configure --enable-safe-mode
Here's the output:
Before: 'Tim'\''s Test'
After: sh: line 1: /usr/local/php/bin/echo: No such file or directory
Note that it was looking for "echo" at a different path. When I
created the directory that it was looking for and copied "echo" there,
then I got the same incorrect output as before:
Before: 'Tim'\''s Test'
After: Tim\s Test'
So the problem occurs when safe-mode is compiled into the executable
even though I am not using safe mode when running the script. I'm using
"php -n" which should avoid safe mode (right?) and my "php.ini" also
turns safe mode off. I checked the other versions of PHP which I
reported on earlier, and the versions which behaved incorrectly had safe
mode compiled in but turned off, and those that behaved correctly did
not have safe mode compiled in at all.
Previous Comments:
[2008-04-24 18:01:39] [EMAIL PROTECTED]
Can you try with this instead:
# rm -f config.cache
# ./configure --disable-all --disable-cgi
ie. Eliminate everything but the core. :)
------------
[2008-04-24 17:52:47] twm at twmacinta dot com
I was actually using the "-n" flag from the start, so that moving part
was already eliminated.
Here are my "./configure" and "make install" commands:
CONF_OLD_PREFIX=/usr
CONF_PREFIX=/var/tmp2/php5_take2/targ
CONF_SYSCONFDIR=${CONF_PREFIX}/etc
CONF_BINDIR=${CONF_PREFIX}/bin
./configure \
--prefix=${CONF_PREFIX} \
--with-config-file-path=${CONF_SYSCONFDIR} \
--enable-force-cgi-redirect \
--enable-fastcgi \
--disable-debug \
--enable-pic \
--disable-rpath \
--enable-inline-optimization \
--with-bz2 \
--with-curl \
--with-dom=${CONF_PREFIX} \
--with-exec-dir=${CONF_BINDIR} \
--with-freetype-dir=${CONF_PREFIX} \
--with-png-dir=${CONF_PREFIX} \
--with-gd \
--enable-gd-native-ttf \
--with-ttf \
--with-gdbm \
--with-gettext \
--with-db4 \
--with-ncurses \
--with-gmp \
--with-iconv \
--with-jpeg-dir=${CONF_PREFIX} \
--with-mm \
--with-openssl \
--with-png \
--with-pspell \
--with-regex=system \
--with-xml \
--with-domxml \
--with-expat-dir=${CONF_PREFIX} \
--with-zlib \
--with-layout=GNU \
--enable-mcal \
--enable-bcmath \
--enable-debugger \
--enable-exif \
--enable-ftp \
--enable-magic-quotes \
--enable-safe-mode \
--enable-sockets \
--enable-sysvsem \
--enable-sysvshm \
--enable-discard-path \
--enable-track-vars \
--enable-trans-sid \
--enable-yp \
--enable-wddx \
--without-oci8 \
--with-imap=shared \
--with-mcrypt \
--with-imap-ssl \
--with-kerberos=/usr/kerberos \
--with-ldap=shared \
--with-mysql=shared,${CONF_PREFIX} \
--with-pgsql=shared \
--with-snmp=shared,${CONF_PREFIX} \
--with-snmp=shared \
--enable-net-snmp-hack \
--with-unixODBC=shared,${CONF_OLD_PREFIX} \
--enable-memory-limit \
--enable-bcmath \
--enable-shmop \
--enable-versioning \
--enable-calendar \
--enable-dbx \
--enable-dio \
--enable-mbstring \
--enable-mbstr-enc-trans
make install INSTALL_ROOT=/var/tmp2/php5_take2/targ
[2008-04-24 17:44:49] [EMAIL PROTECTED]
Next obvious question is: How did you build PHP? ie. What configure
line, etc. Also to eliminate every last moving parts: run the script
like this:
# php -n script.php
[2008-04-24 17:23:47] twm at twmacinta dot com
Good idea. I modified my test script as suggested. Here's the output
on RHEL3 with the CVS snapshot php5.2-20080423123:
Bef
#44801 [Fbk->Opn]: Invalid escaping for passthru() in CLI
ID: 44801
User updated by: twm at twmacinta dot com
Reported By: twm at twmacinta dot com
-Status: Feedback
+Status: Open
Bug Type: CGI related
Operating System: Red Hat Enterprise Linux ES 3
PHP Version: 5.2.5
Assigned To: fb-req-jani
New Comment:
I was actually using the "-n" flag from the start, so that moving part
was already eliminated.
Here are my "./configure" and "make install" commands:
CONF_OLD_PREFIX=/usr
CONF_PREFIX=/var/tmp2/php5_take2/targ
CONF_SYSCONFDIR=${CONF_PREFIX}/etc
CONF_BINDIR=${CONF_PREFIX}/bin
./configure \
--prefix=${CONF_PREFIX} \
--with-config-file-path=${CONF_SYSCONFDIR} \
--enable-force-cgi-redirect \
--enable-fastcgi \
--disable-debug \
--enable-pic \
--disable-rpath \
--enable-inline-optimization \
--with-bz2 \
--with-curl \
--with-dom=${CONF_PREFIX} \
--with-exec-dir=${CONF_BINDIR} \
--with-freetype-dir=${CONF_PREFIX} \
--with-png-dir=${CONF_PREFIX} \
--with-gd \
--enable-gd-native-ttf \
--with-ttf \
--with-gdbm \
--with-gettext \
--with-db4 \
--with-ncurses \
--with-gmp \
--with-iconv \
--with-jpeg-dir=${CONF_PREFIX} \
--with-mm \
--with-openssl \
--with-png \
--with-pspell \
--with-regex=system \
--with-xml \
--with-domxml \
--with-expat-dir=${CONF_PREFIX} \
--with-zlib \
--with-layout=GNU \
--enable-mcal \
--enable-bcmath \
--enable-debugger \
--enable-exif \
--enable-ftp \
--enable-magic-quotes \
--enable-safe-mode \
--enable-sockets \
--enable-sysvsem \
--enable-sysvshm \
--enable-discard-path \
--enable-track-vars \
--enable-trans-sid \
--enable-yp \
--enable-wddx \
--without-oci8 \
--with-imap=shared \
--with-mcrypt \
--with-imap-ssl \
--with-kerberos=/usr/kerberos \
--with-ldap=shared \
--with-mysql=shared,${CONF_PREFIX} \
--with-pgsql=shared \
--with-snmp=shared,${CONF_PREFIX} \
--with-snmp=shared \
--enable-net-snmp-hack \
--with-unixODBC=shared,${CONF_OLD_PREFIX} \
--enable-memory-limit \
--enable-bcmath \
--enable-shmop \
--enable-versioning \
--enable-calendar \
--enable-dbx \
--enable-dio \
--enable-mbstring \
--enable-mbstr-enc-trans
make install INSTALL_ROOT=/var/tmp2/php5_take2/targ
Previous Comments:
[2008-04-24 17:44:49] [EMAIL PROTECTED]
Next obvious question is: How did you build PHP? ie. What configure
line, etc. Also to eliminate every last moving parts: run the script
like this:
# php -n script.php
--------
[2008-04-24 17:23:47] twm at twmacinta dot com
Good idea. I modified my test script as suggested. Here's the output
on RHEL3 with the CVS snapshot php5.2-20080423123:
Before: 'Tim'\''s Test'
After: sh: line 1: /var/tmp2/php5_take2/targ/bin/Tim\s: No such file or
directory
In case you're wondering about the path, I set "./configure --prefix"
to "/var/tmp2/php5_take2/targ" so that I could install it there and test
it before overwriting my old PHP 4 installation. PHP 4 on the same
machine gives the same output as above, except that it's the usual
"/usr/bin/" path.
For comparison, here's the output on my other RHEL3 server which has
the latest, default version of PHP 4.3 from Red Hat:
Before: 'Tim'\''s Test'
After: sh: line 1: /usr/bin/'Tim'\''s: No such file or directory
I also ran the revised test on Mac OS X 10.5, which has PHP 5.2.5, to
get what is the correct output (i.e., what you got):
Before: 'Tim'\''s Test'
After: sh: Tim's Test: command not found
[2008-04-24 11:09:06] [EMAIL PROTECTED]
]$ php t.php
Before: 'Tim'\''s Test'
After: Tim's Test
So it works fine using latest CVS (for me).
You're using /bin/echo there, what if you simply do this:
That would eliminate one "moving part" here..
Just check the resulting error message what it has. :)
[2008-04-23 14:13:55] twm at twmacinta dot com
Thank you for the fast reply. I have tried the latest CVS snapshot
(php5.2-200804231230) and I still get the same incorrect output. It
sounds like some library in RHEL3 which
#44801 [Fbk->Opn]: Invalid escaping for passthru() in CLI
ID: 44801
User updated by: twm at twmacinta dot com
Reported By: twm at twmacinta dot com
-Status: Feedback
+Status: Open
Bug Type: CGI related
Operating System: Red Hat Enterprise Linux ES 3
PHP Version: 5.2.5
Assigned To: fb-req-jani
New Comment:
Good idea. I modified my test script as suggested. Here's the output
on RHEL3 with the CVS snapshot php5.2-20080423123:
Before: 'Tim'\''s Test'
After: sh: line 1: /var/tmp2/php5_take2/targ/bin/Tim\s: No such file or
directory
In case you're wondering about the path, I set "./configure --prefix"
to "/var/tmp2/php5_take2/targ" so that I could install it there and test
it before overwriting my old PHP 4 installation. PHP 4 on the same
machine gives the same output as above, except that it's the usual
"/usr/bin/" path.
For comparison, here's the output on my other RHEL3 server which has
the latest, default version of PHP 4.3 from Red Hat:
Before: 'Tim'\''s Test'
After: sh: line 1: /usr/bin/'Tim'\''s: No such file or directory
I also ran the revised test on Mac OS X 10.5, which has PHP 5.2.5, to
get what is the correct output (i.e., what you got):
Before: 'Tim'\''s Test'
After: sh: Tim's Test: command not found
Previous Comments:
[2008-04-24 11:09:06] [EMAIL PROTECTED]
]$ php t.php
Before: 'Tim'\''s Test'
After: Tim's Test
So it works fine using latest CVS (for me).
You're using /bin/echo there, what if you simply do this:
That would eliminate one "moving part" here..
Just check the resulting error message what it has. :)
[2008-04-23 14:13:55] twm at twmacinta dot com
Thank you for the fast reply. I have tried the latest CVS snapshot
(php5.2-200804231230) and I still get the same incorrect output. It
sounds like some library in RHEL3 which PHP uses is behaving differently
than on newer platforms.
If it helps, I have another server running the same version of RHEL3
which has the default version of PHP still on it (updated via
'up2date'), rather than one that I compiled. I know you don't support
PHP 4.3 any longer, I'm just pointing it out in case it helps to know
that this test case has been broken on RHEL3 for awhile, it's not a
problem unique to my compiled version, and the problem didn't just
appear in PHP 5.2. I do get slightly different output there, but it is
still incorrect.
[2008-04-23 00:58:25] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
This looks has been fixed. Works fine for me using 5.2.6-RC4.
[2008-04-22 19:16:55] twm at twmacinta dot com
Description:
When I run a PHP script which uses passthru() to execute a command with
characters that need escaping, the escaping is incorrect when the script
is run from the command line, but it is fine when the script is run from
within Apache. This was causing the script
"ext/standard/tests/file/bug22414.phpt" to fail when I attempted to run
"make test" after building PHP 5.2.5 on RHEL3. I have created a
simplified script for this report to demonstrate the problem, though I
will note that I can also reproduce it reliably with "bug22414.phpt".
I should mention that I also tried my test script from the command line
in Mac OS X 10.5 running PHP 5.2.5 and Ubuntu 7.10 running PHP 5.2.3 and
it worked correctly in both cases. So, my suspicion is that there is an
older library on RHEL3 which is causing the parsing the be incorrect.
It passes all the requirements checks made by './configure', though.
I ran the test code below using the '-n' option to PHP so as to
eliminate my "php.ini" as the problem.
Reproduce code:
---
header("Content-Type: text/plain");
$textEscaped = escapeshellarg("Tim's Test");
print("Before: {$textEscaped}\n");
print("After: ");
passthru("/bin/echo {$textEscaped}");
Expected result:
Before: 'Tim'\''s Test'
After: Tim's Test
Actual result:
--
Before: 'Tim'\''s Test'
After: Tim\s Test'
--
Edit this bug report at http://bugs.php.net/?id=44801&edit=1
#44801 [Fbk->Opn]: Invalid escaping for passthru() in CLI
ID: 44801
User updated by: twm at twmacinta dot com
Reported By: twm at twmacinta dot com
-Status: Feedback
+Status: Open
Bug Type: CGI related
Operating System: Red Hat Enterprise Linux ES 3
PHP Version: 5.2.5
New Comment:
Thank you for the fast reply. I have tried the latest CVS snapshot
(php5.2-200804231230) and I still get the same incorrect output. It
sounds like some library in RHEL3 which PHP uses is behaving differently
than on newer platforms.
If it helps, I have another server running the same version of RHEL3
which has the default version of PHP still on it (updated via
'up2date'), rather than one that I compiled. I know you don't support
PHP 4.3 any longer, I'm just pointing it out in case it helps to know
that this test case has been broken on RHEL3 for awhile, it's not a
problem unique to my compiled version, and the problem didn't just
appear in PHP 5.2. I do get slightly different output there, but it is
still incorrect.
Previous Comments:
[2008-04-23 00:58:25] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
This looks has been fixed. Works fine for me using 5.2.6-RC4.
--------
[2008-04-22 19:16:55] twm at twmacinta dot com
Description:
When I run a PHP script which uses passthru() to execute a command with
characters that need escaping, the escaping is incorrect when the script
is run from the command line, but it is fine when the script is run from
within Apache. This was causing the script
"ext/standard/tests/file/bug22414.phpt" to fail when I attempted to run
"make test" after building PHP 5.2.5 on RHEL3. I have created a
simplified script for this report to demonstrate the problem, though I
will note that I can also reproduce it reliably with "bug22414.phpt".
I should mention that I also tried my test script from the command line
in Mac OS X 10.5 running PHP 5.2.5 and Ubuntu 7.10 running PHP 5.2.3 and
it worked correctly in both cases. So, my suspicion is that there is an
older library on RHEL3 which is causing the parsing the be incorrect.
It passes all the requirements checks made by './configure', though.
I ran the test code below using the '-n' option to PHP so as to
eliminate my "php.ini" as the problem.
Reproduce code:
---
header("Content-Type: text/plain");
$textEscaped = escapeshellarg("Tim's Test");
print("Before: {$textEscaped}\n");
print("After: ");
passthru("/bin/echo {$textEscaped}");
Expected result:
Before: 'Tim'\''s Test'
After: Tim's Test
Actual result:
--
Before: 'Tim'\''s Test'
After: Tim\s Test'
--
Edit this bug report at http://bugs.php.net/?id=44801&edit=1
#44801 [NEW]: Invalid escaping for passthru() in CLI
From: twm at twmacinta dot com
Operating system: Red Hat Enterprise Linux ES 3
PHP version: 5.2.5
PHP Bug Type: CGI related
Bug description: Invalid escaping for passthru() in CLI
Description:
When I run a PHP script which uses passthru() to execute a command with
characters that need escaping, the escaping is incorrect when the script is
run from the command line, but it is fine when the script is run from
within Apache. This was causing the script
"ext/standard/tests/file/bug22414.phpt" to fail when I attempted to run
"make test" after building PHP 5.2.5 on RHEL3. I have created a simplified
script for this report to demonstrate the problem, though I will note that
I can also reproduce it reliably with "bug22414.phpt".
I should mention that I also tried my test script from the command line in
Mac OS X 10.5 running PHP 5.2.5 and Ubuntu 7.10 running PHP 5.2.3 and it
worked correctly in both cases. So, my suspicion is that there is an older
library on RHEL3 which is causing the parsing the be incorrect. It passes
all the requirements checks made by './configure', though.
I ran the test code below using the '-n' option to PHP so as to eliminate
my "php.ini" as the problem.
Reproduce code:
---
header("Content-Type: text/plain");
$textEscaped = escapeshellarg("Tim's Test");
print("Before: {$textEscaped}\n");
print("After: ");
passthru("/bin/echo {$textEscaped}");
Expected result:
Before: 'Tim'\''s Test'
After: Tim's Test
Actual result:
--
Before: 'Tim'\''s Test'
After: Tim\s Test'
--
Edit bug report at http://bugs.php.net/?id=44801&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44801&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44801&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44801&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44801&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44801&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44801&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44801&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44801&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44801&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44801&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44801&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44801&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44801&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44801&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44801&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44801&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44801&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44801&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44801&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44801&r=mysqlcfg
#36793 [WFx]: Some objects become corrupted after 32767 instantiations
ID: 36793 User updated by: twm at twmacinta dot com Reported By: twm at twmacinta dot com Status: Wont fix Bug Type: Scripting Engine problem Operating System: RHEL ES 3 update 7 PHP Version: 4.4.2 New Comment: Hello, OK, thanks for letting me know. Could you give me more information on what the core problem is so that I can try to avoid it? Thanks, - Tim Macinta Previous Comments: [2006-03-20 00:17:24] [EMAIL PROTECTED] Sorry, won't get fixed for PHP-4. [2006-03-20 00:05:14] twm at twmacinta dot com Description: Hello, I have a set of two classes which are used together and which work fine initially but which result in memory corruption after being instantiated 32767 times. I have attached the URL of a sample script which demonstrates the problem since I wasn't able to reproduce it in 20 lines or less. I ran the program through Valgrind to see if it could ferret out more specifics, but it didn't report any errors. Thanks, - Tim Macinta Reproduce code: --- http://www.twmacinta.com/php_bugs/object_corruption_20060319.php.txt Expected result: Start Middle: 0 Middle: 1 Middle: 2 Middle: 3 ... Middle: 999 End Actual result: -- Start Middle: 0 Middle: 1 Middle: 2 Middle: 3 Middle: 32761 Middle: 32762 Middle: 32763 Middle: 32764 Middle: 32765 Middle: 32766 foo was not defined -- Edit this bug report at http://bugs.php.net/?id=36793&edit=1
#36793 [NEW]: Some objects become corrupted after 32767 instantiations
From: twm at twmacinta dot com Operating system: RHEL ES 3 update 7 PHP version: 4.4.2 PHP Bug Type: Scripting Engine problem Bug description: Some objects become corrupted after 32767 instantiations Description: Hello, I have a set of two classes which are used together and which work fine initially but which result in memory corruption after being instantiated 32767 times. I have attached the URL of a sample script which demonstrates the problem since I wasn't able to reproduce it in 20 lines or less. I ran the program through Valgrind to see if it could ferret out more specifics, but it didn't report any errors. Thanks, - Tim Macinta Reproduce code: --- http://www.twmacinta.com/php_bugs/object_corruption_20060319.php.txt Expected result: Start Middle: 0 Middle: 1 Middle: 2 Middle: 3 ... Middle: 999 End Actual result: -- Start Middle: 0 Middle: 1 Middle: 2 Middle: 3 Middle: 32761 Middle: 32762 Middle: 32763 Middle: 32764 Middle: 32765 Middle: 32766 foo was not defined -- Edit bug report at http://bugs.php.net/?id=36793&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36793&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36793&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36793&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36793&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36793&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36793&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36793&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36793&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36793&r=support Expected behavior:http://bugs.php.net/fix.php?id=36793&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36793&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36793&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36793&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36793&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36793&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36793&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36793&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36793&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36793&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36793&r=mysqlcfg
