#41546 [NEW]: Is_callable() function behavior incorrect in PHP5.
From: mahesh dot vemula at in dot ibm dot com
Operating system: RHEL4
PHP version: 5.2.2
PHP Bug Type: Strings related
Bug description: Is_callable() function behavior incorrect in PHP5.
Description:
In the below testcode, PHP5 PHP6 outputs differ for is_callable()
function.
In PHP6 when we are echo-ing a string( eg. welcome\0 ) with null
character at the end of the string, the output with run-tests shows null
character also at the end of the string.
Whereas, running the file with php5.2.2 gives the expected output ( i.e
welcome).
is_callable() function in PHP 5 is incorrectly truncating the name passed
when it calls ZVAL_STRING, i.e it should be possible to have function
names with embedded nulls.
The behavior on PHP6 looks be correct.
This is consistent with the expected behaviour after reading Sarah
Goleman's book; page 25. It says:
What's worth noting about PHP string is that the length of the string is
always explicitly stated in the zval structure. This allows strings to
contain NULL bytes without being truncated. This aspect of PHP strings will
be referred to hereafter as binary safety because it makes it safe to
contain any type of binary data.
Reproduce code:
---
?php
$undef_functions = array (
\0,
'\0',
welcome\0,
'welcome\0',
);
$counter = 1;
foreach($undef_functions as $func) {
echo -- Iteration $counter --\n;
var_dump( is_callable($func, FALSE, $callable_name) );
echo $callable_name, \n;
$counter++;
}
echo done;
?
Expected result:
-- Iteration 1 --
bool(false)
_
-- Iteration 2 --
bool(false)
\0
-- Iteration 3 --
bool(false)
welcome_
-- Iteration 4 --
bool(false)
welcome\0
done
Actual result:
--
-- Iteration 1 --
bool(false)
-- Iteration 2 --
bool(false)
\0
-- Iteration 3 --
bool(false)
welcome
-- Iteration 4 --
bool(false)
welcome\0
done
--
Edit bug report at http://bugs.php.net/?id=41546edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41546r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41546r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41546r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41546r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41546r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41546r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41546r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41546r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41546r=support
Expected behavior:http://bugs.php.net/fix.php?id=41546r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41546r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41546r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41546r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41546r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41546r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41546r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41546r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41546r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41546r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41546r=mysqlcfg
#41350 [Com]: Error in my_thread_global_end()
ID: 41350 Comment by: louis at steelbytes dot com Reported By: graham at directhostinguk dot com Status: Assigned Bug Type: MySQL related Operating System: Windows 2003 PHP Version: 5.2.2 Assigned To: georg New Comment: repro on win2k3. reverting libmysql.dll to 5.2.1 fixes it. Previous Comments: [2007-05-29 17:04:40] php at stock-consulting dot com I receive the message as well, when running PHP 5.2.2 from the command line, so definitely no IIS-related issue. The php_mysql.dll is loaded as an extension, but no functions from the library are called by the application, so most likely no MySQL issue. The message appeared after the PHP version update; no MySQL update was performed. A clear indication, IMHO, the something went wrong on the PHP side. [2007-05-18 10:30:33] e_remove_paine at lastfrontiers dot com With PHP5.2.2, and MySQL5.0.41 under Windows XP (IIS5.1) I can reproduce this by simply creating a normal html page (no php tags) with a .php extension. Error in my_thread_global_end(): 1 threads didn't exit [2007-05-14 01:36:28] sptong at hotmail dot com I have upgraded to PHP 5.2.2. I cfm that using libmysql.dll from 5.2.1, instead of 5.2.2 solved the pbm. Or rather, the error does not show up again. [2007-05-13 15:35:22] paul at orac dot clara dot co dot uk This IS a bug - it is in the libmysql.dll library. If you replace the copy from 5.2.2 with the one from 5.2.1, then the problem goes away. That guy [EMAIL PROTECTED] says that the error message is not in PHP. He might be right about that, but that doesn't mean the PHP isn't the cause of it, which it quite clearly is. Closing bugs without any discussion doesn't help the situation either. [2007-05-10 12:12:10] graham at directhostinguk dot com Description: This closed PHP bug: http://bugs.php.net/bug.php?id=41316 MySQL Bug: http://bugs.mysql.com/bug.php?id=25621 Error in my_thread_global_end(): 1 threads didn't exit I have the same issue even when the script doesn't call any MySQL, but this error only happens when using fast-cgi If I run php 5.2.2 ISAPI the problem goes away. I think this is a php bug It seems to me that the problem lies in the PHP dll php_mysql.dll as it is opening the threads but not telling MySql to close them. -- Edit this bug report at http://bugs.php.net/?id=41350edit=1
#41510 [Bgs]: open_basedir restriction in effect. File(/var/tmp/)
ID: 41510
Updated by: [EMAIL PROTECTED]
Reported By: damian at 1do1 dot pl
Status: Bogus
Bug Type: Session related
Operating System: FreeBSD 5.5
PHP Version: 4.4.7
New Comment:
session.save_path in php.ini is what it is. If you want to use that,
don't call session_save_path() at all.
Previous Comments:
[2007-05-27 18:23:47] damian at 1do1 dot pl
OK. How can I change this default path?
So what for is 'session.save_path' in PHP.INI now?
[2007-05-27 17:45:39] [EMAIL PROTECTED]
If that worked in 4.4.4, it was bug that got fixed.
If you set the save path to '' (empty string), default tmp path will be
used which is /var/tmp in your system. This is not any bug.
[2007-05-27 17:06:03] damian at 1do1 dot pl
It worked on PHP 4.4.4.
In ini session.save_path is set to /home/var/tmp so why the script is
trying to save in /var/tmp?
File(/var/tmp/) is not within the allowed
path(s):
[2007-05-27 14:36:53] [EMAIL PROTECTED]
What is the point of this in your reproduce script:
define('SESSION_DIR', '');
session_save_path(SESSION_DIR);
???
Of course that won't work. Why should it?
And are there by any chance any symlinks in the /home/var/tmp path?
[2007-05-27 08:19:38] damian at 1do1 dot pl
Description:
Hello,
After upgrade from PHP 4.4.4 to 4.4.7 I am having this error in my
aplication i've read that this bug was fixed but I think something is
wrong.
I have all set in my ini
open_basedir = /home
session.save_path = /home/var/tmp
I haven't change anything only upgrade and everything crush.
Reproduce code:
---
$sessionpath = session_save_path();
define('SESSION_DIR', '');
session_save_path(SESSION_DIR);
session_name('test');
session_start();
echo 'brsession_save_path - ' .$sessionpath;
Actual result:
--
Warning: session_start() [function.session-start]: open_basedir
restriction in effect. File(/var/tmp/) is not within the allowed
path(s): (/home) in /usr/home/xxx/public_html/test.php on line 8
Fatal error: session_start() [a
href='function.session-start'function.session-start/a]: Failed to
initialize storage module: files (path: ) in
/usr/home/xxx/public_html/test.php on line 8
--
Edit this bug report at http://bugs.php.net/?id=41510edit=1
#41545 [Opn-Fbk]: Mhash extension SegFaults on MD5 algorithm
ID: 41545 Updated by: [EMAIL PROTECTED] Reported By: wdierkes at 5dollarwhitebox dot org -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Redhat Enterprise Linux ES 3 PHP Version: 5.2.2 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. Previous Comments: [2007-05-30 23:53:41] wdierkes at 5dollarwhitebox dot org The problem does not exist when php-ldap extension is *not* loaded. unloading ldap from the running PHP fixes the problem. [2007-05-30 22:04:47] wdierkes at 5dollarwhitebox dot org Description: The Mhash extension SegFaults on Redhat Enterprise Linux ES 3 when using the MD5 algorithm. All other algorithms seem to work except MD5. NOTE: This appears to possibly be related to bug #30983 which is closed (and I could not touch it). In that bug, it was claimed to 'not imply a bug in PHP itself'. This may be true, however similar tests against the Mhash library itself using C code function as expected. I ran the same test against the Mhash library using the following C code located here: http://www.5dollarwhitebox.org/tmp/mhash_test.c You must install the Mhash library obviously, then compile and run the test file: [EMAIL PROTECTED] ~]$ gcc -lmhash -o mhash_test mhash_test.c [EMAIL PROTECTED] ~]$ ./mhash_test The issue exists on Rhel3 i386/x86_64, but does *not* exist on Rhel4.. and I am using Mhash-0.9.9 Reproduce code: --- PHP Code: ?php $input = PassW0rd; print clear text input: . $input . \n; $tmp_hash_name = mhash_get_hash_name(MHASH_MD5); print hash name: . $tmp_hash_name . \n; print hash follows: ; print bin2hex(mhash(MHASH_MD5, $input)) . \n; ? Expected result: Expected PHP Output: [EMAIL PROTECTED] ~]$ php mhash_test.php clear text input: PassW0rd hash name: MD5 hash follows: 298cde70c32a57b84d0a546fedbb2596 Actual result: -- Actual PHP Output: [EMAIL PROTECTED] ~/]$ php mhash_test.php clear text input: PassW0rd hash name: MD5 hash follows: Segmentation fault -- Edit this bug report at http://bugs.php.net/?id=41545edit=1
#41547 [NEW]: strtotiem bug
From: noisex at apollo dot lv
Operating system: FreeBSD 6.2
PHP version: 5.2.2
PHP Bug Type: Date/time related
Bug description: strtotiem bug
Description:
On months with 31th day the strtotime function with +/-$foo month
calculates wrong. it calculates -30 days not 31 days.
Reproduce code:
---
Simple example (running today 31 May):
?php
for($i=1; $i=12; $i++) {
echo date(Y-M,strtotime(-$i months)).br;
}
?
Expected result:
2007-Mar
2007-Feb
2007-Jan
2006-Dec
2006-Nov
2006-Oct
2006-Sep
2006-Aug
2006-Jul
2006-Jun
2006-May
2006-Apr
Actual result:
--
2007-May
2007-Mar
2007-Mar
2007-Jan
2006-Dec
2006-Dec
2006-Oct
2006-Oct
2006-Aug
2006-Jul
2006-Jul
2006-May
--
Edit bug report at http://bugs.php.net/?id=41547edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41547r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41547r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41547r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41547r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41547r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41547r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41547r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41547r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41547r=support
Expected behavior:http://bugs.php.net/fix.php?id=41547r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41547r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41547r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41547r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41547r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41547r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41547r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41547r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41547r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41547r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41547r=mysqlcfg
#41547 [Opn]: strtotime bug
ID: 41547
User updated by: noisex at apollo dot lv
-Summary: strtotiem bug
Reported By: noisex at apollo dot lv
Status: Open
Bug Type: Date/time related
Operating System: FreeBSD 6.2
PHP Version: 5.2.2
New Comment:
The result must be (sorry):
2007-Apr
2007-Mar
2007-Feb
2007-Jan
2006-Dec
2006-Nov
2006-Oct
2006-Sep
2006-Aug
2006-Jul
2006-Jun
2006-May
Previous Comments:
[2007-05-31 09:21:33] noisex at apollo dot lv
Description:
On months with 31th day the strtotime function with +/-$foo month
calculates wrong. it calculates -30 days not 31 days.
Reproduce code:
---
Simple example (running today 31 May):
?php
for($i=1; $i=12; $i++) {
echo date(Y-M,strtotime(-$i months)).br;
}
?
Expected result:
2007-Mar
2007-Feb
2007-Jan
2006-Dec
2006-Nov
2006-Oct
2006-Sep
2006-Aug
2006-Jul
2006-Jun
2006-May
2006-Apr
Actual result:
--
2007-May
2007-Mar
2007-Mar
2007-Jan
2006-Dec
2006-Dec
2006-Oct
2006-Oct
2006-Aug
2006-Jul
2006-Jul
2006-May
--
Edit this bug report at http://bugs.php.net/?id=41547edit=1
#41547 [Opn-Bgs]: strtotime bug
ID: 41547
Updated by: [EMAIL PROTECTED]
Reported By: noisex at apollo dot lv
-Status: Open
+Status: Bogus
Bug Type: Date/time related
Operating System: FreeBSD 6.2
PHP Version: 5.2.2
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Your are incorrect in your assessment. The +-n months statement goes
back one month. Back from May 31st that becomes April 31st. As April
only has 30 days this turns into May 1st. The same is true February,
which only has 28 days, so the result is March 3rd. See the following
script:
?php
for($i=1; $i=12; $i++) {
echo date(Y-M-d H:i:s,strtotime(-$i months)).br/\n;
}
?
Previous Comments:
[2007-05-31 09:25:19] noisex at apollo dot lv
The result must be (sorry):
2007-Apr
2007-Mar
2007-Feb
2007-Jan
2006-Dec
2006-Nov
2006-Oct
2006-Sep
2006-Aug
2006-Jul
2006-Jun
2006-May
[2007-05-31 09:21:33] noisex at apollo dot lv
Description:
On months with 31th day the strtotime function with +/-$foo month
calculates wrong. it calculates -30 days not 31 days.
Reproduce code:
---
Simple example (running today 31 May):
?php
for($i=1; $i=12; $i++) {
echo date(Y-M,strtotime(-$i months)).br;
}
?
Expected result:
2007-Mar
2007-Feb
2007-Jan
2006-Dec
2006-Nov
2006-Oct
2006-Sep
2006-Aug
2006-Jul
2006-Jun
2006-May
2006-Apr
Actual result:
--
2007-May
2007-Mar
2007-Mar
2007-Jan
2006-Dec
2006-Dec
2006-Oct
2006-Oct
2006-Aug
2006-Jul
2006-Jul
2006-May
--
Edit this bug report at http://bugs.php.net/?id=41547edit=1
#41548 [Opn]: Fail to load php_mysql.dll and php_mysqli.dll
ID: 41548 User updated by: mercury__99 at hotmail dot com -Summary: Fail to load php_mysql.dll. Can load php_mssql.dll and php_oci8.dll. Reported By: mercury__99 at hotmail dot com Status: Open Bug Type: MySQL related Operating System: Windows XP SP2 PHP Version: 5.2.2 New Comment: This is an obvious bug in PHP 5.2.2 Previous Comments: [2007-05-31 09:53:53] mercury__99 at hotmail dot com Description: Here is a portion of php.ini - ;extension=php_msql.dll extension=php_mssql.dll extension=php_mysql.dll extension=php_mysqli.dll extension=php_oci8.dll ;extension=php_openssl.dll after restarting apache, in phpinfo(); I got everything loaded EXCEPT: extension=php_mysql.dll and extension=php_mysqli.dll -- Edit this bug report at http://bugs.php.net/?id=41548edit=1
#41548 [Opn-Bgs]: Fail to load php_mysql.dll and php_mysqli.dll
ID: 41548 Updated by: [EMAIL PROTECTED] Reported By: mercury__99 at hotmail dot com -Status: Open +Status: Bogus Bug Type: MySQL related Operating System: Windows XP SP2 PHP Version: 5.2.2 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Most likely your libmysql.dll is not in place. Previous Comments: [2007-05-31 09:56:48] mercury__99 at hotmail dot com This is an obvious bug in PHP 5.2.2 [2007-05-31 09:53:53] mercury__99 at hotmail dot com Description: Here is a portion of php.ini - ;extension=php_msql.dll extension=php_mssql.dll extension=php_mysql.dll extension=php_mysqli.dll extension=php_oci8.dll ;extension=php_openssl.dll after restarting apache, in phpinfo(); I got everything loaded EXCEPT: extension=php_mysql.dll and extension=php_mysqli.dll -- Edit this bug report at http://bugs.php.net/?id=41548edit=1
#41548 [NEW]: Fail to load php_mysql.dll. Can load php_mssql.dll and php_oci8.dll.
From: mercury__99 at hotmail dot com Operating system: Windows XP SP2 PHP version: 5.2.2 PHP Bug Type: MySQL related Bug description: Fail to load php_mysql.dll. Can load php_mssql.dll and php_oci8.dll. Description: Here is a portion of php.ini - ;extension=php_msql.dll extension=php_mssql.dll extension=php_mysql.dll extension=php_mysqli.dll extension=php_oci8.dll ;extension=php_openssl.dll after restarting apache, in phpinfo(); I got everything loaded EXCEPT: extension=php_mysql.dll and extension=php_mysqli.dll -- Edit bug report at http://bugs.php.net/?id=41548edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41548r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41548r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41548r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=41548r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=41548r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=41548r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=41548r=needscript Try newer version:http://bugs.php.net/fix.php?id=41548r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=41548r=support Expected behavior:http://bugs.php.net/fix.php?id=41548r=notwrong Not enough info: http://bugs.php.net/fix.php?id=41548r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=41548r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=41548r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41548r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=41548r=dst IIS Stability:http://bugs.php.net/fix.php?id=41548r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=41548r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=41548r=float No Zend Extensions: http://bugs.php.net/fix.php?id=41548r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=41548r=mysqlcfg
#41518 [Opn-Fbk]: file_exists() warns of open_basedir restriction on non-existent file
ID: 41518
Updated by: [EMAIL PROTECTED]
Reported By: ruben dot willmes at emil2001 dot de
-Status: Open
+Status: Feedback
Bug Type: Safe Mode/open_basedir
Operating System: Linux
PHP Version: 5.2.2
New Comment:
I don't think I get what you're talking about:
# ls -l /tmp/nosuch
ls: cannot access /tmp/nosuch: No such file or directory
#php -d open_basedir=/tmp -r 'var_dump(file_exists(/tmp/nosuch));'
bool(false)
No warning whatsoever.
Previous Comments:
[2007-05-30 20:20:58] ruben dot willmes at emil2001 dot de
Sorry, but i have to reopen this bug again.
Thx for the reply, Tony, but i don't think you understood me.
I don't want to generally remove this error message, it's just under
your OWN open_basedir, where you shouldn't get this message since
you should be able to check whether the file exists under your OWN
open_basedir, or am i wrong?
Let's make an example:
Two users, user1 and user2, both locked in their homedirs with
open_basedir:
/home/user1/
/home/user2/
Both have one file in their directory, let's call it test.php
Now, if user1 checks whether test.php exists, he get's a true, as
well as user2. If user1 checks user2's test.php, he'll get a false
and an open_basedir warning since he's out of his open_basedir.
That's correct.
But what if user1 checks a file called test2.php under his own
directory, /home/user1/? Should he get an open_basedir error? In my
eyes he should only get a 'false' as the file does not exist, but no
open_basedir warning, since he's still in his own open_basedir.
In the recent PHP5 release (5.2.2) one get's an open_basedir warning
if you check a non-existent file under your OWN open_basedir. In a
previous release the message was not present (i think it was 5.2.0
or 5.2.1).
so, please reconsider this bug
[2007-05-29 20:39:47] [EMAIL PROTECTED]
If we remove this warning for non-existent files, it could be possible
to use file_exists() to detect which files exists (since it's perfectly
legal to print this warning when the file exists).
[2007-05-29 06:58:06] ruben dot willmes at emil2001 dot de
You're right, it does work correctly if i set my open_basedir to
'/var/
www/localhost/htdocs' (without the trailing slash). But if i set it to
'/var/www/localhost/htdocs/' (with the trailing slash), it doesn't work
in my test case. Could you please try it once more setting your
open_basedir to '/www/home/user/' (with the trailing slash)?
The system this is running on is PHP 5.2.2, with Apache 2.0.58.
thx in advance
[2007-05-28 22:09:25] xeo2001 at yahoo dot com
Ow. i forgot to mantion that the server also runs php 5 and 6. While
only tested in php 4 and 5.
[2007-05-28 22:05:11] xeo2001 at yahoo dot com
I have to disagree with you.
I'v set a open base dir as /www/home/user and when i open (the by you
produced code) in /www/home/user/test.php as:
?
if (is_file('/www/home/user/index.phph')) {
print File exists;
}else {
print File does not exist;
}
?
I just get the text File does not exist. I think you got a problem in
your server configuration?
Running system(s):
Debian 4.1
Apache 1.3.37
Php 4.4.7
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/41518
--
Edit this bug report at http://bugs.php.net/?id=41518edit=1
#39330 [Asn]: apache2handler does not call shutdown actions before apache child die
ID: 39330
Updated by: [EMAIL PROTECTED]
Reported By: isk at ecommerce dot com
Status: Assigned
Bug Type: Apache2 related
Operating System: Linux
PHP Version: 5.1.6
-Assigned To: iliaa
+Assigned To: tony2001
New Comment:
I'll commit the patch after 5.2.3 release.
Previous Comments:
[2006-11-01 13:16:08] isk at ecommerce dot com
Description:
apache2handler sapi registers cleanup functions only for
main apache process.
php_apache_server_startup(){
...
apr_pool_cleanup_register(pconf, NULL,
php_apache_server_shutdown, apr_pool_cleanup_null);
...
}
The pconf is main apache process pool. But apache 2 cleans
_only_ child pool before it die.
apache2handler must register cleanup function and for
child pool. This can be fixed by several strings.
sapi/apache2handler/sapi_apache2.c:
static void php_apache_child_init(apr_pool_t *pchild,
server_rec *s)
{
apr_pool_cleanup_register(pchild, NULL,
php_apache_server_shutdown, apr_pool_cleanup_null);
}
void php_ap2_register_hook(apr_pool_t *p)
{
...
ap_hook_child_init(php_apache_child_init, NULL, NULL,
APR_HOOK_MIDDLE);
}
Without this code the using persistent connection has
problem in unclean close connection to DB after apache
child die.
--
Edit this bug report at http://bugs.php.net/?id=39330edit=1
#39330 [Asn]: apache2handler does not call shutdown actions before apache child die
ID: 39330
Updated by: [EMAIL PROTECTED]
Reported By: isk at ecommerce dot com
Status: Assigned
Bug Type: Apache2 related
Operating System: Linux
PHP Version: 5.1.6
Assigned To: tony2001
New Comment:
Bug confirmed and patch does work as said.
Previous Comments:
[2007-05-31 11:40:57] [EMAIL PROTECTED]
I'll commit the patch after 5.2.3 release.
[2006-11-01 13:16:08] isk at ecommerce dot com
Description:
apache2handler sapi registers cleanup functions only for
main apache process.
php_apache_server_startup(){
...
apr_pool_cleanup_register(pconf, NULL,
php_apache_server_shutdown, apr_pool_cleanup_null);
...
}
The pconf is main apache process pool. But apache 2 cleans
_only_ child pool before it die.
apache2handler must register cleanup function and for
child pool. This can be fixed by several strings.
sapi/apache2handler/sapi_apache2.c:
static void php_apache_child_init(apr_pool_t *pchild,
server_rec *s)
{
apr_pool_cleanup_register(pchild, NULL,
php_apache_server_shutdown, apr_pool_cleanup_null);
}
void php_ap2_register_hook(apr_pool_t *p)
{
...
ap_hook_child_init(php_apache_child_init, NULL, NULL,
APR_HOOK_MIDDLE);
}
Without this code the using persistent connection has
problem in unclean close connection to DB after apache
child die.
--
Edit this bug report at http://bugs.php.net/?id=39330edit=1
#41518 [Fbk-Opn]: file_exists() warns of open_basedir restriction on non-existent file
ID: 41518 User updated by: ruben dot willmes at emil2001 dot de Reported By: ruben dot willmes at emil2001 dot de -Status: Feedback +Status: Open Bug Type: Safe Mode/open_basedir Operating System: Linux PHP Version: 5.2.2 New Comment: Your example is correct, that does work, but what if you change the following: Instead of #php -d open_basedir=/tmp -r 'var_dump(file_exists(/tmp/nosuch));' try #php -d open_basedir=/tmp/ -r 'var_dump(file_exists(/tmp/nosuch));' Notice the slash behind open_basedir=/tmp/. With that you get Warning: file_exists(): open_basedir restriction in effect. File(/tmp/ nosuch) is not within the allowed path(s): (/tmp/) in Command line code on line 1 bool(false) Previous Comments: [2007-05-31 11:06:13] [EMAIL PROTECTED] I don't think I get what you're talking about: # ls -l /tmp/nosuch ls: cannot access /tmp/nosuch: No such file or directory #php -d open_basedir=/tmp -r 'var_dump(file_exists(/tmp/nosuch));' bool(false) No warning whatsoever. [2007-05-30 20:20:58] ruben dot willmes at emil2001 dot de Sorry, but i have to reopen this bug again. Thx for the reply, Tony, but i don't think you understood me. I don't want to generally remove this error message, it's just under your OWN open_basedir, where you shouldn't get this message since you should be able to check whether the file exists under your OWN open_basedir, or am i wrong? Let's make an example: Two users, user1 and user2, both locked in their homedirs with open_basedir: /home/user1/ /home/user2/ Both have one file in their directory, let's call it test.php Now, if user1 checks whether test.php exists, he get's a true, as well as user2. If user1 checks user2's test.php, he'll get a false and an open_basedir warning since he's out of his open_basedir. That's correct. But what if user1 checks a file called test2.php under his own directory, /home/user1/? Should he get an open_basedir error? In my eyes he should only get a 'false' as the file does not exist, but no open_basedir warning, since he's still in his own open_basedir. In the recent PHP5 release (5.2.2) one get's an open_basedir warning if you check a non-existent file under your OWN open_basedir. In a previous release the message was not present (i think it was 5.2.0 or 5.2.1). so, please reconsider this bug [2007-05-29 20:39:47] [EMAIL PROTECTED] If we remove this warning for non-existent files, it could be possible to use file_exists() to detect which files exists (since it's perfectly legal to print this warning when the file exists). [2007-05-29 06:58:06] ruben dot willmes at emil2001 dot de You're right, it does work correctly if i set my open_basedir to '/var/ www/localhost/htdocs' (without the trailing slash). But if i set it to '/var/www/localhost/htdocs/' (with the trailing slash), it doesn't work in my test case. Could you please try it once more setting your open_basedir to '/www/home/user/' (with the trailing slash)? The system this is running on is PHP 5.2.2, with Apache 2.0.58. thx in advance [2007-05-28 22:09:25] xeo2001 at yahoo dot com Ow. i forgot to mantion that the server also runs php 5 and 6. While only tested in php 4 and 5. 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/41518 -- Edit this bug report at http://bugs.php.net/?id=41518edit=1
#41549 [NEW]: Object to String convert
From: nikolai dot essel at maxworx dot com
Operating system: Windows XP SP2
PHP version: 5.2.2
PHP Bug Type: Class/Object related
Bug description: Object to String convert
Description:
After updating from PHP 5.1.6 some scripts didn´t work.
Problem is the standard behavior from casting objects into strings without
an explicit defined __toString() method
Reproduce code:
---
?php
class test
{
private $var = test;
public function __construct() {}
}
$object = new test();
echo $object;
?
Expected result:
Object id #1
Actual result:
--
Catchable fatal error: Object of class test could not be converted to
string in C:\xampp\htdocs\classtest.php on line 9
--
Edit bug report at http://bugs.php.net/?id=41549edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41549r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41549r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41549r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41549r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41549r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41549r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41549r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41549r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41549r=support
Expected behavior:http://bugs.php.net/fix.php?id=41549r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41549r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41549r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41549r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41549r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41549r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41549r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41549r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41549r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41549r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41549r=mysqlcfg
#41549 [Opn-Bgs]: Object to String convert
ID: 41549
Updated by: [EMAIL PROTECTED]
Reported By: nikolai dot essel at maxworx dot com
-Status: Open
+Status: Bogus
Bug Type: Class/Object related
Operating System: Windows XP SP2
PHP Version: 5.2.2
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
.
Previous Comments:
[2007-05-31 13:02:07] nikolai dot essel at maxworx dot com
Description:
After updating from PHP 5.1.6 some scripts didn´t work.
Problem is the standard behavior from casting objects into strings
without an explicit defined __toString() method
Reproduce code:
---
?php
class test
{
private $var = test;
public function __construct() {}
}
$object = new test();
echo $object;
?
Expected result:
Object id #1
Actual result:
--
Catchable fatal error: Object of class test could not be converted to
string in C:\xampp\htdocs\classtest.php on line 9
--
Edit this bug report at http://bugs.php.net/?id=41549edit=1
#41531 [Asn]: [PATCH] apache and apache_hooks config.w32 incorrect
ID: 41531
User updated by: auroraeosrose at gmail dot com
Reported By: auroraeosrose at gmail dot com
Status: Assigned
Bug Type: Compile Failure
Operating System: WinXPSP2
PHP Version: 5CVS-2007-05-29 (snap)
Assigned To: edink
New Comment:
bugs.php.net needs a real patch system - here's a link to the patch
hthttp://perisama.net/patches/bug-41531.patch
Previous Comments:
[2007-05-30 02:26:09] auroraeosrose at gmail dot com
Second part of that patch has an error, sorry
Index: apache_hooks/config.w32
===
RCS file: /repository/php-src/sapi/apache_hooks/config.w32,v
retrieving revision 1.2
diff -u -r1.2 config.w32
--- apache_hooks/config.w32 17 Jan 2004 13:00:08 - 1.2
+++ apache_hooks/config.w32 30 May 2007 02:20:28 -
@@ -6,10 +6,10 @@
if (PHP_APACHE_HOOKS != no) {
if (CHECK_HEADER_ADD_INCLUDE(httpd.h, CFLAGS_APACHE_HOOKS,
php_usual_include_suspects +
; + PROGRAM_FILES + \\Apache
Group\\Apache\\include +
- ;..\\php_build\\apache\\src\\include)
+ ; + PHP_PHP_BUILD + \\apache\\src\\include)
CHECK_LIB(ApacheCore.lib, apache_hooks,
php_usual_lib_suspects
+
';' + PROGRAM_FILES + '\\Apache
Group\\Apache\\libexec' +
- ';..\\php_build\\apache\\src\\corer')) {
+ ';' + PHP_PHP_BUILD + '\\apache\\src\\corer')) {
// We need to play tricks to get our readdir.h used by apache
// headers
SAPI('apache_hooks', 'mod_php5.c sapi_apache.c php_apache.c',
[2007-05-29 19:50:40] auroraeosrose at gmail dot com
Description:
apache and apache_hooks sapis have the location of their libraries
hardcoded using ../php_build instead of using the PHP_PHP_BUILD
variable, so detecting libraries when --with-php-build is used fails -
patches to fix this error below
Reproduce code:
---
Index: apache/config.w32
===
RCS file: /repository/php-src/sapi/apache/config.w32,v
retrieving revision 1.7
diff -u -r1.7 config.w32
--- apache/config.w32 17 Jan 2004 13:00:04 - 1.7
+++ apache/config.w32 29 May 2007 19:30:49 -
@@ -9,10 +9,10 @@
if (PHP_APACHE != no) {
if (CHECK_HEADER_ADD_INCLUDE(httpd.h, CFLAGS_APACHE,
php_usual_include_suspects +
; + PROGRAM_FILES + \\Apache
Group\\Apache\\include +
- ;..\\php_build\\apache\\src\\include)
+ ; + PHP_PHP_BUILD + \\apache\\src\\include)
CHECK_LIB(ApacheCore.lib, apache,
php_usual_lib_suspects +
';' + PROGRAM_FILES + '\\Apache
Group\\Apache\\libexec' +
- ';..\\php_build\\apache\\src\\corer')) {
+ ';' + PHP_PHP_BUILD + '\\apache\\src\\corer')) {
// We need to play tricks to get our readdir.h used by apache
// headers
SAPI('apache', 'mod_php5.c sapi_apache.c php_apache.c',
Index: apache_hooks/config.w32
===
RCS file: /repository/php-src/sapi/apache_hooks/config.w32,v
retrieving revision 1.2
diff -u -r1.2 config.w32
--- apache_hooks/config.w32 17 Jan 2004 13:00:08 - 1.2
+++ apache_hooks/config.w32 29 May 2007 19:42:45 -
@@ -6,10 +6,10 @@
if (PHP_APACHE_HOOKS != no) {
if (CHECK_HEADER_ADD_INCLUDE(httpd.h, CFLAGS_APACHE_HOOKS,
php_usual_include_suspects +
; + PROGRAM_FILES + \\Apache
Group\\Apache\\include +
- ;..\\php_build\\apache\\src\\include)
+ ; + PHP_PHP_BUILD +
\\php_build\\apache\\src\\include)
CHECK_LIB(ApacheCore.lib, apache_hooks,
php_usual_lib_suspects
+
';' + PROGRAM_FILES + '\\Apache
Group\\Apache\\libexec' +
- ';..\\php_build\\apache\\src\\corer')) {
+ ';' + PHP_PHP_BUILD + '\\apache\\src\\corer')) {
// We need to play tricks to get our readdir.h used by apache
// headers
SAPI('apache_hooks', 'mod_php5.c sapi_apache.c php_apache.c',
--
Edit this bug report at http://bugs.php.net/?id=41531edit=1
#41550 [NEW]: getElementById doesn't work after a schemaValidate
From: info at adaniels dot nl
Operating system: Linux
PHP version: 5CVS-2007-05-31 (CVS)
PHP Bug Type: DOM XML related
Bug description: getElementById doesn't work after a schemaValidate
Description:
Note that this is about the DOM extension, not DOM XML.
After using schemaValidate on a DOMDocument, the ID attributes should be
marked, so getElementById() should work. This used to work in PHP 5.1.x,
but is broken in current versions.
Reproduce code:
---
?php
$xml = XML
root
item id=abc /
item id=def /
item id=xyz /
/root
XML;
$schema = XML
?xml version=1.0?
xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema;
xs:element name=root
xs:complexType
xs:sequence
xs:element name=item type=item
maxOccurs=unbounded/
/xs:sequence
/xs:complexType
/xs:element
xs:complexType name=item
xs:attribute name=id use=required type=xs:ID/
/xs:complexType
/xs:schema
XML;
$dom = new DOMDocument();
$dom-loadXML($xml);
if (!$dom-schemaValidateSource($schema)) trigger_error(Validation
failed, E_USER_ERROR);
$node = $dom-getElementById('def');
echo $node ? 'Node found' : 'Where is it?';
?
Expected result:
Node found
Actual result:
--
Where is it?
--
Edit bug report at http://bugs.php.net/?id=41550edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41550r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41550r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41550r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41550r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41550r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41550r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41550r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41550r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41550r=support
Expected behavior:http://bugs.php.net/fix.php?id=41550r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41550r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41550r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41550r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41550r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41550r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41550r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41550r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41550r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41550r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41550r=mysqlcfg
#41548 [Bgs]: Fail to load php_mysql.dll and php_mysqli.dll
ID: 41548 User updated by: mercury__99 at hotmail dot com Reported By: mercury__99 at hotmail dot com Status: Bogus Bug Type: MySQL related Operating System: Windows XP SP2 PHP Version: 5.2.2 New Comment: Many thanks for the prompt reply from PHP. I don't think it is the libmysql.dll issue. I have the libmysql.dll under the C:\php, and all the php_xx.dll under the C:\php\ext. I have set the environment paths to point to both directories, modified the php.ini to point the extension directory, and re-started my comp. Still, I couldn't load the php_mysql.dll and php_mysqli.dll. No problem to load other php_xx.dll. Ok, I have resolved the problem by trial-an-error: 1) Simply uninstall MySQL. I could then see (from phpinfo()) that both php_mysql.dll and php_mysqli.dll loaded successfully. 2) Then, re-install MySQL. Everything is working fine now. ^_^' Previous Comments: [2007-05-31 10:33:33] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Most likely your libmysql.dll is not in place. [2007-05-31 09:56:48] mercury__99 at hotmail dot com This is an obvious bug in PHP 5.2.2 [2007-05-31 09:53:53] mercury__99 at hotmail dot com Description: Here is a portion of php.ini - ;extension=php_msql.dll extension=php_mssql.dll extension=php_mysql.dll extension=php_mysqli.dll extension=php_oci8.dll ;extension=php_openssl.dll after restarting apache, in phpinfo(); I got everything loaded EXCEPT: extension=php_mysql.dll and extension=php_mysqli.dll -- Edit this bug report at http://bugs.php.net/?id=41548edit=1
#41551 [NEW]: win 2K
From: kondakov at dewia dot com
Operating system: Win 2000, php 5.1.1 and 4.4.1
PHP version: 5.2.2
PHP Bug Type: Date/time related
Bug description: win 2K
Description:
for the actual date is 31.05.2007
Reproduce code:
---
var_dump(strtolower(date('F')), strtolower(date('F',strtotime(' +1
month';
Expected result:
string(3) may
string(4) june
Actual result:
--
string(3) may
string(4) july
--
Edit bug report at http://bugs.php.net/?id=41551edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41551r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41551r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41551r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41551r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41551r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41551r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41551r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41551r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41551r=support
Expected behavior:http://bugs.php.net/fix.php?id=41551r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41551r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41551r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41551r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41551r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41551r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41551r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41551r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41551r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41551r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41551r=mysqlcfg
#41551 [Opn-Bgs]: win 2K
ID: 41551
Updated by: [EMAIL PROTECTED]
Reported By: kondakov at dewia dot com
-Status: Open
+Status: Bogus
Bug Type: Date/time related
Operating System: Win 2000, php 5.1.1 and 4.4.1
PHP Version: 5.2.2
New Comment:
See bug #41547 for the explanation.
Previous Comments:
[2007-05-31 15:44:21] kondakov at dewia dot com
Description:
for the actual date is 31.05.2007
Reproduce code:
---
var_dump(strtolower(date('F')), strtolower(date('F',strtotime(' +1
month';
Expected result:
string(3) may
string(4) june
Actual result:
--
string(3) may
string(4) july
--
Edit this bug report at http://bugs.php.net/?id=41551edit=1
#41552 [NEW]: Bus Error - core dumped - Solaris - make: [test] Error 138
From: shane dot kinsch at netracorp dot com Operating system: Solaris 10 (SunOS 5.10) PHP version: 4.4.7 PHP Bug Type: *Compile Issues Bug description: Bus Error - core dumped - Solaris - make: [test] Error 138 Description: Running the make test for PHP 4.4.7 caused a core dump under Solaris Using GCC 3.4.6 under Solaris 10 (SunOS 5.10) and receive the same Bus Error / core dump on an elaborate configure or a basic configure. In the example below, I'm using a simple configure in order to isolate where the issue may live, but unfortunately I'm still stumped. Reproduce code: --- I received a simple warning about libiconv, so I've downgraded libiconv from 1.11 to 1.9.2 with no different results. I've since removed 1.9.2 and re-applied libiconv 1.11. I get the same bus error / core dump when I configure PHP with only these options: # make clean # CC=gcc \ ./configure --disable-xml --without-pear It configures what appears to be fine: http://my.gi.net/shane.kinsch/php-configure-log.txt It compiles what appears to be fine as well: http://my.gi.net/shane.kinsch/php-make-log.txt OS and Package Versions: SunOS web1 5.10 s10_72 sun4u sparc SUNW,UltraSPARC-IIi-cEngine - openssl-0.9.8e- autoconf 2.60 - automake 1.10 - bison 2.3 - expat 1.95.5 - flex 2.5.33 - fontconfig 2.4.2 - freetype 2.3.1 - gcc 3.4.6 - gd 2.0.33 - jpeg 6b - libiconv 1.9.2 - libpng 1.2.16 - libtool 1.5 - libxml2 2.6.26- libxslt 1.1.17 - m4 1.4.7 - make 3.81 - perl 5.8.8- texinfo 4.8 - xpm 3.4k - zlib 1.2.3 Expected result: make test to complete successfully, or even execute. Actual result: -- # make test Bus Error - core dumped make: [test] Error 138 (ignored) core dump -- Edit bug report at http://bugs.php.net/?id=41552edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41552r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41552r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41552r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=41552r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=41552r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=41552r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=41552r=needscript Try newer version:http://bugs.php.net/fix.php?id=41552r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=41552r=support Expected behavior:http://bugs.php.net/fix.php?id=41552r=notwrong Not enough info: http://bugs.php.net/fix.php?id=41552r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=41552r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=41552r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41552r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=41552r=dst IIS Stability:http://bugs.php.net/fix.php?id=41552r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=41552r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=41552r=float No Zend Extensions: http://bugs.php.net/fix.php?id=41552r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=41552r=mysqlcfg
#41552 [Opn-Fbk]: Bus Error - core dumped - Solaris - make: [test] Error 138
ID: 41552 Updated by: [EMAIL PROTECTED] Reported By: shane dot kinsch at netracorp dot com -Status: Open +Status: Feedback Bug Type: *Compile Issues Operating System: Solaris 10 (SunOS 5.10) PHP Version: 4.4.7 New Comment: Try updating GCC to the latest available version. Previous Comments: [2007-05-31 16:25:28] shane dot kinsch at netracorp dot com Description: Running the make test for PHP 4.4.7 caused a core dump under Solaris Using GCC 3.4.6 under Solaris 10 (SunOS 5.10) and receive the same Bus Error / core dump on an elaborate configure or a basic configure. In the example below, I'm using a simple configure in order to isolate where the issue may live, but unfortunately I'm still stumped. Reproduce code: --- I received a simple warning about libiconv, so I've downgraded libiconv from 1.11 to 1.9.2 with no different results. I've since removed 1.9.2 and re-applied libiconv 1.11. I get the same bus error / core dump when I configure PHP with only these options: # make clean # CC=gcc \ ./configure --disable-xml --without-pear It configures what appears to be fine: http://my.gi.net/shane.kinsch/php-configure-log.txt It compiles what appears to be fine as well: http://my.gi.net/shane.kinsch/php-make-log.txt OS and Package Versions: SunOS web1 5.10 s10_72 sun4u sparc SUNW,UltraSPARC-IIi-cEngine - openssl-0.9.8e- autoconf 2.60 - automake 1.10 - bison 2.3 - expat 1.95.5 - flex 2.5.33 - fontconfig 2.4.2 - freetype 2.3.1 - gcc 3.4.6 - gd 2.0.33 - jpeg 6b - libiconv 1.9.2 - libpng 1.2.16 - libtool 1.5 - libxml2 2.6.26- libxslt 1.1.17 - m4 1.4.7 - make 3.81 - perl 5.8.8- texinfo 4.8 - xpm 3.4k - zlib 1.2.3 Expected result: make test to complete successfully, or even execute. Actual result: -- # make test Bus Error - core dumped make: [test] Error 138 (ignored) core dump -- Edit this bug report at http://bugs.php.net/?id=41552edit=1
#41545 [Fbk-Opn]: Mhash extension SegFaults on MD5 algorithm
ID: 41545 User updated by: wdierkes at 5dollarwhitebox dot org Reported By: wdierkes at 5dollarwhitebox dot org -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Redhat Enterprise Linux ES 3 PHP Version: 5.2.2 New Comment: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1218525024 (LWP 4690)] 0x0068c5b8 in malloc_consolidate () from /lib/tls/libc.so.6 (gdb) bt #0 0x0068c5b8 in malloc_consolidate () from /lib/tls/libc.so.6 #1 0x0068bd59 in _int_malloc () from /lib/tls/libc.so.6 #2 0x0068b0fd in malloc () from /lib/tls/libc.so.6 #3 0x00dbe5a2 in apr_allocator_set_mutex () from /usr/lib/libapr-0.so.0 #4 0x00117942 in apr_bucket_alloc () from /usr/lib/libaprutil-0.so.0 #5 0x001171c2 in apr_brigade_write () from /usr/lib/libaprutil-0.so.0 #6 0x08077557 in ap_old_write_filter () #7 0x08077667 in ap_rwrite () #8 0x07439d4b in php_apache_sapi_ub_write ( str=0xb73931cc clear text input: PassW0rd\nname: MD5\nhash follows: , '0' repeats 32 times, \n, str_length=84) at /usr/src/debug/php-5.2.2/sapi/apache2handler/sapi_apache2.c:78 #9 0x0737b765 in php_ub_body_write_no_header ( str=0xb73931cc clear text input: PassW0rd\nname: MD5\nhash follows: , '0' repeats 32 times, \n, str_length=84) at /usr/src/debug/php-5.2.2/main/output.c:688 #10 0x0737b859 in php_ub_body_write ( str=0xb73931cc clear text input: PassW0rd\nname: MD5\nhash follows: , '0' repeats 32 times, \n, str_length=84) at /usr/src/debug/php-5.2.2/main/output.c:721 #11 0x0737a98b in php_end_ob_buffer (send_buffer=1 '\001', just_flush=0 '\0') at /usr/src/debug/php-5.2.2/main/output.c:300 #12 0x0737ab46 in php_end_ob_buffers (send_buffer=1 '\001') at /usr/src/debug/php-5.2.2/main/output.c:339 #13 0x07366eaf in php_request_shutdown (dummy=0x0) at /usr/src/debug/php-5.2.2/main/main.c:1291 #14 0x0743aafa in php_apache_request_dtor (r=0x9e31920) at /usr/src/debug/php-5.2.2/sapi/apache2handler/sapi_apache2.c:463 #15 0x0743b292 in php_handler (r=0x9e31920) at /usr/src/debug/php-5.2.2/sapi/apache2handler/sapi_apache2.c:635 #16 0x08068625 in ap_run_handler () #17 0x08068c3f in ap_invoke_handler () #18 0x08065266 in ap_process_request () #19 0x080608dc in _start () #20 0x09e31920 in ?? () #21 0x0004 in ?? () #22 0x09e31920 in ?? () #23 0x009dd2f7 in modperl_process_connection_handler () from /etc/httpd/modules/mod_perl.so #24 0x080723d5 in ap_run_process_connection () #25 0x08066b01 in ap_graceful_stop_signalled () #26 0x08066d1a in ap_graceful_stop_signalled () #27 0x08066d76 in ap_graceful_stop_signalled () #28 0x080675cd in ap_mpm_run () #29 0x0806dbcf in main () NOTE: A co-worker of mine mentioned that he ran into this a while ago. He mentioned that the issue was that the ldap module, and Mhash library had conflicting function names (possibly relating to SSL)... etc. Therefore, it is likely not a PHP issue directly, though not certain of the proper path to take in resolving the matter. Previous Comments: [2007-05-31 09:11:58] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. [2007-05-30 23:53:41] wdierkes at 5dollarwhitebox dot org The problem does not exist when php-ldap extension is *not* loaded. unloading ldap from the running PHP fixes the problem. [2007-05-30 22:04:47] wdierkes at 5dollarwhitebox dot org Description: The Mhash extension SegFaults on Redhat Enterprise Linux ES 3 when using the MD5 algorithm. All other algorithms seem to work except MD5. NOTE: This appears to possibly be related to bug #30983 which is closed (and I could not touch it). In that bug, it was claimed to 'not imply a bug in PHP itself'. This may be true, however similar tests against the Mhash library itself using C code function as expected. I ran the same test against the Mhash library using the following C code located here: http://www.5dollarwhitebox.org/tmp/mhash_test.c You must install the Mhash library obviously, then compile and run the test file: [EMAIL PROTECTED] ~]$ gcc -lmhash -o mhash_test mhash_test.c [EMAIL PROTECTED] ~]$ ./mhash_test The issue exists on Rhel3 i386/x86_64, but does *not* exist on Rhel4.. and I am using Mhash-0.9.9 Reproduce code: --- PHP Code: ?php $input = PassW0rd; print clear text input: .
#41545 [Opn-Bgs]: Mhash extension SegFaults on MD5 algorithm
ID: 41545 Updated by: [EMAIL PROTECTED] Reported By: wdierkes at 5dollarwhitebox dot org -Status: Open +Status: Bogus Bug Type: Reproducible crash Operating System: Redhat Enterprise Linux ES 3 PHP Version: 5.2.2 New Comment: Well, if some third party libraries have a symbol with the same name, we can hardly fix them. The problem is clearly not in the extensions, since they don't have any similar symbols at all. Please report the problem to OpenLDAP/Mhash developers if/when you have more details. Previous Comments: [2007-05-31 17:06:32] wdierkes at 5dollarwhitebox dot org Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1218525024 (LWP 4690)] 0x0068c5b8 in malloc_consolidate () from /lib/tls/libc.so.6 (gdb) bt #0 0x0068c5b8 in malloc_consolidate () from /lib/tls/libc.so.6 #1 0x0068bd59 in _int_malloc () from /lib/tls/libc.so.6 #2 0x0068b0fd in malloc () from /lib/tls/libc.so.6 #3 0x00dbe5a2 in apr_allocator_set_mutex () from /usr/lib/libapr-0.so.0 #4 0x00117942 in apr_bucket_alloc () from /usr/lib/libaprutil-0.so.0 #5 0x001171c2 in apr_brigade_write () from /usr/lib/libaprutil-0.so.0 #6 0x08077557 in ap_old_write_filter () #7 0x08077667 in ap_rwrite () #8 0x07439d4b in php_apache_sapi_ub_write ( str=0xb73931cc clear text input: PassW0rd\nname: MD5\nhash follows: , '0' repeats 32 times, \n, str_length=84) at /usr/src/debug/php-5.2.2/sapi/apache2handler/sapi_apache2.c:78 #9 0x0737b765 in php_ub_body_write_no_header ( str=0xb73931cc clear text input: PassW0rd\nname: MD5\nhash follows: , '0' repeats 32 times, \n, str_length=84) at /usr/src/debug/php-5.2.2/main/output.c:688 #10 0x0737b859 in php_ub_body_write ( str=0xb73931cc clear text input: PassW0rd\nname: MD5\nhash follows: , '0' repeats 32 times, \n, str_length=84) at /usr/src/debug/php-5.2.2/main/output.c:721 #11 0x0737a98b in php_end_ob_buffer (send_buffer=1 '\001', just_flush=0 '\0') at /usr/src/debug/php-5.2.2/main/output.c:300 #12 0x0737ab46 in php_end_ob_buffers (send_buffer=1 '\001') at /usr/src/debug/php-5.2.2/main/output.c:339 #13 0x07366eaf in php_request_shutdown (dummy=0x0) at /usr/src/debug/php-5.2.2/main/main.c:1291 #14 0x0743aafa in php_apache_request_dtor (r=0x9e31920) at /usr/src/debug/php-5.2.2/sapi/apache2handler/sapi_apache2.c:463 #15 0x0743b292 in php_handler (r=0x9e31920) at /usr/src/debug/php-5.2.2/sapi/apache2handler/sapi_apache2.c:635 #16 0x08068625 in ap_run_handler () #17 0x08068c3f in ap_invoke_handler () #18 0x08065266 in ap_process_request () #19 0x080608dc in _start () #20 0x09e31920 in ?? () #21 0x0004 in ?? () #22 0x09e31920 in ?? () #23 0x009dd2f7 in modperl_process_connection_handler () from /etc/httpd/modules/mod_perl.so #24 0x080723d5 in ap_run_process_connection () #25 0x08066b01 in ap_graceful_stop_signalled () #26 0x08066d1a in ap_graceful_stop_signalled () #27 0x08066d76 in ap_graceful_stop_signalled () #28 0x080675cd in ap_mpm_run () #29 0x0806dbcf in main () NOTE: A co-worker of mine mentioned that he ran into this a while ago. He mentioned that the issue was that the ldap module, and Mhash library had conflicting function names (possibly relating to SSL)... etc. Therefore, it is likely not a PHP issue directly, though not certain of the proper path to take in resolving the matter. [2007-05-31 09:11:58] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. [2007-05-30 23:53:41] wdierkes at 5dollarwhitebox dot org The problem does not exist when php-ldap extension is *not* loaded. unloading ldap from the running PHP fixes the problem. [2007-05-30 22:04:47] wdierkes at 5dollarwhitebox dot org Description: The Mhash extension SegFaults on Redhat Enterprise Linux ES 3 when using the MD5 algorithm. All other algorithms seem to work except MD5. NOTE: This appears to possibly be related to bug #30983 which is closed (and I could not touch it). In that bug, it was claimed to 'not imply a bug in PHP itself'. This may be true, however similar tests against the Mhash library itself using C code function as expected. I ran the same test against the Mhash library using the following C code located here: http://www.5dollarwhitebox.org/tmp/mhash_test.c
#41553 [NEW]: httpd.conf modified incorrectly with installer
From: r dot bunder at chello dot nl Operating system: Windows XP and Vista PHP version: 5.2.2 PHP Bug Type: Apache2 related Bug description: httpd.conf modified incorrectly with installer Description: Hi, When using the windows installer php-5.2.2-win32-installer.msi It creates the following entry in the httpd.conf #BEGIN PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL PHPIniDir C:\Program Files\PHP\ LoadModule php5_module C:\Program Files\PHP\\php5apache2_2.dll #END PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL The line LoadModule php5_module C:\Program Files\PHP\\php5apache2_2.dll contains one \ to many It should be: LoadModule php5_module C:\Program Files\PHP\php5apache2_2.dll Kind regards Remco Bunder -- Edit bug report at http://bugs.php.net/?id=41553edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41553r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41553r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41553r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=41553r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=41553r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=41553r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=41553r=needscript Try newer version:http://bugs.php.net/fix.php?id=41553r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=41553r=support Expected behavior:http://bugs.php.net/fix.php?id=41553r=notwrong Not enough info: http://bugs.php.net/fix.php?id=41553r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=41553r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=41553r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41553r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=41553r=dst IIS Stability:http://bugs.php.net/fix.php?id=41553r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=41553r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=41553r=float No Zend Extensions: http://bugs.php.net/fix.php?id=41553r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=41553r=mysqlcfg
#41553 [Opn-Fbk]: httpd.conf modified incorrectly with installer
ID: 41553 Updated by: [EMAIL PROTECTED] Reported By: r dot bunder at chello dot nl -Status: Open +Status: Feedback -Bug Type: Apache2 related +Bug Type: Unknown/Other Function Operating System: Windows XP and Vista PHP Version: 5.2.2 New Comment: 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 Previous Comments: [2007-05-31 20:30:17] r dot bunder at chello dot nl Description: Hi, When using the windows installer php-5.2.2-win32-installer.msi It creates the following entry in the httpd.conf #BEGIN PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL PHPIniDir C:\Program Files\PHP\ LoadModule php5_module C:\Program Files\PHP\\php5apache2_2.dll #END PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL The line LoadModule php5_module C:\Program Files\PHP\\php5apache2_2.dll contains one \ to many It should be: LoadModule php5_module C:\Program Files\PHP\php5apache2_2.dll Kind regards Remco Bunder -- Edit this bug report at http://bugs.php.net/?id=41553edit=1
#40835 [Opn-Asn]: Incompatible with prototype warnings
ID: 40835 Updated by: [EMAIL PROTECTED] Reported By: ian at onlineloop dot com -Status: Open +Status: Assigned Bug Type: Compile Warning Operating System: Solaris 10 PHP Version: 5.2.1 Assigned To: tony2001 Previous Comments: [2007-05-15 15:35:45] ian at onlineloop dot com I'm setting up a zone on an Enterprise 3500 for the PHP team. Please contact me directly so we can arrange access and discuss your needs. [2007-03-20 16:11:17] [EMAIL PROTECTED] Any news? Btw, I've looked through the warnings and all of them are safe. Actually, I believe your compiler should not even report most of them. [2007-03-16 15:52:53] [EMAIL PROTECTED] Most of these warnings can be safely ignored (and do not exist if you use less strict compiler). [2007-03-16 15:34:49] ian at onlineloop dot com OK, so it seems no text file attachments are possible, as such a link to the build history. http://www.meduniwien.ac.at/user/ib/php-5.2.1-solaris10_build.log.gz As for access to a machine, I will try to arrange something in the next couple of weeks. [2007-03-16 15:04:39] [EMAIL PROTECTED] It would be very good to have an access to a machine with Sun Compiler, just for tests. As far as I know at the moment none of developers use Sun Compiler or test the builds using it. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/40835 -- Edit this bug report at http://bugs.php.net/?id=40835edit=1
#41545 [Bgs]: Mhash extension SegFaults on MD5 algorithm
ID: 41545 User updated by: wdierkes at 5dollarwhitebox dot org Reported By: wdierkes at 5dollarwhitebox dot org Status: Bogus Bug Type: Reproducible crash Operating System: Redhat Enterprise Linux ES 3 PHP Version: 5.2.2 New Comment: This issue can be followed up at the following Mhash bug track: http://sourceforge.net/tracker/index.php?func=detailaid=1729145group_id=4286atid=104286 A patch has been submitted to work around this issue, and can be downloaded from there. Previous Comments: [2007-05-31 17:13:30] [EMAIL PROTECTED] Well, if some third party libraries have a symbol with the same name, we can hardly fix them. The problem is clearly not in the extensions, since they don't have any similar symbols at all. Please report the problem to OpenLDAP/Mhash developers if/when you have more details. [2007-05-31 17:06:32] wdierkes at 5dollarwhitebox dot org Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1218525024 (LWP 4690)] 0x0068c5b8 in malloc_consolidate () from /lib/tls/libc.so.6 (gdb) bt #0 0x0068c5b8 in malloc_consolidate () from /lib/tls/libc.so.6 #1 0x0068bd59 in _int_malloc () from /lib/tls/libc.so.6 #2 0x0068b0fd in malloc () from /lib/tls/libc.so.6 #3 0x00dbe5a2 in apr_allocator_set_mutex () from /usr/lib/libapr-0.so.0 #4 0x00117942 in apr_bucket_alloc () from /usr/lib/libaprutil-0.so.0 #5 0x001171c2 in apr_brigade_write () from /usr/lib/libaprutil-0.so.0 #6 0x08077557 in ap_old_write_filter () #7 0x08077667 in ap_rwrite () #8 0x07439d4b in php_apache_sapi_ub_write ( str=0xb73931cc clear text input: PassW0rd\nname: MD5\nhash follows: , '0' repeats 32 times, \n, str_length=84) at /usr/src/debug/php-5.2.2/sapi/apache2handler/sapi_apache2.c:78 #9 0x0737b765 in php_ub_body_write_no_header ( str=0xb73931cc clear text input: PassW0rd\nname: MD5\nhash follows: , '0' repeats 32 times, \n, str_length=84) at /usr/src/debug/php-5.2.2/main/output.c:688 #10 0x0737b859 in php_ub_body_write ( str=0xb73931cc clear text input: PassW0rd\nname: MD5\nhash follows: , '0' repeats 32 times, \n, str_length=84) at /usr/src/debug/php-5.2.2/main/output.c:721 #11 0x0737a98b in php_end_ob_buffer (send_buffer=1 '\001', just_flush=0 '\0') at /usr/src/debug/php-5.2.2/main/output.c:300 #12 0x0737ab46 in php_end_ob_buffers (send_buffer=1 '\001') at /usr/src/debug/php-5.2.2/main/output.c:339 #13 0x07366eaf in php_request_shutdown (dummy=0x0) at /usr/src/debug/php-5.2.2/main/main.c:1291 #14 0x0743aafa in php_apache_request_dtor (r=0x9e31920) at /usr/src/debug/php-5.2.2/sapi/apache2handler/sapi_apache2.c:463 #15 0x0743b292 in php_handler (r=0x9e31920) at /usr/src/debug/php-5.2.2/sapi/apache2handler/sapi_apache2.c:635 #16 0x08068625 in ap_run_handler () #17 0x08068c3f in ap_invoke_handler () #18 0x08065266 in ap_process_request () #19 0x080608dc in _start () #20 0x09e31920 in ?? () #21 0x0004 in ?? () #22 0x09e31920 in ?? () #23 0x009dd2f7 in modperl_process_connection_handler () from /etc/httpd/modules/mod_perl.so #24 0x080723d5 in ap_run_process_connection () #25 0x08066b01 in ap_graceful_stop_signalled () #26 0x08066d1a in ap_graceful_stop_signalled () #27 0x08066d76 in ap_graceful_stop_signalled () #28 0x080675cd in ap_mpm_run () #29 0x0806dbcf in main () NOTE: A co-worker of mine mentioned that he ran into this a while ago. He mentioned that the issue was that the ldap module, and Mhash library had conflicting function names (possibly relating to SSL)... etc. Therefore, it is likely not a PHP issue directly, though not certain of the proper path to take in resolving the matter. [2007-05-31 09:11:58] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. [2007-05-30 23:53:41] wdierkes at 5dollarwhitebox dot org The problem does not exist when php-ldap extension is *not* loaded. unloading ldap from the running PHP fixes the problem. [2007-05-30 22:04:47] wdierkes at 5dollarwhitebox dot org Description: The Mhash extension SegFaults on Redhat Enterprise Linux ES 3 when using the MD5 algorithm. All other algorithms seem to work except MD5. NOTE: This appears to possibly be related to bug #30983
#41550 [Opn-Asn]: getElementById doesn't work after a schemaValidate
ID: 41550
Updated by: [EMAIL PROTECTED]
Reported By: info at adaniels dot nl
-Status: Open
+Status: Assigned
Bug Type: DOM XML related
Operating System: Linux
PHP Version: 5CVS-2007-05-31 (CVS)
-Assigned To:
+Assigned To: rrichards
Previous Comments:
[2007-05-31 15:17:02] info at adaniels dot nl
Description:
Note that this is about the DOM extension, not DOM XML.
After using schemaValidate on a DOMDocument, the ID attributes should
be marked, so getElementById() should work. This used to work in PHP
5.1.x, but is broken in current versions.
Reproduce code:
---
?php
$xml = XML
root
item id=abc /
item id=def /
item id=xyz /
/root
XML;
$schema = XML
?xml version=1.0?
xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema;
xs:element name=root
xs:complexType
xs:sequence
xs:element name=item type=item
maxOccurs=unbounded/
/xs:sequence
/xs:complexType
/xs:element
xs:complexType name=item
xs:attribute name=id use=required type=xs:ID/
/xs:complexType
/xs:schema
XML;
$dom = new DOMDocument();
$dom-loadXML($xml);
if (!$dom-schemaValidateSource($schema)) trigger_error(Validation
failed, E_USER_ERROR);
$node = $dom-getElementById('def');
echo $node ? 'Node found' : 'Where is it?';
?
Expected result:
Node found
Actual result:
--
Where is it?
--
Edit this bug report at http://bugs.php.net/?id=41550edit=1
#41546 [Opn]: Is_callable() function behavior incorrect in PHP5.
ID: 41546
Updated by: [EMAIL PROTECTED]
Reported By: mahesh dot vemula at in dot ibm dot com
Status: Open
Bug Type: Strings related
Operating System: RHEL4
PHP Version: 5.2.2
New Comment:
is_callable() function in PHP 5 is incorrectly truncating the name
passed when it calls ZVAL_STRING
Well, the problem is that zend_is_callable() in PHP5 operates on
strings, not zvals (like in PHP6, which is just a sideffect of having
two types of strings), so there is no way to know the length of the
resulting string except to use strlen().
i.e it should be possible to have function names with embedded nulls.
Functions with embedded nulls make no sense to me.
So the bottom line is:
function names with NULLs are not supported in both PHP5 and PHP6, but
PHP6 just happens to handle them correctly.
I'd say this is a won't fix.
Previous Comments:
[2007-05-31 06:29:53] mahesh dot vemula at in dot ibm dot com
Description:
In the below testcode, PHP5 PHP6 outputs differ for is_callable()
function.
In PHP6 when we are echo-ing a string( eg. welcome\0 ) with null
character at the end of the string, the output with run-tests shows null
character also at the end of the string.
Whereas, running the file with php5.2.2 gives the expected output ( i.e
welcome).
is_callable() function in PHP 5 is incorrectly truncating the name
passed when it calls ZVAL_STRING, i.e it should be possible to have
function names with embedded nulls.
The behavior on PHP6 looks be correct.
This is consistent with the expected behaviour after reading Sarah
Goleman's book; page 25. It says:
What's worth noting about PHP string is that the length of the string
is always explicitly stated in the zval structure. This allows strings
to contain NULL bytes without being truncated. This aspect of PHP
strings will be referred to hereafter as binary safety because it makes
it safe to contain any type of binary data.
Reproduce code:
---
?php
$undef_functions = array (
\0,
'\0',
welcome\0,
'welcome\0',
);
$counter = 1;
foreach($undef_functions as $func) {
echo -- Iteration $counter --\n;
var_dump( is_callable($func, FALSE, $callable_name) );
echo $callable_name, \n;
$counter++;
}
echo done;
?
Expected result:
-- Iteration 1 --
bool(false)
_
-- Iteration 2 --
bool(false)
\0
-- Iteration 3 --
bool(false)
welcome_
-- Iteration 4 --
bool(false)
welcome\0
done
Actual result:
--
-- Iteration 1 --
bool(false)
-- Iteration 2 --
bool(false)
\0
-- Iteration 3 --
bool(false)
welcome
-- Iteration 4 --
bool(false)
welcome\0
done
--
Edit this bug report at http://bugs.php.net/?id=41546edit=1
#41518 [Com]: file_exists() warns of open_basedir restriction on non-existent file
ID: 41518 Comment by: phpbugs at thequod dot de Reported By: ruben dot willmes at emil2001 dot de Status: Open Bug Type: Safe Mode/open_basedir Operating System: Linux PHP Version: 5.2.2 New Comment: This might be related to bug #39123, where open_basedir=/tmp/ started to fail, as internally only /tmp (without trailing slash) got considered. (http://bugs.php.net/bug.php?id=39123) Previous Comments: [2007-05-31 12:40:31] ruben dot willmes at emil2001 dot de Your example is correct, that does work, but what if you change the following: Instead of #php -d open_basedir=/tmp -r 'var_dump(file_exists(/tmp/nosuch));' try #php -d open_basedir=/tmp/ -r 'var_dump(file_exists(/tmp/nosuch));' Notice the slash behind open_basedir=/tmp/. With that you get Warning: file_exists(): open_basedir restriction in effect. File(/tmp/ nosuch) is not within the allowed path(s): (/tmp/) in Command line code on line 1 bool(false) [2007-05-31 11:06:13] [EMAIL PROTECTED] I don't think I get what you're talking about: # ls -l /tmp/nosuch ls: cannot access /tmp/nosuch: No such file or directory #php -d open_basedir=/tmp -r 'var_dump(file_exists(/tmp/nosuch));' bool(false) No warning whatsoever. [2007-05-30 20:20:58] ruben dot willmes at emil2001 dot de Sorry, but i have to reopen this bug again. Thx for the reply, Tony, but i don't think you understood me. I don't want to generally remove this error message, it's just under your OWN open_basedir, where you shouldn't get this message since you should be able to check whether the file exists under your OWN open_basedir, or am i wrong? Let's make an example: Two users, user1 and user2, both locked in their homedirs with open_basedir: /home/user1/ /home/user2/ Both have one file in their directory, let's call it test.php Now, if user1 checks whether test.php exists, he get's a true, as well as user2. If user1 checks user2's test.php, he'll get a false and an open_basedir warning since he's out of his open_basedir. That's correct. But what if user1 checks a file called test2.php under his own directory, /home/user1/? Should he get an open_basedir error? In my eyes he should only get a 'false' as the file does not exist, but no open_basedir warning, since he's still in his own open_basedir. In the recent PHP5 release (5.2.2) one get's an open_basedir warning if you check a non-existent file under your OWN open_basedir. In a previous release the message was not present (i think it was 5.2.0 or 5.2.1). so, please reconsider this bug [2007-05-29 20:39:47] [EMAIL PROTECTED] If we remove this warning for non-existent files, it could be possible to use file_exists() to detect which files exists (since it's perfectly legal to print this warning when the file exists). [2007-05-29 06:58:06] ruben dot willmes at emil2001 dot de You're right, it does work correctly if i set my open_basedir to '/var/ www/localhost/htdocs' (without the trailing slash). But if i set it to '/var/www/localhost/htdocs/' (with the trailing slash), it doesn't work in my test case. Could you please try it once more setting your open_basedir to '/www/home/user/' (with the trailing slash)? The system this is running on is PHP 5.2.2, with Apache 2.0.58. thx in advance 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/41518 -- Edit this bug report at http://bugs.php.net/?id=41518edit=1
#41555 [NEW]: Unable to compile with --with-gd switch
From: genetiq at gmail dot com
Operating system: MacOS X 10.4.9
PHP version: 5.2.3
PHP Bug Type: Compile Failure
Bug description: Unable to compile with --with-gd switch
Description:
Unable to compile with bundled GD library - configure script fails with
an error.
Reproduce code:
---
trying to compile with the following options:
./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
--mandir=/usr/share/man/ --with-apxs2=/usr/sbin/apxs --with-curl --with-gd
--enable-exif --enable-fastcgi --with-pgsql --with-zip
--with-jpeg-dir=/usr/src/libjpeg --with-png-dir=/usr/src/libpng
it fails with this error:
configure: error: GD build test failed. Please check the config.log for
details.
in config.log there are following info:
configure:42434: gcc -o conftest -g -O2 -no-cpp-precomp conftest.c -L
-lpng -lz -lcurl -lm -lxml2 -lz -liconv -lm -lcurl -lssl -lcrypto -lz
-lxml2 -lz -liconv -lm 15
/usr/bin/ld: -L: directory name missing
collect2: ld returned 1 exit status
configure: failed program was:
#line 42423 configure
#include confdefs.h
char foobar () {}
char foobar();
int main() {
foobar();
return 0;
}
Expected result:
php is always expected to build normally :)
--
Edit bug report at http://bugs.php.net/?id=41555edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41555r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41555r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41555r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41555r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41555r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41555r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41555r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41555r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41555r=support
Expected behavior:http://bugs.php.net/fix.php?id=41555r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41555r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41555r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41555r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41555r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41555r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41555r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41555r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41555r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41555r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41555r=mysqlcfg
#41556 [NEW]: bug in ini_set(), include_path function
From: flexibill2001 at hotmail dot com
Operating system: linux
PHP version: 4.4.7
PHP Bug Type: *Configuration Issues
Bug description: bug in ini_set(), include_path function
Description:
ini_set('include_path',ini_get('include_path').';'.$_SERVER['DOCUMENT_ROOT'].'/Dynamic_Form2/pear');
i use this instruction on one of my php file.This worked fine for windows
but when i call this page from linux machine it did not work and give
error.
solution : make sure when you using linux for include new path use : and
for windows use ; .
Reproduce code:
---
?ini_set('include_path',ini_get('include_path').';'.$_SERVER['DOCUMENT_ROOT'].'/Dynamic_Form2/pear');
require_once HTML/QuickForm.php;
$form = new HTML_QuickForm('frmTest', 'get');
$form-addElement('header', 'MyHeader', 'Testing QuickForm');
$form-display();
?
Expected result:
when run this coude on windows it work fine.but on linux give following
error:
Warning: main(HTML/QuickForm.php) [function.main]: failed to open stream:
No such file or directory in F:\apache2triad\htdocs\Dynamic_Form2\delme.php
on line 5
Actual result:
--
when run this coude on windows it work fine.but on linux give following
error:
Warning: main(HTML/QuickForm.php) [function.main]: failed to open stream:
No such file or directory in F:\apache2triad\htdocs\Dynamic_Form2\delme.php
on line 5
--
Edit bug report at http://bugs.php.net/?id=41556edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41556r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41556r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41556r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41556r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41556r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41556r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41556r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41556r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41556r=support
Expected behavior:http://bugs.php.net/fix.php?id=41556r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41556r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41556r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41556r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41556r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41556r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41556r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41556r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41556r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41556r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41556r=mysqlcfg
#41540 [Bgs]: A probable solution for the Mysterious Warning Message.
ID: 41540
User updated by: essem76 at yahoo dot com
Reported By: essem76 at yahoo dot com
Status: Bogus
Bug Type: Session related
Operating System: Windows Server 2000
PHP Version: 5.2.2
New Comment:
The thing is that a null value assignment to a session variable is
perfectly acceptable. But an already uninitialized php variable can not
be assigned to a session variable!! I can't understand why? But..
Also the warning message is also confusing as I am already using
version 5.2.0
Previous Comments:
[2007-05-30 12:06:03] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
[2007-05-30 11:53:06] essem76 at yahoo dot com
Description:
If that iritating warning occurs then check the mistyped PHP variables
assigned to session variable.
I faced the same problem and half an hour after getting on my nerves I
found the typing mistake and the nasty warning disappeared.
As there aren't many articles when I googled, I thought this might be
help someone..
Reproduce code:
---
?php
session_start();
function checkArrEmpty($arr){
$flag = false;
if(is_array($arr)) {
foreach($arr as $val){
if($val == ){
$flag = true; break;
}
}
}
return $flag;
}
if(!$_SESSION['blnFormDataValid']){
$arrUserData = $_SESSION['arrFormData'];
}
if(isset($_POST['btnAdd'])){
$arrFormData = $_POST;
if(!checkArrEmpty($arrFormData)){
$_SESSION['blnFormDataValid'] = true;
$_SESSION['arrFormData'] = ; //header(location:
XTemp.php);//exit();
}
else{//THE following nasty variable mistyped (look for small case d in
data) is creating a hell.
//Simply replace $arrFormdata to $arrFormData and see the
difference.
$_SESSION['arrFormData'] = $arrFormdata;
$_SESSION['blnFormDataValid'] = false;
}
}
?
form id=frmUser method=post action=?php echo
$_SERVER['PHP_SELF']; ?
labelFirst Name: /labelinput type=text name=fName
value=?php echo $arrUserData['fName']; ? /br/
labelLast Name: /labelinput type=text name=lName value=?php
echo $arrUserData['lName']; ? /br/
input type=submit name=btnAdd value=add /
/form
Expected result:
The code is expected to check the server side validations of the form
inputs failing which will generate the same form but with the partially
filled values this time.
Actual result:
--
The following warning is displayed even in PHP 5.2.0:-
Warning: Unknown: Your script possibly relies on a session side-effect
which existed until PHP 4.2.3. Please be advised that the session
extension does not consider global variables as a source of data, unless
register_globals is enabled. You can disable this functionality and this
warning by setting session.bug_compat_42 or session.bug_compat_warn to
off, respectively. in Unknown on line 0
--
Edit this bug report at http://bugs.php.net/?id=41540edit=1
