#41892 [Bgs]: url parsing bug
ID: 41892 User updated by: a dot fokin at new-vision dot com -Summary: url separating related Reported By: a dot fokin at new-vision dot com Status: Bogus Bug Type: cURL related Operating System: windows PHP Version: 5.2.3 New Comment: I am 99,5% sure, that this is not a support or development question. When i use http://111:[EMAIL PROTECTED] - everything is fine, but when i use http://[EMAIL PROTECTED]:[EMAIL PROTECTED] - curl reads it as if username is `111`, no password given and actual url (host) is `111.111:[EMAIL PROTECTED], which is wrong url parsing. I'm not asking here for help or feedback (in some case ;)). Just want to make sure, that you actually read current bogus description and understand what is the problem. And sorry for spam if i am wrong ;). Previous Comments: [2007-07-04 11:53:28] [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-07-04 09:04:21] a dot fokin at new-vision dot com Description: when i try to http authenticate by url with user name, containing '@', i got '6' returned. Reproduce code: --- ?php $ch = curl_init(); curl_setopt( $ch, CURLOPT_URL, http://[EMAIL PROTECTED]:[EMAIL PROTECTED] ); curl_setopt($ch, CURLOPT_HEADER, 0); curl_exec($ch); $errno = curl_errno($ch); echo $errno; ? Expected result: You have reached this web page by typing example.com, example.net, or example.org into your web browser. These domain names are reserved for use in documentation and are not available for registration. See RFC 2606, Section 3. /0/ Actual result: -- /6/ -- Edit this bug report at http://bugs.php.net/?id=41892edit=1
#41899 [NEW]: Can't open files with leading relative path of '..' and '..' is not readable
From: geoffwa at cs dot rmit dot edu dot au Operating system: Solaris 10 PHP version: 5.2.3 PHP Bug Type: Streams related Bug description: Can't open files with leading relative path of '..' and '..' is not readable Description: (possibly related to bug #39953 or bug #39351) If a relative path to a file has '..' as a leading path component, and the directory referred to by '..' is not readable by the user, then opening a file using the relative path fails. Using an absolute path or a path with a non-'..' leading component opens said file just fine. Reproduce code: --- See http://goanna.cs.rmit.edu.au/~geoffwa/relative_path_bug.php for a large test script. Expected result: (Using PHP 5.1.4) Current working directory is: /home/g/geoffwa/test Opened /home/g/geoffwa/test/a/b/file Opened ./a/b/file from ./a using ./b/file Opened ./a/b/file from ./a using ./b/c/../file Opened ./a/b/file from ./a/b/c using ../file Opened ../file from ./a/b/c using ./../file Opened ./a/b/file from ./a/b using ./file Opened ./a/file from ./a/b using ./c/../../file Opened ./a/b/c/file from ./a/b/c using ../c/file Actual result: -- (Using PHP 5.2.3 + suhosin patch) Opened /home/g/geoffwa/test/a/b/file Opened ./a/b/file from ./a using ./b/file Opened ./a/b/file from ./a using ./b/c/../file Failed to open ./a/b/file from ./a/b/c using ../file Failed to open ./a/b/file from ./a/b/c using ./../file Opened ./a/b/file from ./a/b using ./file Opened ./a/file from ./a/b using ./c/../../file Failed to open ./a/b/c/file from ./a/b/c using ../c/file -- Edit bug report at http://bugs.php.net/?id=41899edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41899r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41899r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41899r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=41899r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=41899r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=41899r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=41899r=needscript Try newer version:http://bugs.php.net/fix.php?id=41899r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=41899r=support Expected behavior:http://bugs.php.net/fix.php?id=41899r=notwrong Not enough info: http://bugs.php.net/fix.php?id=41899r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=41899r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=41899r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41899r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=41899r=dst IIS Stability:http://bugs.php.net/fix.php?id=41899r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=41899r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=41899r=float No Zend Extensions: http://bugs.php.net/fix.php?id=41899r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=41899r=mysqlcfg
#41900 [NEW]: unresolved external symbol
From: rok dot bermez at zavod-zviti dot si Operating system: Windows PHP version: 5.2.3 PHP Bug Type: Compile Failure Bug description: unresolved external symbol Description: Using functions such as RETURN_STRING, RETURN_STRING causes Error 1 error LNK2001: unresolved external symbol __imp___estrndupphp_hello.obj on VS2005 Reproduce code: --- Extension Writing Part I: Introduction to PHP and Zend demo code from http://devzone.zend.com/node/view/id/1021 . I added to the php_hello.c file for windows compatibility #define ZEND_WIN32 #define PHP_WIN32 #define ZEND_DEBUG 0 #define COMPILE_DL_PASS 1 #define ZTS 1 -- Edit bug report at http://bugs.php.net/?id=41900edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41900r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41900r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41900r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=41900r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=41900r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=41900r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=41900r=needscript Try newer version:http://bugs.php.net/fix.php?id=41900r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=41900r=support Expected behavior:http://bugs.php.net/fix.php?id=41900r=notwrong Not enough info: http://bugs.php.net/fix.php?id=41900r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=41900r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=41900r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41900r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=41900r=dst IIS Stability:http://bugs.php.net/fix.php?id=41900r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=41900r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=41900r=float No Zend Extensions: http://bugs.php.net/fix.php?id=41900r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=41900r=mysqlcfg
#41901 [NEW]: Parse error:parse error,unexpected '' in /usr/www/ogi/.../Work/www/index.php
From: ozahariev at yahoo dot com Operating system: linux PHP version: 5CVS-2007-07-05 (snap) PHP Bug Type: Compile Failure Bug description: Parse error:parse error,unexpected '' in /usr/www/ogi/.../Work/www/index.php Description: source at index.php line 16:: body onload=?php Reproduce code: --- Parse error: parse error, unexpected '' in /usr/www/ogi/Projects/Work/www/index.php on line 16 Expected result: anything else but not this. Actual result: -- Parse error: parse error, unexpected '' in /usr/www/ogi/Projects/Work/www/index.php on line 16 -- Edit bug report at http://bugs.php.net/?id=41901edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41901r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41901r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41901r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=41901r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=41901r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=41901r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=41901r=needscript Try newer version:http://bugs.php.net/fix.php?id=41901r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=41901r=support Expected behavior:http://bugs.php.net/fix.php?id=41901r=notwrong Not enough info: http://bugs.php.net/fix.php?id=41901r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=41901r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=41901r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41901r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=41901r=dst IIS Stability:http://bugs.php.net/fix.php?id=41901r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=41901r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=41901r=float No Zend Extensions: http://bugs.php.net/fix.php?id=41901r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=41901r=mysqlcfg
#41901 [Opn-Bgs]: Parse error:parse error,unexpected '' in /usr/www/ogi/.../Work/www/index.php
ID: 41901 Updated by: [EMAIL PROTECTED] Reported By: ozahariev at yahoo dot com -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: linux PHP Version: 5CVS-2007-07-05 (snap) 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-07-05 10:43:58] ozahariev at yahoo dot com Description: source at index.php line 16:: body onload=?php Reproduce code: --- Parse error: parse error, unexpected '' in /usr/www/ogi/Projects/Work/www/index.php on line 16 Expected result: anything else but not this. Actual result: -- Parse error: parse error, unexpected '' in /usr/www/ogi/Projects/Work/www/index.php on line 16 -- Edit this bug report at http://bugs.php.net/?id=41901edit=1
#32330 [Com]: session_destroy, Failed to initialize storage module, custom session handler
ID: 32330
Comment by: facingratio at email dot it
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Session related
Operating System: *
PHP Version: 6CVS, 5CVS, 4CVS (2005-03-17)
New Comment:
I confirm that the ini_set workaround doesn't work. The only solution i
found is to use the session_set_save_handler(...) again after you call
session_destroy(). Also session_write_close() followed by
session_start() seems to generate the same fatal error.
Previous Comments:
[2007-03-08 05:07:06] colossuswv at hotmail dot com
The ini_set workaround doesn't seem to work when using a db to store
sessions. Using session_set_save_handler() again after session destroy
does work however, albeit an undesirable solution.
[2006-12-14 17:24:03] faithfulsoft at tiscali dot it
I've experienced this problem today, and it was driving me crazy.
I was able to resolve it thanks to the last post on this page.
I've put this two lines of code
ini_set(session.save_handler, files);
session_start();
in a separate file, and I include them where I need.
The strange thing is that I borrowed the piece of code I am using from
a GPL portal system, which is working like a charm on my local server
with this line
ini_set('session.save_handler', 'files');
This is really strange.
Anyhow, thank you all guys.
[2006-06-07 04:26:18] sean at oteams dot com
I struggled for several days with the Failed to initialize storage
module: user problem. I read everything I could find on php.net and in
this bug database. Finally, what solved the problem for me was this:
Whenever I made a call in my code to session_start(), I used an include
statement to include the following from an include file:
?php
ini_set(session.save_handler, files);
session_start();
?
And that did it.
[2006-01-16 16:41:52] ajithts at gmail dot com
Hi folks,
I have also had the same problem. My /tmp was not a separate partition
and it had full permissions.
I have then changed session.save_handler to files in php.ini.
Initially it was user. Everything worked perfectly after I have
restarted httpd saving the changes.
Thanks and regards,
Ajith
[2005-06-04 00:25:54] [EMAIL PROTECTED]
PS(mod_data) gets set to NULL with these:
session_write_close(),
session_module_name('foo'),
session_destroy()
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/32330
--
Edit this bug report at http://bugs.php.net/?id=32330edit=1
#41903 [NEW]: imap_headerinfo for message/rfc822 attachments
From: jt at taajama dot fi Operating system: Solaris PHP version: 5.2.3 PHP Bug Type: IMAP related Bug description: imap_headerinfo for message/rfc822 attachments Description: Would it be possible to have imap_headerinfo kind of function which would accept section as parameter to have it parse message/rfc822 attachments? Similar to imap_bodystruct comparing to imap_fetchstructure. -- Edit bug report at http://bugs.php.net/?id=41903edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41903r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41903r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41903r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=41903r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=41903r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=41903r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=41903r=needscript Try newer version:http://bugs.php.net/fix.php?id=41903r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=41903r=support Expected behavior:http://bugs.php.net/fix.php?id=41903r=notwrong Not enough info: http://bugs.php.net/fix.php?id=41903r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=41903r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=41903r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41903r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=41903r=dst IIS Stability:http://bugs.php.net/fix.php?id=41903r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=41903r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=41903r=float No Zend Extensions: http://bugs.php.net/fix.php?id=41903r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=41903r=mysqlcfg
#41869 [Asn]: current time returned for haiti and Etc/GMT-* timezone incorrect
ID: 41869
Updated by: [EMAIL PROTECTED]
Reported By: gnupun at yahoo dot com
Status: Assigned
Bug Type: Date/time related
Operating System: windows xp
PHP Version: 5.2.3
Assigned To: derick
New Comment:
I updated the timezone database (you can use it by installing the
timezonedb extension from PECL).
However the following statement is *correct* behavior:
Eg: Etc/GMT+1 returns time 1 hour before Etc/GMT
Similarly, Etc/GMT-1 returns time 1 hour after Etc/GMT
This is how the timezone database does it - however, please try to
avoid using timezones like this as they do not take care of DST and the
like.
Previous Comments:
[2007-07-03 06:52:18] [EMAIL PROTECTED]
Derick, looks like the timezone DB needs an update.
[2007-07-02 07:44:57] gnupun at yahoo dot com
Description:
PHP returns incorrect time for the following timezones:
America/Port-au-Prince
Etc/GMT+*
Etc/GMT-*
where * is a digit 1-9.
Eg: Etc/GMT+1 returns time 1 hour before Etc/GMT
Similarly, Etc/GMT-1 returns time 1 hour after Etc/GMT
Reproduce code:
---
function print_current_time($timezone) {
date_default_timezone_set($timezone);
$s = strftime(%I:%M:%S %p %d %B %Y);
printf(%20s: %s\n, $timezone, $s);
}
print_current_time('America/Port-au-Prince');
print_current_time('Etc/GMT');
print_current_time('Etc/GMT+1');
print_current_time('Etc/GMT-1');
Expected result:
America/Port-au-Prince: 02:36:53 AM 02 July 2007
Etc/GMT: 07:36:53 AM 02 July 2007
Etc/GMT+1: 08:36:53 AM 02 July 2007
Etc/GMT-1: 06:36:53 AM 02 July 2007
Actual result:
--
America/Port-au-Prince: 03:36:53 AM 02 July 2007
Etc/GMT: 07:36:53 AM 02 July 2007
Etc/GMT+1: 06:36:53 AM 02 July 2007
Etc/GMT-1: 08:36:53 AM 02 July 2007
--
Edit this bug report at http://bugs.php.net/?id=41869edit=1
#41900 [Opn-Bgs]: unresolved external symbol
ID: 41900 Updated by: [EMAIL PROTECTED] Reported By: rok dot bermez at zavod-zviti dot si -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: Windows PHP Version: 5.2.3 New Comment: 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. Previous Comments: [2007-07-05 10:43:33] rok dot bermez at zavod-zviti dot si Description: Using functions such as RETURN_STRING, RETURN_STRING causes Error 1 error LNK2001: unresolved external symbol __imp___estrndupphp_hello.obj on VS2005 Reproduce code: --- Extension Writing Part I: Introduction to PHP and Zend demo code from http://devzone.zend.com/node/view/id/1021 . I added to the php_hello.c file for windows compatibility #define ZEND_WIN32 #define PHP_WIN32 #define ZEND_DEBUG 0 #define COMPILE_DL_PASS 1 #define ZTS 1 -- Edit this bug report at http://bugs.php.net/?id=41900edit=1
#41904 [NEW]: proc_open with empty array as $env uses $_ENV of parent
From: martin dot partel at mbnet dot fi
Operating system: Linux
PHP version: 5.2.3
PHP Bug Type: Program Execution
Bug description: proc_open with empty array as $env uses $_ENV of parent
Description:
The documentation of proc_open states that passing NULL as the $env
parameter of proc_open has the child process use the same
environment as the current PHP process. Passing an empty array seems
to have the same effect, even though intuitively it should give the
child process an empty environment.
Reproduce code:
---
?php
echo 'pre';
$descriptorspec = array(
0 = array(pipe, r),
1 = array(pipe, w),
);
$cwd = '/tmp';
$env = array();
$process = proc_open('php', $descriptorspec, $pipes, $cwd, $env);
if (is_resource($process)) {
fwrite($pipes[0], '?php print_r($_ENV); ?');
fclose($pipes[0]);
echo stream_get_contents($pipes[1]);
fclose($pipes[1]);
proc_close($process);
}
Expected result:
The script should output an (almost) empty $_ENV.
Actual result:
--
The script outputs the $_ENV of the parent process.
--
Edit bug report at http://bugs.php.net/?id=41904edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41904r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41904r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41904r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41904r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41904r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41904r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41904r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41904r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41904r=support
Expected behavior:http://bugs.php.net/fix.php?id=41904r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41904r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41904r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41904r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41904r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41904r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41904r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41904r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41904r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41904r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41904r=mysqlcfg
#41903 [Opn]: imap_headerinfo for message/rfc822 attachments
ID: 41903 Updated by: [EMAIL PROTECTED] Reported By: jt at taajama dot fi Status: Open -Bug Type: IMAP related +Bug Type: Feature/Change Request Operating System: Solaris PHP Version: 5.2.3 New Comment: Reclassified as feature request. Feel free to send a patch. Previous Comments: [2007-07-05 13:21:45] jt at taajama dot fi Description: Would it be possible to have imap_headerinfo kind of function which would accept section as parameter to have it parse message/rfc822 attachments? Similar to imap_bodystruct comparing to imap_fetchstructure. -- Edit this bug report at http://bugs.php.net/?id=41903edit=1
#41898 [Opn-Fbk]: mysqli_* functions missing
ID: 41898
Updated by: [EMAIL PROTECTED]
Reported By: ben at popator dot com
-Status: Open
+Status: Feedback
Bug Type: MySQLi related
Operating System: CentOS 4.5 x86_64
PHP Version: 5.2.3
New Comment:
Cannot reproduce.
Try to remove all the configure options and leave only --with-mysqli
and then add options one by one to see which one causes the problem.
Previous Comments:
[2007-07-05 01:09:04] ben at popator dot com
Description:
PHP 5.2.3 fails to implement mysqli functions in conjunction with
mysql.
phpinfo() reports MySQL and MySQLi as being available.
Attempted workarounds as detailed at
http://www.kofler.cc/forum/forumthread.php?rootID=3571 without any
success.
MySQL Version: 4.1.21
Configure:
'./configure' '--enable-pic' '--with-libdir=lib64'
'--prefix=/usr/local' '--with-xml' '--enable-bcmath' '--enable-calendar'
'--with-curl' '--with-dom' '--with-dom-xslt' '--with-dom-exslt'
'--enable-exif' '--enable-ftp' '--with-gd' '--with-jpeg-dir=/usr/local'
'--with-png-dir=/usr' '--with-xpm-dir=/usr/X11R6' '--with-gettext'
'--with-iconv' '--with-imap=/usr/local/imap-2004g' '--enable-mbstring'
'--enable-mbstr-enc-trans' '--enable-mbregex' '--with-mcrypt'
'--with-mhash' '--enable-magic-quotes' '--with-mysql=/usr'
'--with-mysqli=/usr/bin/mysql_config' '--with-snmp'
'--enable-ucd-snmp-hack' '--with-openssl' '--with-pear' '--with-pspell'
'--enable-sockets' '--enable-track-vars' '--with-ttf'
'--with-freetype-dir=/usr' '--enable-gd-native-ttf' '--enable-wddx'
'--with-xmlrpc' '--with-zip' '--with-zlib' '--prefix=/usr/local/php5'
'--exec-prefix=/usr/local/php5' '--program-suffix=5'
'--enable-force-cgi-redirect' '--disable-discard-path'
'--with-pdo-mysql'
Reproduce code:
---
?php
$foo = function_exists('mysqli_connect');
if ($foo) {
echo Mysqli available;
} else {
echo Mysqli not available;
}
Expected result:
Mysqli available
Actual result:
--
Mysqli not available
--
Edit this bug report at http://bugs.php.net/?id=41898edit=1
#41859 [Opn-Fbk]: Low throughput with readfile/fpassthru
ID: 41859
Updated by: [EMAIL PROTECTED]
Reported By: champs dot name at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: Performance problem
Operating System: Windows Server 2003/IIS6
PHP Version: 5.2.3
New Comment:
We don't have any win32 developers at the moment and I would appreciate
if you provide any info you can gather in order to help us to understand
the issue.
Previous Comments:
[2007-07-03 17:34:52] champs dot name at gmail dot com
This does not appear to be a problem with Apache 2 + PHP5 + Linux,
performance numbers are within 5% of eachother.
While I cannot test the Apache + Win32 combination, I can look at the
PHP source to say that it does not appear to be something in the
ISAPI-specific code, although it may have something to do with the
affected code's interaction with IIS.
[2007-07-03 06:54:54] [EMAIL PROTECTED]
Did you try to reproduce on *nix ?
[2007-06-30 11:58:31] judas dot iscariote at gmail dot com
You have to choose between readfile() and your code, readfile is
designed to be fast AND use few memory.
The best way you have to do this is simple. DO NOT serve files through
PHP :) use mod_secdownload and/or X-SendFile with lighttpd...with apache
use mod_auth_token and/or mod_sendfile to make the webserver itself to
serve the file
[2007-06-29 22:10:08] champs dot name at gmail dot com
Description:
With a client using a 10Mbps connection, it is possible to saturate the
pipe using print(fread(...)) in chunks of 32K or larger, but the
throughput of fpassthru() and readfile() is consistently ~1/3 of that
speed. On the other side of the coin, a client with sub-Mbit DSL is not
able to complete 100MB downloads at all, unless readfile/fpassthru() is
used.
This has been tested in different orders, at different times of day,
and on different, non-consecutive days.
Reproduce code:
---
if ($file = fopen($path, $mode)) {
$chunk_size = 32;
while(!feof($file)) {
print(fread($file, $chunk_size * 1024));
if (connection_status() == 0) {
flush();
}
else {
break;
}
}
fclose($file);
}
Expected result:
Similar throughput if while() block is replaced with fpassthru($file)
or readfile($path).
Actual result:
--
File is served at over 900kB/s with fread(), less than 300kB/s with
fpassthru/readfile().
--
Edit this bug report at http://bugs.php.net/?id=41859edit=1
#41877 [Opn-Fbk]: Trying to insert multiple BLOBs on oracle with pdo_oci hangs up Apache
ID: 41877
Updated by: [EMAIL PROTECTED]
Reported By: jarismar at adplabs dot com dot br
-Status: Open
+Status: Feedback
Bug Type: PDO related
Operating System: Windows
PHP Version: 5.2.3
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
Previous Comments:
[2007-07-02 20:21:08] jarismar at adplabs dot com dot br
Running the script from command line seems to work fine.
Apache version is 2.0.59 I'll trying an upgrade.
[2007-07-02 20:04:09] jarismar at adplabs dot com dot br
Description:
Unable to read BLOBs from a given table and insert on another one,
because php hangs up after inserting the first record on destination
table.
Reproduce code:
---
SQL:
CREATE TABLE TBL_BLOB (id NUMBER(10), data BLOB);
CREATE TABLE TBL_BLOB2 (id NUMBER(10), data BLOB);
You will need to insert some records on TBL_BLOB.
PHP:
try {
$oPDO = new PDO($sDSN, $sUserName, $sPassword);
$oPDO-beginTransaction();
$sSQLRead = 'SELECT ID, DATA FROM TBL_BLOB';
$oStmtRead = $oPDO-prepare($sSQLRead);
$oStmtRead-execute();
$sSQLWrite = 'INSERT INTO TBL_BLOB2 (ID, DATA) VALUES (:id,
EMPTY_BLOB()) RETURNING DATA INTO :stream';
$oStmtWrite = $oPDO-prepare($sSQLWrite);
while (($aRow = $oStmtRead-fetch())) {
$iID = $aRow['ID'];
$rData = $aRow['DATA'];
if (is_resource($rData)) {
$sData = stream_get_contents($rData);
fclose($rData);
} else {
throw new Exception('Error fetching stream');
}
$oStmtWrite-bindParam(':id', $iID);
$oStmtWrite-bindParam(':stream', $resource, PDO::PARAM_LOB);
$oStmtWrite-execute();
if (is_resource($resource)) {
fwrite($resource, $sData);
fclose($resource);
} else {
throw new Exception('Error fetching stream');
}
}
$oStmtRead-closeCursor();
$oPDO-commit();
} catch (Exception $oE) {
$oPDO-rollBack();
throw $oE;
}
$oPDO = null;
Expected result:
No output, but TBL_BLOB2 should have same records from TBL_BLOB.
Actual result:
--
Apache hangs up, the page keeps loading forever.
Simply trying to debug the script I see no error, the script finishes
normally, but Apache does not send any response.
Uncommenting the fclose(stream) command then debugging, the debugger
stops after writing to TBL_BLOB2 on the second record.
--
Edit this bug report at http://bugs.php.net/?id=41877edit=1
#41877 [Fbk]: Trying to insert multiple BLOBs on oracle with pdo_oci hangs up Apache
ID: 41877
Updated by: [EMAIL PROTECTED]
Reported By: jarismar at adplabs dot com dot br
Status: Feedback
Bug Type: PDO related
Operating System: Windows
PHP Version: 5.2.3
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.
Wrong button. sorry.
Previous Comments:
[2007-07-02 20:21:08] jarismar at adplabs dot com dot br
Running the script from command line seems to work fine.
Apache version is 2.0.59 I'll trying an upgrade.
[2007-07-02 20:04:09] jarismar at adplabs dot com dot br
Description:
Unable to read BLOBs from a given table and insert on another one,
because php hangs up after inserting the first record on destination
table.
Reproduce code:
---
SQL:
CREATE TABLE TBL_BLOB (id NUMBER(10), data BLOB);
CREATE TABLE TBL_BLOB2 (id NUMBER(10), data BLOB);
You will need to insert some records on TBL_BLOB.
PHP:
try {
$oPDO = new PDO($sDSN, $sUserName, $sPassword);
$oPDO-beginTransaction();
$sSQLRead = 'SELECT ID, DATA FROM TBL_BLOB';
$oStmtRead = $oPDO-prepare($sSQLRead);
$oStmtRead-execute();
$sSQLWrite = 'INSERT INTO TBL_BLOB2 (ID, DATA) VALUES (:id,
EMPTY_BLOB()) RETURNING DATA INTO :stream';
$oStmtWrite = $oPDO-prepare($sSQLWrite);
while (($aRow = $oStmtRead-fetch())) {
$iID = $aRow['ID'];
$rData = $aRow['DATA'];
if (is_resource($rData)) {
$sData = stream_get_contents($rData);
fclose($rData);
} else {
throw new Exception('Error fetching stream');
}
$oStmtWrite-bindParam(':id', $iID);
$oStmtWrite-bindParam(':stream', $resource, PDO::PARAM_LOB);
$oStmtWrite-execute();
if (is_resource($resource)) {
fwrite($resource, $sData);
fclose($resource);
} else {
throw new Exception('Error fetching stream');
}
}
$oStmtRead-closeCursor();
$oPDO-commit();
} catch (Exception $oE) {
$oPDO-rollBack();
throw $oE;
}
$oPDO = null;
Expected result:
No output, but TBL_BLOB2 should have same records from TBL_BLOB.
Actual result:
--
Apache hangs up, the page keeps loading forever.
Simply trying to debug the script I see no error, the script finishes
normally, but Apache does not send any response.
Uncommenting the fclose(stream) command then debugging, the debugger
stops after writing to TBL_BLOB2 on the second record.
--
Edit this bug report at http://bugs.php.net/?id=41877edit=1
#41905 [NEW]: Incorrect String Compare with '=='
From: domluc at gmail dot com Operating system: GNU/Linux Debian PHP version: 4.4.7 PHP Bug Type: Strings related Bug description: Incorrect String Compare with '==' Description: Obs:This bug hape in PHP 4.4.x and 5.2.x I have a string with 17bytes, sample: code $var1 = '000650719'; $var2 = '000650718'; /code if I compare these strings with: code if ( $var1 == $var2) echo Equal else echo 'Not Equal' /code it will print Equal, but this is incorrect. The solution to correct do this, is using '===': $var1 === $var2 But this behavior is wrong. I beliave that when php engine compare with '==' it cast variables to integer, and 17th byte is ignored! -- Edit bug report at http://bugs.php.net/?id=41905edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41905r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41905r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41905r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=41905r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=41905r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=41905r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=41905r=needscript Try newer version:http://bugs.php.net/fix.php?id=41905r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=41905r=support Expected behavior:http://bugs.php.net/fix.php?id=41905r=notwrong Not enough info: http://bugs.php.net/fix.php?id=41905r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=41905r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=41905r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41905r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=41905r=dst IIS Stability:http://bugs.php.net/fix.php?id=41905r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=41905r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=41905r=float No Zend Extensions: http://bugs.php.net/fix.php?id=41905r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=41905r=mysqlcfg
#41869 [Asn-Csd]: current time returned for haiti and Etc/GMT-* timezone incorrect
ID: 41869
Updated by: [EMAIL PROTECTED]
Reported By: gnupun at yahoo dot com
-Status: Assigned
+Status: Closed
Bug Type: Date/time related
Operating System: windows xp
PHP Version: 5.2.3
Assigned To: derick
Previous Comments:
[2007-07-05 13:51:26] [EMAIL PROTECTED]
I updated the timezone database (you can use it by installing the
timezonedb extension from PECL).
However the following statement is *correct* behavior:
Eg: Etc/GMT+1 returns time 1 hour before Etc/GMT
Similarly, Etc/GMT-1 returns time 1 hour after Etc/GMT
This is how the timezone database does it - however, please try to
avoid using timezones like this as they do not take care of DST and the
like.
[2007-07-03 06:52:18] [EMAIL PROTECTED]
Derick, looks like the timezone DB needs an update.
[2007-07-02 07:44:57] gnupun at yahoo dot com
Description:
PHP returns incorrect time for the following timezones:
America/Port-au-Prince
Etc/GMT+*
Etc/GMT-*
where * is a digit 1-9.
Eg: Etc/GMT+1 returns time 1 hour before Etc/GMT
Similarly, Etc/GMT-1 returns time 1 hour after Etc/GMT
Reproduce code:
---
function print_current_time($timezone) {
date_default_timezone_set($timezone);
$s = strftime(%I:%M:%S %p %d %B %Y);
printf(%20s: %s\n, $timezone, $s);
}
print_current_time('America/Port-au-Prince');
print_current_time('Etc/GMT');
print_current_time('Etc/GMT+1');
print_current_time('Etc/GMT-1');
Expected result:
America/Port-au-Prince: 02:36:53 AM 02 July 2007
Etc/GMT: 07:36:53 AM 02 July 2007
Etc/GMT+1: 08:36:53 AM 02 July 2007
Etc/GMT-1: 06:36:53 AM 02 July 2007
Actual result:
--
America/Port-au-Prince: 03:36:53 AM 02 July 2007
Etc/GMT: 07:36:53 AM 02 July 2007
Etc/GMT+1: 06:36:53 AM 02 July 2007
Etc/GMT-1: 08:36:53 AM 02 July 2007
--
Edit this bug report at http://bugs.php.net/?id=41869edit=1
#41905 [Opn-Bgs]: Incorrect String Compare with '=='
ID: 41905 Updated by: [EMAIL PROTECTED] Reported By: domluc at gmail dot com -Status: Open +Status: Bogus Bug Type: Strings related Operating System: GNU/Linux Debian PHP Version: 4.4.7 New Comment: '==' will see the strings as numeric values, use === if you expect a type safe comparison (as you noticed and documented). Previous Comments: [2007-07-05 14:20:27] domluc at gmail dot com Description: Obs:This bug hape in PHP 4.4.x and 5.2.x I have a string with 17bytes, sample: code $var1 = '000650719'; $var2 = '000650718'; /code if I compare these strings with: code if ( $var1 == $var2) echo Equal else echo 'Not Equal' /code it will print Equal, but this is incorrect. The solution to correct do this, is using '===': $var1 === $var2 But this behavior is wrong. I beliave that when php engine compare with '==' it cast variables to integer, and 17th byte is ignored! -- Edit this bug report at http://bugs.php.net/?id=41905edit=1
#41905 [Bgs]: Incorrect String Compare with '=='
ID: 41905 User updated by: domluc at gmail dot com Reported By: domluc at gmail dot com Status: Bogus Bug Type: Strings related Operating System: GNU/Linux Debian PHP Version: 4.4.7 New Comment: Ok, I know way to do this,but, I think this is incorrect. The auto cast trunk the variable without warning. Previous Comments: [2007-07-05 14:28:11] [EMAIL PROTECTED] '==' will see the strings as numeric values, use === if you expect a type safe comparison (as you noticed and documented). [2007-07-05 14:20:27] domluc at gmail dot com Description: Obs:This bug hape in PHP 4.4.x and 5.2.x I have a string with 17bytes, sample: code $var1 = '000650719'; $var2 = '000650718'; /code if I compare these strings with: code if ( $var1 == $var2) echo Equal else echo 'Not Equal' /code it will print Equal, but this is incorrect. The solution to correct do this, is using '===': $var1 === $var2 But this behavior is wrong. I beliave that when php engine compare with '==' it cast variables to integer, and 17th byte is ignored! -- Edit this bug report at http://bugs.php.net/?id=41905edit=1
#41906 [NEW]: slow local mysql_connect
From: kkr at mit dot de Operating system: Windows 2000 PHP version: 5.2.3 PHP Bug Type: Performance problem Bug description: slow local mysql_connect Description: Between 5.2.1 and 5.2.2 the PHP connects much slower to a local mysql5 installation running under apache/windows 2000. It now takes 5 seconds more to a simple connect which at least does work after that time. In the changelog I've seen a new mysql client lib used starting from 5.2.2 upwards, anyone else has these problems too? The 5.2.3 still has the same behavior. A connect is either via TCP or via named pipe/socket possible but slow. Local graphical frontends to the database are as fast as always. MySQL version is the latest released one 5.0.41. Reproduce code: --- the usual mysql_connect() Expected result: I expect a connect time from 200ms and experience 5500ms now. -- Edit bug report at http://bugs.php.net/?id=41906edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41906r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41906r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41906r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=41906r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=41906r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=41906r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=41906r=needscript Try newer version:http://bugs.php.net/fix.php?id=41906r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=41906r=support Expected behavior:http://bugs.php.net/fix.php?id=41906r=notwrong Not enough info: http://bugs.php.net/fix.php?id=41906r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=41906r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=41906r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41906r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=41906r=dst IIS Stability:http://bugs.php.net/fix.php?id=41906r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=41906r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=41906r=float No Zend Extensions: http://bugs.php.net/fix.php?id=41906r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=41906r=mysqlcfg
#41907 [NEW]: wrong result from round(64.365,2)
From: milman at gmx dot de Operating system: windows xp PHP version: 5.2.3 PHP Bug Type: *Math Functions Bug description: wrong result from round(64.365,2) Description: wrong result from round(64.365,2) should be 64.37 not 64.36 Reproduce code: --- ? echo right: round (63.365,2) = . round (63.365,2) . br\n ; echo wrong: round (64.365,2) = . round (64.365,2) . br\n ; echo wrong: round (81.365,2) = . round (81.365,2) . br\n ; echo right: round (82.365,2) = . round (82.365,2) . br\n ; ? Expected result: allway .37 not somtimes .36 -- Edit bug report at http://bugs.php.net/?id=41907edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41907r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41907r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41907r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=41907r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=41907r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=41907r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=41907r=needscript Try newer version:http://bugs.php.net/fix.php?id=41907r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=41907r=support Expected behavior:http://bugs.php.net/fix.php?id=41907r=notwrong Not enough info: http://bugs.php.net/fix.php?id=41907r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=41907r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=41907r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41907r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=41907r=dst IIS Stability:http://bugs.php.net/fix.php?id=41907r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=41907r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=41907r=float No Zend Extensions: http://bugs.php.net/fix.php?id=41907r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=41907r=mysqlcfg
#41907 [Opn-Bgs]: wrong result from round(64.365,2)
ID: 41907 Updated by: [EMAIL PROTECTED] Reported By: milman at gmx dot de -Status: Open +Status: Bogus Bug Type: *Math Functions Operating System: windows xp PHP Version: 5.2.3 New Comment: Floating point values have a limited precision. Hence a value might not have the same string representation after any processing. That also includes writing a floating point value in your script and directly printing it without any mathematical operations. If you would like to know more about floats and what IEEE 754 is read this: http://docs.sun.com/source/806-3568/ncg_goldberg.html Thank you for your interest in PHP. . Previous Comments: [2007-07-05 16:27:24] milman at gmx dot de Description: wrong result from round(64.365,2) should be 64.37 not 64.36 Reproduce code: --- ? echo right: round (63.365,2) = . round (63.365,2) . br\n ; echo wrong: round (64.365,2) = . round (64.365,2) . br\n ; echo wrong: round (81.365,2) = . round (81.365,2) . br\n ; echo right: round (82.365,2) = . round (82.365,2) . br\n ; ? Expected result: allway .37 not somtimes .36 -- Edit this bug report at http://bugs.php.net/?id=41907edit=1
#41909 [NEW]: var_export
From: stingbat at stingbat dot dk Operating system: Windows PHP version: 5.2.3 PHP Bug Type: Variables related Bug description: var_export Description: Seems like there has been a change to the var_export-function, when comparing PHP4 and PHP5, as stated below: PHP4 314 : case IS_DOUBLE: 315 8 : php_printf(%.*G, (int) EG(precision), Z_DVAL_PP(struc)); from: http://gcov.php.net/PHP_4_4/lcov_html/ext/standard/var.c.gcov.php PHP5 407 : case IS_DOUBLE: 408 42 : php_printf(%.*H, (int) EG(precision), Z_DVAL_PP(struc)); from: http://gcov.php.net/PHP_5_2/lcov_html/ext/standard/var.c.gcov.php Of some reason, the output don't give the same. I don't know if it's PHP4 that has always had this problem, or if it's a new problem only existing in PHP5. However, it gives difficulties, if trying to compare the results or want to output the results float-values to either JavaScript or Database. And especially when trying to create scripts that should work on both PHP-versions (4.x+5.x). Reproduce code: --- ?php $test_value = 1.50; setlocale(LC_ALL, 'da_DK.iso-8859-1', 'da_DK', 'danish', 'da'); echo 'DK: ' . var_export($test_value, TRUE) . \n; setlocale(LC_ALL, 'en'); echo 'EN: ' . var_export($test_value, TRUE) . \n; echo \n . PHP_VERSION; ? Expected result: DK: 1.5 EN: 1.5 Actual result: -- DK: 1,5 EN: 1.5 -- Edit bug report at http://bugs.php.net/?id=41909edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41909r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41909r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41909r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=41909r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=41909r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=41909r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=41909r=needscript Try newer version:http://bugs.php.net/fix.php?id=41909r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=41909r=support Expected behavior:http://bugs.php.net/fix.php?id=41909r=notwrong Not enough info: http://bugs.php.net/fix.php?id=41909r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=41909r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=41909r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41909r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=41909r=dst IIS Stability:http://bugs.php.net/fix.php?id=41909r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=41909r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=41909r=float No Zend Extensions: http://bugs.php.net/fix.php?id=41909r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=41909r=mysqlcfg
#41908 [NEW]: CFLAGS=-Os ./configure --enable-debug fails
From: christian at hoffie dot info Operating system: Gentoo Linux PHP version: 5.2.3 PHP Bug Type: *Compile Issues Bug description: CFLAGS=-Os ./configure --enable-debug fails Description: PHP's configure script incorrectly manipulates CFLAGS and CXXFLAGS when running with --enable-debug or --enable-gcov. When CFLAGS or CXXFLAGS contains -Os (optimize for size), the configure script builds a bad list of CFLAGS/CXXFLAGS and as such configure fails in a later stage. I created a small patch[1] which should solve that, I'm not completely sure whether it's a good idea to remove that -O stuff at all -- does appending -O0 after user-supplied flags not lead to the expected result (building with -O0 and not -O2 for instance)? [1] http://overlays.gentoo.org/proj/php/browser/patches/php-patches/5.2.3/5.2.3/php5.2.3-configure-Os-fix.patch?rev=1237 Reproduce code: --- CFLAGS=-Os ./configure --enable-debug (same if you replace CFLAGS by CXXFLAGS or --enable-debug with --enable-gcov) Actual result: -- [EMAIL PROTECTED] /tmp/php-5.2.3 $ env | grep FLAGS CXXFLAGS=-Os CFLAGS=-Os [EMAIL PROTECTED] /tmp/php-5.2.3 $ ./configure --disable-all --enable-debug [...] Configuring libtool checking build system type... i686-pc-linux-gnu checking for ld used by gcc... /usr/i686-pc-linux-gnu/bin/ld checking if the linker (/usr/i686-pc-linux-gnu/bin/ld) is GNU ld... yes checking for /usr/i686-pc-linux-gnu/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking how to recognise dependent libraries... pass_all checking for object suffix... configure: error: installation or configuration problem; compiler does not work Depending on ./configure options the output looks different. For example, with --with-xml you will see a libxml2 failure first. -- Edit bug report at http://bugs.php.net/?id=41908edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41908r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41908r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41908r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=41908r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=41908r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=41908r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=41908r=needscript Try newer version:http://bugs.php.net/fix.php?id=41908r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=41908r=support Expected behavior:http://bugs.php.net/fix.php?id=41908r=notwrong Not enough info: http://bugs.php.net/fix.php?id=41908r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=41908r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=41908r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41908r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=41908r=dst IIS Stability:http://bugs.php.net/fix.php?id=41908r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=41908r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=41908r=float No Zend Extensions: http://bugs.php.net/fix.php?id=41908r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=41908r=mysqlcfg
#41909 [Opn-Fbk]: var_export
ID: 41909 Updated by: [EMAIL PROTECTED] Reported By: stingbat at stingbat dot dk -Status: Open +Status: Feedback Bug Type: Variables related Operating System: Windows PHP Version: 5.2.3 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 I already fixed this I think... please try the snapshot. But are you really on Windows? Previous Comments: [2007-07-05 17:11:05] stingbat at stingbat dot dk Description: Seems like there has been a change to the var_export-function, when comparing PHP4 and PHP5, as stated below: PHP4 314 : case IS_DOUBLE: 315 8 : php_printf(%.*G, (int) EG(precision), Z_DVAL_PP(struc)); from: http://gcov.php.net/PHP_4_4/lcov_html/ext/standard/var.c.gcov.php PHP5 407 : case IS_DOUBLE: 408 42 : php_printf(%.*H, (int) EG(precision), Z_DVAL_PP(struc)); from: http://gcov.php.net/PHP_5_2/lcov_html/ext/standard/var.c.gcov.php Of some reason, the output don't give the same. I don't know if it's PHP4 that has always had this problem, or if it's a new problem only existing in PHP5. However, it gives difficulties, if trying to compare the results or want to output the results float-values to either JavaScript or Database. And especially when trying to create scripts that should work on both PHP-versions (4.x+5.x). Reproduce code: --- ?php $test_value = 1.50; setlocale(LC_ALL, 'da_DK.iso-8859-1', 'da_DK', 'danish', 'da'); echo 'DK: ' . var_export($test_value, TRUE) . \n; setlocale(LC_ALL, 'en'); echo 'EN: ' . var_export($test_value, TRUE) . \n; echo \n . PHP_VERSION; ? Expected result: DK: 1.5 EN: 1.5 Actual result: -- DK: 1,5 EN: 1.5 -- Edit this bug report at http://bugs.php.net/?id=41909edit=1
#41907 [Bgs]: wrong result from round(64.365,2)
ID: 41907 User updated by: milman at gmx dot de Reported By: milman at gmx dot de Status: Bogus Bug Type: *Math Functions Operating System: windows xp PHP Version: 5.2.3 New Comment: sorry but i can't accept this answer. for me it seem like, round-problem than bogus and standard answer. php use common round (Symmetric Arithmetic Rounding) Decide which is the last digit to keep. Increase it by 1 if the next digit is 5 or more (this is called rounding up) Leave it the same if the next digit is 4 or less (this is called rounding down) and then round (8.155, 2) is 8.16 and not 8.15 sprintf (%15.8f, 8.155) is 08.1550 so it is not a problem from intern representation. the rounding problem occurs at number_format and sprintf too. round Previous Comments: [2007-07-05 16:30:05] [EMAIL PROTECTED] Floating point values have a limited precision. Hence a value might not have the same string representation after any processing. That also includes writing a floating point value in your script and directly printing it without any mathematical operations. If you would like to know more about floats and what IEEE 754 is read this: http://docs.sun.com/source/806-3568/ncg_goldberg.html Thank you for your interest in PHP. . [2007-07-05 16:27:24] milman at gmx dot de Description: wrong result from round(64.365,2) should be 64.37 not 64.36 Reproduce code: --- ? echo right: round (63.365,2) = . round (63.365,2) . br\n ; echo wrong: round (64.365,2) = . round (64.365,2) . br\n ; echo wrong: round (81.365,2) = . round (81.365,2) . br\n ; echo right: round (82.365,2) = . round (82.365,2) . br\n ; ? Expected result: allway .37 not somtimes .36 -- Edit this bug report at http://bugs.php.net/?id=41907edit=1
#41907 [Bgs]: wrong result from round(64.365,2)
ID: 41907 Updated by: [EMAIL PROTECTED] Reported By: milman at gmx dot de Status: Bogus Bug Type: *Math Functions Operating System: windows xp PHP Version: 5.2.3 New Comment: php -r 'echo sprintf(%15.20f, 8.155);' 8.15436051 Previous Comments: [2007-07-05 18:48:25] milman at gmx dot de sorry but i can't accept this answer. for me it seem like, round-problem than bogus and standard answer. php use common round (Symmetric Arithmetic Rounding) Decide which is the last digit to keep. Increase it by 1 if the next digit is 5 or more (this is called rounding up) Leave it the same if the next digit is 4 or less (this is called rounding down) and then round (8.155, 2) is 8.16 and not 8.15 sprintf (%15.8f, 8.155) is 08.1550 so it is not a problem from intern representation. the rounding problem occurs at number_format and sprintf too. round [2007-07-05 16:30:05] [EMAIL PROTECTED] Floating point values have a limited precision. Hence a value might not have the same string representation after any processing. That also includes writing a floating point value in your script and directly printing it without any mathematical operations. If you would like to know more about floats and what IEEE 754 is read this: http://docs.sun.com/source/806-3568/ncg_goldberg.html Thank you for your interest in PHP. . [2007-07-05 16:27:24] milman at gmx dot de Description: wrong result from round(64.365,2) should be 64.37 not 64.36 Reproduce code: --- ? echo right: round (63.365,2) = . round (63.365,2) . br\n ; echo wrong: round (64.365,2) = . round (64.365,2) . br\n ; echo wrong: round (81.365,2) = . round (81.365,2) . br\n ; echo right: round (82.365,2) = . round (82.365,2) . br\n ; ? Expected result: allway .37 not somtimes .36 -- Edit this bug report at http://bugs.php.net/?id=41907edit=1
#41907 [Bgs]: wrong result from round(64.365,2)
ID: 41907
User updated by: milman at gmx dot de
Reported By: milman at gmx dot de
Status: Bogus
Bug Type: *Math Functions
Operating System: windows xp
PHP Version: 5.2.3
New Comment:
ok,
but that is the same for other numbers too.
function tround ($r0)
{
$rr0 = round ($r0,2) ;
$str1 = sprintf (%015.20f, $r0) ;
echo $r0 : $rr0 $str1br\n ;
}
tround (8.055,2) ;
tround (8.155,2) ;
tround (8.255,2) ;
8.055 : 8.06 8.05471578
8.155 : 8.15 8.15436051
8.255 : 8.26 8.25578160
so i don't understand it.
for me it is a bug.
Previous Comments:
[2007-07-05 18:50:48] [EMAIL PROTECTED]
php -r 'echo sprintf(%15.20f, 8.155);'
8.15436051
[2007-07-05 18:48:25] milman at gmx dot de
sorry but i can't accept this answer.
for me it seem like, round-problem than bogus and standard answer.
php use common round (Symmetric Arithmetic Rounding)
Decide which is the last digit to keep.
Increase it by 1 if the next digit is 5 or more (this is called
rounding up)
Leave it the same if the next digit is 4 or less (this is called
rounding down)
and then round (8.155, 2) is 8.16 and not 8.15
sprintf (%15.8f, 8.155) is 08.1550
so it is not a problem from intern representation.
the rounding problem occurs at number_format and sprintf too.
round
[2007-07-05 16:30:05] [EMAIL PROTECTED]
Floating point values have a limited precision. Hence a value might
not have the same string representation after any processing. That also
includes writing a floating point value in your script and directly
printing it without any mathematical operations.
If you would like to know more about floats and what IEEE
754 is read this:
http://docs.sun.com/source/806-3568/ncg_goldberg.html
Thank you for your interest in PHP.
.
[2007-07-05 16:27:24] milman at gmx dot de
Description:
wrong result from round(64.365,2)
should be 64.37 not 64.36
Reproduce code:
---
?
echo right: round (63.365,2) = . round (63.365,2) . br\n ;
echo wrong: round (64.365,2) = . round (64.365,2) . br\n ;
echo wrong: round (81.365,2) = . round (81.365,2) . br\n ;
echo right: round (82.365,2) = . round (82.365,2) . br\n ;
?
Expected result:
allway .37 not somtimes .36
--
Edit this bug report at http://bugs.php.net/?id=41907edit=1
#41909 [Fbk-Csd]: var_export
ID: 41909 User updated by: stingbat at stingbat dot dk Reported By: stingbat at stingbat dot dk -Status: Feedback +Status: Closed Bug Type: Variables related Operating System: Windows PHP Version: 5.2.3 New Comment: Has it just been fixed? Wasn't able to find any bug related to this issue, but could just see that there was a problem with PHP 5.2.3 (on multiple both Windows 2000 and XP). Seems like it is fixed in the CVS snapshot, as far as I can see. Thanks for the quick reply :) Do you know in how many version of PHP5, the issue has existed? Previous Comments: [2007-07-05 17:33:48] [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 I already fixed this I think... please try the snapshot. But are you really on Windows? [2007-07-05 17:11:05] stingbat at stingbat dot dk Description: Seems like there has been a change to the var_export-function, when comparing PHP4 and PHP5, as stated below: PHP4 314 : case IS_DOUBLE: 315 8 : php_printf(%.*G, (int) EG(precision), Z_DVAL_PP(struc)); from: http://gcov.php.net/PHP_4_4/lcov_html/ext/standard/var.c.gcov.php PHP5 407 : case IS_DOUBLE: 408 42 : php_printf(%.*H, (int) EG(precision), Z_DVAL_PP(struc)); from: http://gcov.php.net/PHP_5_2/lcov_html/ext/standard/var.c.gcov.php Of some reason, the output don't give the same. I don't know if it's PHP4 that has always had this problem, or if it's a new problem only existing in PHP5. However, it gives difficulties, if trying to compare the results or want to output the results float-values to either JavaScript or Database. And especially when trying to create scripts that should work on both PHP-versions (4.x+5.x). Reproduce code: --- ?php $test_value = 1.50; setlocale(LC_ALL, 'da_DK.iso-8859-1', 'da_DK', 'danish', 'da'); echo 'DK: ' . var_export($test_value, TRUE) . \n; setlocale(LC_ALL, 'en'); echo 'EN: ' . var_export($test_value, TRUE) . \n; echo \n . PHP_VERSION; ? Expected result: DK: 1.5 EN: 1.5 Actual result: -- DK: 1,5 EN: 1.5 -- Edit this bug report at http://bugs.php.net/?id=41909edit=1
#41770 [Asn-Fbk]: SSL: fatal protocol error due to buffer issues
ID: 41770 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Feedback Bug Type: Streams related Operating System: Linux PHP Version: 5.2.3 Assigned To: iliaa New Comment: I am unable to reproduce the bug with 4 different HTTPS hosts and the provided code. Do you have a particular URL/host that can be used to reproduce the described issue. Previous Comments: [2007-07-02 16:50:24] [EMAIL PROTECTED] iliaa: All you did is make the warning not appear with that commit. You didn't fix the underlying issue with the connection. It still closes the connection and now it will just mysteriously start failing rather then giving a warning about why it's failing. I would revert your commit and not mark this as fixed. [2007-07-02 16:42:17] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2007-06-21 19:35:37] [EMAIL PROTECTED] It's some streams issue, reclassified as such. Too bad we're out of streams developers right now. :) [2007-06-21 19:22:17] [EMAIL PROTECTED] Bug #34668 as well. [2007-06-21 19:21:43] [EMAIL PROTECTED] Description: Essentially this bug is a mash up of #39283, #35758, #41021, #39039 and possibly others. Essentially the code I'm using looks like: $fd = fsockopen(ssl://myhost, myport, $error, $timeout); $data = fread($fd, 8192); But you can create the same error using: - SoapClient to fetch a WSDL file. - file_get_contents() - file() The backend can be an Apache server or a custom app internally that serves SSL encrypted data. It doesn't matter. If the transmitted data is smaller then the $length passed to fread, everything works successfully. I chose 8192 in my example because file(), file_get_contents() and SoapClient all use 8192 internally based on how the work. Now if the actual data being transmitted is 1 for example, you will receive the first block of data fine. Then the next time you call fread(), or in the case of SoapClient, file_get_contents(), file() they will do this internally. You will get: SSL: fatal protocol error printed out and any subsequent action on the file descriptor will result in an OpenSSL error saying the socket has already been shutdown, as per line 116 (current CVS) of ext/openssl/xp_ssl.c Now you can create this situation with 2048 of data as well. Just call fread($fd, 1024); or fread($fd, 2000); and it will trigger. Basically the $length has to be less then your total amount of data and it will occur. A lot of the previous bugs PHP developer mention IIS while users mention Apache. I have not tested IIS. I have only tested Apache and a custom app which serves data over SSL. I have tested the output of Apache with wget and the custom app with openssl s_client and both work properly. -- Edit this bug report at http://bugs.php.net/?id=41770edit=1
#41909 [Csd]: var_export
ID: 41909 Updated by: [EMAIL PROTECTED] Reported By: stingbat at stingbat dot dk Status: Closed Bug Type: Variables related Operating System: Windows PHP Version: 5.2.3 New Comment: 5.2.1 to 5.2.3 only, I didn't file a bug for this, but I will write this one in the NEWS file. Previous Comments: [2007-07-05 20:31:05] stingbat at stingbat dot dk Has it just been fixed? Wasn't able to find any bug related to this issue, but could just see that there was a problem with PHP 5.2.3 (on multiple both Windows 2000 and XP). Seems like it is fixed in the CVS snapshot, as far as I can see. Thanks for the quick reply :) Do you know in how many version of PHP5, the issue has existed? [2007-07-05 17:33:48] [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 I already fixed this I think... please try the snapshot. But are you really on Windows? [2007-07-05 17:11:05] stingbat at stingbat dot dk Description: Seems like there has been a change to the var_export-function, when comparing PHP4 and PHP5, as stated below: PHP4 314 : case IS_DOUBLE: 315 8 : php_printf(%.*G, (int) EG(precision), Z_DVAL_PP(struc)); from: http://gcov.php.net/PHP_4_4/lcov_html/ext/standard/var.c.gcov.php PHP5 407 : case IS_DOUBLE: 408 42 : php_printf(%.*H, (int) EG(precision), Z_DVAL_PP(struc)); from: http://gcov.php.net/PHP_5_2/lcov_html/ext/standard/var.c.gcov.php Of some reason, the output don't give the same. I don't know if it's PHP4 that has always had this problem, or if it's a new problem only existing in PHP5. However, it gives difficulties, if trying to compare the results or want to output the results float-values to either JavaScript or Database. And especially when trying to create scripts that should work on both PHP-versions (4.x+5.x). Reproduce code: --- ?php $test_value = 1.50; setlocale(LC_ALL, 'da_DK.iso-8859-1', 'da_DK', 'danish', 'da'); echo 'DK: ' . var_export($test_value, TRUE) . \n; setlocale(LC_ALL, 'en'); echo 'EN: ' . var_export($test_value, TRUE) . \n; echo \n . PHP_VERSION; ? Expected result: DK: 1.5 EN: 1.5 Actual result: -- DK: 1,5 EN: 1.5 -- Edit this bug report at http://bugs.php.net/?id=41909edit=1
#41909 [Csd]: var_export
ID: 41909 User updated by: stingbat at stingbat dot dk Reported By: stingbat at stingbat dot dk Status: Closed Bug Type: Variables related Operating System: Windows PHP Version: 5.2.3 New Comment: Ah I see, that's okay :) Thanks for the fix anyway. // over and out ;-) Previous Comments: [2007-07-05 20:52:37] [EMAIL PROTECTED] 5.2.1 to 5.2.3 only, I didn't file a bug for this, but I will write this one in the NEWS file. [2007-07-05 20:31:05] stingbat at stingbat dot dk Has it just been fixed? Wasn't able to find any bug related to this issue, but could just see that there was a problem with PHP 5.2.3 (on multiple both Windows 2000 and XP). Seems like it is fixed in the CVS snapshot, as far as I can see. Thanks for the quick reply :) Do you know in how many version of PHP5, the issue has existed? [2007-07-05 17:33:48] [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 I already fixed this I think... please try the snapshot. But are you really on Windows? [2007-07-05 17:11:05] stingbat at stingbat dot dk Description: Seems like there has been a change to the var_export-function, when comparing PHP4 and PHP5, as stated below: PHP4 314 : case IS_DOUBLE: 315 8 : php_printf(%.*G, (int) EG(precision), Z_DVAL_PP(struc)); from: http://gcov.php.net/PHP_4_4/lcov_html/ext/standard/var.c.gcov.php PHP5 407 : case IS_DOUBLE: 408 42 : php_printf(%.*H, (int) EG(precision), Z_DVAL_PP(struc)); from: http://gcov.php.net/PHP_5_2/lcov_html/ext/standard/var.c.gcov.php Of some reason, the output don't give the same. I don't know if it's PHP4 that has always had this problem, or if it's a new problem only existing in PHP5. However, it gives difficulties, if trying to compare the results or want to output the results float-values to either JavaScript or Database. And especially when trying to create scripts that should work on both PHP-versions (4.x+5.x). Reproduce code: --- ?php $test_value = 1.50; setlocale(LC_ALL, 'da_DK.iso-8859-1', 'da_DK', 'danish', 'da'); echo 'DK: ' . var_export($test_value, TRUE) . \n; setlocale(LC_ALL, 'en'); echo 'EN: ' . var_export($test_value, TRUE) . \n; echo \n . PHP_VERSION; ? Expected result: DK: 1.5 EN: 1.5 Actual result: -- DK: 1,5 EN: 1.5 -- Edit this bug report at http://bugs.php.net/?id=41909edit=1
#32300 [Com]: 64bit libraries in */lib and */lib64
ID: 32300 Comment by: public at caffeianted dot org Reported By: axelseaa at amadmax dot com Status: No Feedback Bug Type: Compile Failure Operating System: Fedora Core 3 64 Bit PHP Version: 5.0.3 New Comment: Same problem here. On CentOS 4.5 manually installing Apache 1.3.31 and PHP 4.4.2 and when I try to add --with-ldap, it needs to have --with-ldap=/usr/lib64 specified but then it can't find the ldap.h file which is located in the /usr/lib directory. How can I make this work? Previous Comments: [2007-03-23 17:12:29] rwarner at snaplogic dot org The problem persists. I am having the same problem in 5.2.1 trying to configure on RedHat ES 4 x64_86. It still looks for the LDAP libraries in /usr/lib rather than /usr/lib64 even with the appropriate flag set to configure to tell it to use /usr/lib64 for the libraries. [2005-04-02 07:41:34] darren at cpanel dot net This also happens on RHEL 3. The vendor installs libraries via up2date/rpms to both /usr/lib/ and /usr/lib64/ , however the php configure script (4.3.11) has $i/lib/library.ext hardcoded in, where $i=/usr/ and the library.ext we need to link against was installed by the vendor in /usr/lib64/ . A couple examples are libjpeg and libpng, both put in /usr/lib64/ (needed with the common GD support). [2005-03-25 01:49:09] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to Open. Thank you. [2005-03-18 19:37:22] [EMAIL PROTECTED] *sigh* You can always tell in configure of those mysql and postgresql where they put the libraries.. IMO, you should always do whatever the distribution packages does: In this case: Put the 64bit libs in /lib64 !! [2005-03-16 15:26:22] axelseaa at amadmax dot com Jabber compiles get around this by offering the following configuration option: --with-extra-library-path=/usr/lib:/usr/lib64:/some/other/lib Would something like this be doable? 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/32300 -- Edit this bug report at http://bugs.php.net/?id=32300edit=1
#41906 [Opn-Fbk]: slow local mysql_connect
ID: 41906 Updated by: [EMAIL PROTECTED] Reported By: kkr at mit dot de -Status: Open +Status: Feedback Bug Type: MySQL related Operating System: Windows 2000 PHP Version: 5.2.3 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-07-05 15:56:22] kkr at mit dot de Description: Between 5.2.1 and 5.2.2 the PHP connects much slower to a local mysql5 installation running under apache/windows 2000. It now takes 5 seconds more to a simple connect which at least does work after that time. In the changelog I've seen a new mysql client lib used starting from 5.2.2 upwards, anyone else has these problems too? The 5.2.3 still has the same behavior. A connect is either via TCP or via named pipe/socket possible but slow. Local graphical frontends to the database are as fast as always. MySQL version is the latest released one 5.0.41. Reproduce code: --- the usual mysql_connect() Expected result: I expect a connect time from 200ms and experience 5500ms now. -- Edit this bug report at http://bugs.php.net/?id=41906edit=1
#41899 [Opn-Fbk]: Can't open files with leading relative path of '..' and '..' is not readable
ID: 41899 Updated by: [EMAIL PROTECTED] Reported By: geoffwa at cs dot rmit dot edu dot au -Status: Open +Status: Feedback Bug Type: Streams related Operating System: Solaris 10 PHP Version: 5.2.3 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-07-05 06:34:06] geoffwa at cs dot rmit dot edu dot au Description: (possibly related to bug #39953 or bug #39351) If a relative path to a file has '..' as a leading path component, and the directory referred to by '..' is not readable by the user, then opening a file using the relative path fails. Using an absolute path or a path with a non-'..' leading component opens said file just fine. Reproduce code: --- See http://goanna.cs.rmit.edu.au/~geoffwa/relative_path_bug.php for a large test script. Expected result: (Using PHP 5.1.4) Current working directory is: /home/g/geoffwa/test Opened /home/g/geoffwa/test/a/b/file Opened ./a/b/file from ./a using ./b/file Opened ./a/b/file from ./a using ./b/c/../file Opened ./a/b/file from ./a/b/c using ../file Opened ../file from ./a/b/c using ./../file Opened ./a/b/file from ./a/b using ./file Opened ./a/file from ./a/b using ./c/../../file Opened ./a/b/c/file from ./a/b/c using ../c/file Actual result: -- (Using PHP 5.2.3 + suhosin patch) Opened /home/g/geoffwa/test/a/b/file Opened ./a/b/file from ./a using ./b/file Opened ./a/b/file from ./a using ./b/c/../file Failed to open ./a/b/file from ./a/b/c using ../file Failed to open ./a/b/file from ./a/b/c using ./../file Opened ./a/b/file from ./a/b using ./file Opened ./a/file from ./a/b using ./c/../../file Failed to open ./a/b/c/file from ./a/b/c using ../c/file -- Edit this bug report at http://bugs.php.net/?id=41899edit=1
#41899 [Fbk-Opn]: Can't open files with leading relative path of '..' and '..' is not readable
ID: 41899 User updated by: geoffwa at cs dot rmit dot edu dot au Reported By: geoffwa at cs dot rmit dot edu dot au -Status: Feedback +Status: Open Bug Type: Streams related Operating System: Solaris 10 PHP Version: 5.2.3 New Comment: Is also broken in 5.2.0 and 5.2.2. Appears to be fixed in latest snapshot: ./php-5.2-200707060030 -v PHP 5.2.4-dev (cli) (built: Jul 6 2007 10:59:53) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies ./php-5.2-200707060030 -f test.php Current working directory is: /home/g/geoffwa/test Opened /home/g/geoffwa/test/a/b/file Opened ./a/b/file from ./a using ./b/file Opened ./a/b/file from ./a using ./b/c/../file Opened ./a/b/file from ./a/b/c using ../file Opened ../file from ./a/b/c using ./../file Opened ./a/b/file from ./a/b using ./file Opened ./a/file from ./a/b using ./c/../../file Opened ./a/b/c/file from ./a/b/c using ../c/file Previous Comments: [2007-07-05 21:59:45] [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 [2007-07-05 06:34:06] geoffwa at cs dot rmit dot edu dot au Description: (possibly related to bug #39953 or bug #39351) If a relative path to a file has '..' as a leading path component, and the directory referred to by '..' is not readable by the user, then opening a file using the relative path fails. Using an absolute path or a path with a non-'..' leading component opens said file just fine. Reproduce code: --- See http://goanna.cs.rmit.edu.au/~geoffwa/relative_path_bug.php for a large test script. Expected result: (Using PHP 5.1.4) Current working directory is: /home/g/geoffwa/test Opened /home/g/geoffwa/test/a/b/file Opened ./a/b/file from ./a using ./b/file Opened ./a/b/file from ./a using ./b/c/../file Opened ./a/b/file from ./a/b/c using ../file Opened ../file from ./a/b/c using ./../file Opened ./a/b/file from ./a/b using ./file Opened ./a/file from ./a/b using ./c/../../file Opened ./a/b/c/file from ./a/b/c using ../c/file Actual result: -- (Using PHP 5.2.3 + suhosin patch) Opened /home/g/geoffwa/test/a/b/file Opened ./a/b/file from ./a using ./b/file Opened ./a/b/file from ./a using ./b/c/../file Failed to open ./a/b/file from ./a/b/c using ../file Failed to open ./a/b/file from ./a/b/c using ./../file Opened ./a/b/file from ./a/b using ./file Opened ./a/file from ./a/b using ./c/../../file Failed to open ./a/b/c/file from ./a/b/c using ../c/file -- Edit this bug report at http://bugs.php.net/?id=41899edit=1
#41910 [NEW]: mysql_error doesn't return a string, just dumps output to screen
From: dan at novapulsar dot com
Operating system: centos4.3
PHP version: 4.4.7
PHP Bug Type: MySQL related
Bug description: mysql_error doesn't return a string, just dumps output to
screen
Description:
Since mysql_error() is documented to 'return' a string, I assumed it would
be safe to put it in either a string, or as an argument to an error
handling function.
Reproduce code:
---
function fn_Save_Error ($x_page_url, $x_error) {
if (strlen($x_page_url) strlen($x_error)) {
//output if debugging is on
echo (Error on page: . $x_page_url . - . $x_error);
//save to db
}
}
$strSQL = select all from something will make an error duh;
$objResult = mysql_query ($strSQL) or die (fn_Save_Error('this.php',
mysql_error());
Expected result:
Expected result is that the string value of mysql_error() is passed as an
argument of datatype string whether blank or with contents to the
fn_Save_Error function.
Actual result:
--
Mysql_error() is output directly to the screen/console, instead of being
passed as a value to fn_Save_Error for custom error handling.
Based on the mysql_error() documentation it should not output the error to
screen, it should return it as a string, so that I could do this:
...some wrong query execution...
$error_message = mysql_error(); echo ($error_message);
$error_message should be == to $mysql_error, but instead it just outputs
to screen/console
--
Edit bug report at http://bugs.php.net/?id=41910edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41910r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41910r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41910r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41910r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41910r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41910r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41910r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41910r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41910r=support
Expected behavior:http://bugs.php.net/fix.php?id=41910r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41910r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41910r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41910r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41910r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41910r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41910r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41910r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41910r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41910r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41910r=mysqlcfg
