#34997 [WFx]: nodeValue is set when should be null
ID: 34997 User updated by: php dot net at punk dot co dot nz Reported By: php dot net at punk dot co dot nz Status: Wont fix Bug Type: DOM XML related Operating System: Windows XP PHP Version: 5.0.5 New Comment: Does this impact memory usage and performance on large documents? As it appears to duplicate a lot of data. >From what I can tell this is not an extension, more a violation of the spec. The spec indicates it should be null, not undefined and open to interpretation. IMHO it should be changed to reflect the spec and set to null, or if some people do use it, then maybe made an optional setting? And, if doing that, it might be more useful if it didn't concat all the descendant text nodes into the parent, but just contained only the content from any attached text/CDATA nodes. (Actually then I'd find it useful.) /2c Previous Comments: [2005-10-27 01:10:44] [EMAIL PROTECTED] This was done intentionally and as an extension to the DOM specs. Provides quick access to Element content and is read-only for DOMElement. This is the only node type that this exception was made for. [2005-10-27 00:39:22] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-10-27 00:37:58] php dot net at punk dot co dot nz Description: The nodeValue attribute appears to be set to the concatenation of the contents of all child text nodes. As far as I understand according to the specification (p36, DOM2-Core.pdf, w3.org) the nodeValue should be set to NULL for Element node types (and many other node types). This may be a problem for other node types as well. Reproduce code: --- http://www.punk.co.nz/php.net/nodeValue-test.zip Includes a sample xml file and output.txt. -- Edit this bug report at http://bugs.php.net/?id=34997&edit=1
#34796 [Csd]: ftp module compiled with openssl extension enabled must be loaded after ssl lib
ID: 34796 Updated by: [EMAIL PROTECTED] Reported By: glen at delfi dot ee Status: Closed Bug Type: Compile Failure Operating System: PLD Linux PHP Version: 5.1.0RC1 New Comment: Any problem with my committing this patch so that building via phpize works? Seems like there should better or more standard way to do this, but I couldn't find any. Index: config.m4 === RCS file: /repository/php-src/ext/ftp/config.m4,v retrieving revision 1.7.20.2 diff -u -p -r1.7.20.2 config.m4 --- config.m4 9 Oct 2005 20:44:02 - 1.7.20.2 +++ config.m4 28 Oct 2005 00:32:09 - @@ -12,6 +12,9 @@ if test "$PHP_FTP" = "yes"; then AC_DEFINE(HAVE_FTP,1,[Whether you want FTP support]) PHP_NEW_EXTENSION(ftp, php_ftp.c ftp.c, $ext_shared) + dnl Empty variable means 'no' + test -z "$PHP_OPENSSL" && PHP_OPENSSL=no + if test "$PHP_OPENSSL" != "no" || test "$PHP_OPENSSL_DIR" != "no"; then PHP_SETUP_OPENSSL(FTP_SHARED_LIBADD) PHP_SUBST(FTP_SHARED_LIBADD) Previous Comments: [2005-10-10 07:50:43] [EMAIL PROTECTED] Thanks but I already committed something similar as your first patch was obviously half-way there. [2005-10-10 00:10:22] glen at delfi dot ee i updated the patch so it will work also with: --disable-openssl --enable-ftp=shared my test compile and run worked ok. get the patch from same URL. [2005-10-09 22:40:05] [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. Fix will be in PHP 5.1 and above. [2005-10-09 22:01:49] glen at delfi dot ee Description: if you configure your php with: --with-openssl=shared --enable-ftp=shared then ftp module is compiled with openssl related functions, but not linked, this causes ftp module loaded earlier in php.ini outputing missing SSL_ symbols $ php -m PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/ftp.so' - /usr/lib/php/ftp.so: undefined symbol: SSL_shutdown in Unknown on line 0 here's patch to fix it. http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/php-ftp-ssllibs.patch NB: applying this patch and compiling --without-openssl is not tested. otherwise it fixes the bug described earlier. -- Edit this bug report at http://bugs.php.net/?id=34796&edit=1
#35005 [Opn]: Opening a lot of files result in no network connectivity
ID: 35005
User updated by: daniel at polkabrothers dot com
Reported By: daniel at polkabrothers dot com
Status: Open
Bug Type: Network related
Operating System: Mac OS X 10.4.2
PHP Version: 5.0.5
New Comment:
I should probably add that I've tried running this both as
root (su root; ulimit -n 5000) and using sudo (sudo php ...).
Same result.
Previous Comments:
[2005-10-27 23:06:30] daniel at polkabrothers dot com
I used ulimit -n to increase the number of allowed open
files, otherwise it wouldn't even allow me to create 3000
files.
Now ulimit -a gives me:
core file size(blocks, -c) 0
data seg size (kbytes, -d) 6144
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files(-n) 10240
pipe size (512 bytes, -p) 1
stack size(kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes(-u) 100
virtual memory(kbytes, -v) unlimited
Can't find anything else which relates to file descriptors
and Mac OS X.
[2005-10-27 22:56:55] [EMAIL PROTECTED]
Looks like MacOSX has max number of file descriptors set to 1024 or
something like that.
I don't have MacOSX around here, but I guess this fact should be
documented somewhere @ apple.com.
Could you check it?
[2005-10-27 22:50:34] daniel at polkabrothers dot com
Have now done a bit more testing, and it only happens if you
try to open more than 1017 files and then try to open a url.
Have tried opening urls with fopen(), curl_* and exec
("wget"). Same end-result, they don't connect.
PHP doesn't generate any error messages when trying to open
using fopen(). When trying it with the curl functions, curl
returns with "couldn't connect" but if you turn on more
debugging it comes back with "Unknown error: 0". When trying
to exec() wget it stops as soon as it gets a connection and
is about to output "200 OK"
(i have read the how to report bugs, but can't find what i'm
missing to include)
[2005-10-27 22:42:02] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
[2005-10-27 22:31:53] daniel at polkabrothers dot com
Description:
When opening a lot (3000 in this case) files under Mac OS X,
network connectivity disappears.
This has been tested under Linux 2.6, and works fine.
Reproduce code:
---
$fp = array();
for($x=0;$x<3000;$x++) {
$fp[$x] = fopen("/tmp/$x", "w");
}
$url_fp = fopen("http://www.google.com";, "r");
var_dump(fread($url_fp, 1500));
Expected result:
To get the first 1500 bytes from www.google.com
Actual result:
--
string(0) ""
--
Edit this bug report at http://bugs.php.net/?id=35005&edit=1
#35005 [Fbk->Opn]: Opening a lot of files result in no network connectivity
ID: 35005
User updated by: daniel at polkabrothers dot com
Reported By: daniel at polkabrothers dot com
-Status: Feedback
+Status: Open
Bug Type: Network related
Operating System: Mac OS X 10.4.2
PHP Version: 5.0.5
New Comment:
I used ulimit -n to increase the number of allowed open
files, otherwise it wouldn't even allow me to create 3000
files.
Now ulimit -a gives me:
core file size(blocks, -c) 0
data seg size (kbytes, -d) 6144
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files(-n) 10240
pipe size (512 bytes, -p) 1
stack size(kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes(-u) 100
virtual memory(kbytes, -v) unlimited
Can't find anything else which relates to file descriptors
and Mac OS X.
Previous Comments:
[2005-10-27 22:56:55] [EMAIL PROTECTED]
Looks like MacOSX has max number of file descriptors set to 1024 or
something like that.
I don't have MacOSX around here, but I guess this fact should be
documented somewhere @ apple.com.
Could you check it?
[2005-10-27 22:50:34] daniel at polkabrothers dot com
Have now done a bit more testing, and it only happens if you
try to open more than 1017 files and then try to open a url.
Have tried opening urls with fopen(), curl_* and exec
("wget"). Same end-result, they don't connect.
PHP doesn't generate any error messages when trying to open
using fopen(). When trying it with the curl functions, curl
returns with "couldn't connect" but if you turn on more
debugging it comes back with "Unknown error: 0". When trying
to exec() wget it stops as soon as it gets a connection and
is about to output "200 OK"
(i have read the how to report bugs, but can't find what i'm
missing to include)
[2005-10-27 22:42:02] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
[2005-10-27 22:31:53] daniel at polkabrothers dot com
Description:
When opening a lot (3000 in this case) files under Mac OS X,
network connectivity disappears.
This has been tested under Linux 2.6, and works fine.
Reproduce code:
---
$fp = array();
for($x=0;$x<3000;$x++) {
$fp[$x] = fopen("/tmp/$x", "w");
}
$url_fp = fopen("http://www.google.com";, "r");
var_dump(fread($url_fp, 1500));
Expected result:
To get the first 1500 bytes from www.google.com
Actual result:
--
string(0) ""
--
Edit this bug report at http://bugs.php.net/?id=35005&edit=1
#35005 [Opn->Fbk]: Opening a lot of files result in no network connectivity
ID: 35005
Updated by: [EMAIL PROTECTED]
Reported By: daniel at polkabrothers dot com
-Status: Open
+Status: Feedback
Bug Type: Network related
Operating System: Mac OS X 10.4.2
PHP Version: 5.0.5
New Comment:
Looks like MacOSX has max number of file descriptors set to 1024 or
something like that.
I don't have MacOSX around here, but I guess this fact should be
documented somewhere @ apple.com.
Could you check it?
Previous Comments:
[2005-10-27 22:50:34] daniel at polkabrothers dot com
Have now done a bit more testing, and it only happens if you
try to open more than 1017 files and then try to open a url.
Have tried opening urls with fopen(), curl_* and exec
("wget"). Same end-result, they don't connect.
PHP doesn't generate any error messages when trying to open
using fopen(). When trying it with the curl functions, curl
returns with "couldn't connect" but if you turn on more
debugging it comes back with "Unknown error: 0". When trying
to exec() wget it stops as soon as it gets a connection and
is about to output "200 OK"
(i have read the how to report bugs, but can't find what i'm
missing to include)
[2005-10-27 22:42:02] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
[2005-10-27 22:31:53] daniel at polkabrothers dot com
Description:
When opening a lot (3000 in this case) files under Mac OS X,
network connectivity disappears.
This has been tested under Linux 2.6, and works fine.
Reproduce code:
---
$fp = array();
for($x=0;$x<3000;$x++) {
$fp[$x] = fopen("/tmp/$x", "w");
}
$url_fp = fopen("http://www.google.com";, "r");
var_dump(fread($url_fp, 1500));
Expected result:
To get the first 1500 bytes from www.google.com
Actual result:
--
string(0) ""
--
Edit this bug report at http://bugs.php.net/?id=35005&edit=1
#35005 [Fbk->Opn]: Opening a lot of files result in no network connectivity
ID: 35005
User updated by: daniel at polkabrothers dot com
Reported By: daniel at polkabrothers dot com
-Status: Feedback
+Status: Open
Bug Type: Network related
Operating System: Mac OS X 10.4.2
PHP Version: 5.0.5
New Comment:
Have now done a bit more testing, and it only happens if you
try to open more than 1017 files and then try to open a url.
Have tried opening urls with fopen(), curl_* and exec
("wget"). Same end-result, they don't connect.
PHP doesn't generate any error messages when trying to open
using fopen(). When trying it with the curl functions, curl
returns with "couldn't connect" but if you turn on more
debugging it comes back with "Unknown error: 0". When trying
to exec() wget it stops as soon as it gets a connection and
is about to output "200 OK"
(i have read the how to report bugs, but can't find what i'm
missing to include)
Previous Comments:
[2005-10-27 22:42:02] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
[2005-10-27 22:31:53] daniel at polkabrothers dot com
Description:
When opening a lot (3000 in this case) files under Mac OS X,
network connectivity disappears.
This has been tested under Linux 2.6, and works fine.
Reproduce code:
---
$fp = array();
for($x=0;$x<3000;$x++) {
$fp[$x] = fopen("/tmp/$x", "w");
}
$url_fp = fopen("http://www.google.com";, "r");
var_dump(fread($url_fp, 1500));
Expected result:
To get the first 1500 bytes from www.google.com
Actual result:
--
string(0) ""
--
Edit this bug report at http://bugs.php.net/?id=35005&edit=1
#35004 [Csd->Bgs]: $_server["AUTH_USER"] is not including seperator between domain and user
ID: 35004
User updated by: jmcentire at jackhenry dot com
Reported By: jmcentire at jackhenry dot com
-Status: Closed
+Status: Bogus
Bug Type: Variables related
Operating System: Windows server 2003
PHP Version: 5.0.5
New Comment:
Changed to "bogus"
Previous Comments:
[2005-10-27 22:43:00] jmcentire at jackhenry dot com
Sorry - this appears to be a problem only under MediaWiki. When ran in
a test.php by itself:
returns the correct value with the seperator. I'll close this and
pursue this with mediawiki.
[2005-10-27 22:26:46] [EMAIL PROTECTED]
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 ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
[2005-10-27 22:20:48] jmcentire at jackhenry dot com
>> var_dump($_SERVER["AUTH_USER"]);
prints
string(13) "DDuuu"
where DD is the 6 character domain name
and uuu is the 7 character user name
No seperator
[2005-10-27 21:44:00] [EMAIL PROTECTED]
what does this code print:
var_dump($_SERVER["AUTH_USER"]);
?
[2005-10-27 21:40:39] jmcentire at jackhenry dot com
Description:
php_info() shows server variable AUTH_USER in correct format:
DOMAIN\username
However, the $_server["AUTH_USER"] in code returns "DOMAINusername" (no
seperator).
Reproduce code:
---
list($domain,$username) = split('[\]',$_SERVER["AUTH_USER"],2);
print "Domain: $domain UserName: $username";
Expected result:
Domain: DOMAIN UserName: username
Actual result:
--
Domain: DOMAINusername UserName:
--
Edit this bug report at http://bugs.php.net/?id=35004&edit=1
#35004 [Fbk->Csd]: $_server["AUTH_USER"] is not including seperator between domain and user
ID: 35004
User updated by: jmcentire at jackhenry dot com
Reported By: jmcentire at jackhenry dot com
-Status: Feedback
+Status: Closed
Bug Type: Variables related
Operating System: Windows server 2003
PHP Version: 5.0.5
New Comment:
Sorry - this appears to be a problem only under MediaWiki. When ran in
a test.php by itself:
returns the correct value with the seperator. I'll close this and
pursue this with mediawiki.
Previous Comments:
[2005-10-27 22:26:46] [EMAIL PROTECTED]
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 ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
[2005-10-27 22:20:48] jmcentire at jackhenry dot com
>> var_dump($_SERVER["AUTH_USER"]);
prints
string(13) "DDuuu"
where DD is the 6 character domain name
and uuu is the 7 character user name
No seperator
[2005-10-27 21:44:00] [EMAIL PROTECTED]
what does this code print:
var_dump($_SERVER["AUTH_USER"]);
?
[2005-10-27 21:40:39] jmcentire at jackhenry dot com
Description:
php_info() shows server variable AUTH_USER in correct format:
DOMAIN\username
However, the $_server["AUTH_USER"] in code returns "DOMAINusername" (no
seperator).
Reproduce code:
---
list($domain,$username) = split('[\]',$_SERVER["AUTH_USER"],2);
print "Domain: $domain UserName: $username";
Expected result:
Domain: DOMAIN UserName: username
Actual result:
--
Domain: DOMAINusername UserName:
--
Edit this bug report at http://bugs.php.net/?id=35004&edit=1
#35005 [Opn->Fbk]: Opening a lot of files result in no network connectivity
ID: 35005
Updated by: [EMAIL PROTECTED]
Reported By: daniel at polkabrothers dot com
-Status: Open
+Status: Feedback
Bug Type: Network related
Operating System: Mac OS X 10.4.2
PHP Version: 5.0.5
New Comment:
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
Previous Comments:
[2005-10-27 22:31:53] daniel at polkabrothers dot com
Description:
When opening a lot (3000 in this case) files under Mac OS X,
network connectivity disappears.
This has been tested under Linux 2.6, and works fine.
Reproduce code:
---
$fp = array();
for($x=0;$x<3000;$x++) {
$fp[$x] = fopen("/tmp/$x", "w");
}
$url_fp = fopen("http://www.google.com";, "r");
var_dump(fread($url_fp, 1500));
Expected result:
To get the first 1500 bytes from www.google.com
Actual result:
--
string(0) ""
--
Edit this bug report at http://bugs.php.net/?id=35005&edit=1
#35005 [NEW]: Opening a lot of files result in no network connectivity
From: daniel at polkabrothers dot com
Operating system: Mac OS X 10.4.2
PHP version: 5.0.5
PHP Bug Type: Network related
Bug description: Opening a lot of files result in no network connectivity
Description:
When opening a lot (3000 in this case) files under Mac OS X,
network connectivity disappears.
This has been tested under Linux 2.6, and works fine.
Reproduce code:
---
$fp = array();
for($x=0;$x<3000;$x++) {
$fp[$x] = fopen("/tmp/$x", "w");
}
$url_fp = fopen("http://www.google.com";, "r");
var_dump(fread($url_fp, 1500));
Expected result:
To get the first 1500 bytes from www.google.com
Actual result:
--
string(0) ""
--
Edit bug report at http://bugs.php.net/?id=35005&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=35005&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=35005&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=35005&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=35005&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=35005&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=35005&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=35005&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=35005&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=35005&r=support
Expected behavior: http://bugs.php.net/fix.php?id=35005&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=35005&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=35005&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=35005&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35005&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=35005&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=35005&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=35005&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=35005&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=35005&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=35005&r=mysqlcfg
#35004 [Opn->Fbk]: $_server["AUTH_USER"] is not including seperator between domain and user
ID: 35004
Updated by: [EMAIL PROTECTED]
Reported By: jmcentire at jackhenry dot com
-Status: Open
+Status: Feedback
Bug Type: Variables related
Operating System: Windows server 2003
PHP Version: 5.0.5
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 ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
Previous Comments:
[2005-10-27 22:20:48] jmcentire at jackhenry dot com
>> var_dump($_SERVER["AUTH_USER"]);
prints
string(13) "DDuuu"
where DD is the 6 character domain name
and uuu is the 7 character user name
No seperator
[2005-10-27 21:44:00] [EMAIL PROTECTED]
what does this code print:
var_dump($_SERVER["AUTH_USER"]);
?
[2005-10-27 21:40:39] jmcentire at jackhenry dot com
Description:
php_info() shows server variable AUTH_USER in correct format:
DOMAIN\username
However, the $_server["AUTH_USER"] in code returns "DOMAINusername" (no
seperator).
Reproduce code:
---
list($domain,$username) = split('[\]',$_SERVER["AUTH_USER"],2);
print "Domain: $domain UserName: $username";
Expected result:
Domain: DOMAIN UserName: username
Actual result:
--
Domain: DOMAINusername UserName:
--
Edit this bug report at http://bugs.php.net/?id=35004&edit=1
#35004 [Fbk->Opn]: $_server["AUTH_USER"] is not including seperator between domain and user
ID: 35004
User updated by: jmcentire at jackhenry dot com
Reported By: jmcentire at jackhenry dot com
-Status: Feedback
+Status: Open
Bug Type: Variables related
Operating System: Windows server 2003
PHP Version: 5.0.5
New Comment:
>> var_dump($_SERVER["AUTH_USER"]);
prints
string(13) "DDuuu"
where DD is the 6 character domain name
and uuu is the 7 character user name
No seperator
Previous Comments:
[2005-10-27 21:44:00] [EMAIL PROTECTED]
what does this code print:
var_dump($_SERVER["AUTH_USER"]);
?
[2005-10-27 21:40:39] jmcentire at jackhenry dot com
Description:
php_info() shows server variable AUTH_USER in correct format:
DOMAIN\username
However, the $_server["AUTH_USER"] in code returns "DOMAINusername" (no
seperator).
Reproduce code:
---
list($domain,$username) = split('[\]',$_SERVER["AUTH_USER"],2);
print "Domain: $domain UserName: $username";
Expected result:
Domain: DOMAIN UserName: username
Actual result:
--
Domain: DOMAINusername UserName:
--
Edit this bug report at http://bugs.php.net/?id=35004&edit=1
#35004 [Opn->Fbk]: $_server["AUTH_USER"] is not including seperator between domain and user
ID: 35004
Updated by: [EMAIL PROTECTED]
Reported By: jmcentire at jackhenry dot com
-Status: Open
+Status: Feedback
Bug Type: Variables related
Operating System: Windows server 2003
PHP Version: 5.0.5
New Comment:
what does this code print:
var_dump($_SERVER["AUTH_USER"]);
?
Previous Comments:
[2005-10-27 21:40:39] jmcentire at jackhenry dot com
Description:
php_info() shows server variable AUTH_USER in correct format:
DOMAIN\username
However, the $_server["AUTH_USER"] in code returns "DOMAINusername" (no
seperator).
Reproduce code:
---
list($domain,$username) = split('[\]',$_SERVER["AUTH_USER"],2);
print "Domain: $domain UserName: $username";
Expected result:
Domain: DOMAIN UserName: username
Actual result:
--
Domain: DOMAINusername UserName:
--
Edit this bug report at http://bugs.php.net/?id=35004&edit=1
#35004 [NEW]: $_server["AUTH_USER"] is not including seperator between domain and user
From: jmcentire at jackhenry dot com
Operating system: Windows server 2003
PHP version: 5.0.5
PHP Bug Type: Variables related
Bug description: $_server["AUTH_USER"] is not including seperator between
domain and user
Description:
php_info() shows server variable AUTH_USER in correct format:
DOMAIN\username
However, the $_server["AUTH_USER"] in code returns "DOMAINusername" (no
seperator).
Reproduce code:
---
list($domain,$username) = split('[\]',$_SERVER["AUTH_USER"],2);
print "Domain: $domain UserName: $username";
Expected result:
Domain: DOMAIN UserName: username
Actual result:
--
Domain: DOMAINusername UserName:
--
Edit bug report at http://bugs.php.net/?id=35004&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=35004&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=35004&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=35004&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=35004&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=35004&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=35004&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=35004&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=35004&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=35004&r=support
Expected behavior: http://bugs.php.net/fix.php?id=35004&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=35004&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=35004&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=35004&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35004&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=35004&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=35004&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=35004&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=35004&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=35004&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=35004&r=mysqlcfg
#34939 [Com]: Undefined reference make failed
ID: 34939 Comment by: chris at spawnordie dot com Reported By: marcel dot bariou at brasnah dot com Status: Assigned Bug Type: PDO related Operating System: LINUX RH ES3 PHP Version: 5.1.0RC3 Assigned To: wez New Comment: I got the same result. Tring to compile with PDO support for mysql 5.0.15 and the 200510271830 PHP snapshot. Compiles fine without PDO for MySQL or for PDO for MySQL 4. It hink this is related to MySQL 5. Here are the configure options: ./configure \ --with-mysql=/usr/local/mysql5 \ --with-pgsql=/usr/local/pgsql \ --with-apxs2=/usr/local/apache2/bin/apxs \ --with-gd \ --with-imap-ssl \ --enable-track-vars \ --enable-url-includes \ --with-ttf \ --enable-magic-quotes \ --with-pcre-regex \ --enable-ftp \ --with-mcrypt \ --enable-freetype-4bit-antialias-hack \ --with-curl \ --with-zlib-dir=/usr \ --with-kerberos \ --with-gettext \ --with-jpeg-dir=/usr \ --with-png-dir=/usr \ --with-zlib \ --enable-gd-native-ttf \ --with-freetype-dir=/usr/include/freetype2 \ --with-dom \ --enable-sockets \ --enable-wddx \ --with-xmlrpc \ --with-xsl \ --enable-xslt \ --with-xslt-sablot=/usr/local \ --with-expat-dir \ --with-pdo-mysql=/usr/local/mysql5 \ --with-pdo-pgsql=/usr/local/pgsql \ --enable-soap \ --with-xmlreader Here are the last few lines of output from make: sapi_krb5 -lkrb5 -lk5crypto -lkrb5support -lcom_err -lresolv -lidn -lssl -lcrypto -lz -lxml2 -lz -lm -lxml2 -lz -lm -lxml2 -lz -lm -lcrypt -lxml2 -lz -lm -lxml2 -lz -lm -lxml2 -lz -lm -lxslt -lxml2 -lz -lm -lcrypt -o sapi/cli/php ext/pdo_mysql/.libs/mysql_driver.o(.text+0xd2f): In function `pdo_mysql_handle_factory': /usr/local/src/php5-200510271830/ext/pdo_mysql/mysql_driver.c:438: undefined reference to `pdo_attr_strval' ext/pdo_mysql/.libs/mysql_driver.o(.text+0xdab):/usr/local/src/php5-200510271830/ext/pdo_mysql/mysql_driver.c:448: undefined reference to `pdo_attr_strval' ext/pdo_mysql/.libs/mysql_driver.o(.text+0xde2):/usr/local/src/php5-200510271830/ext/pdo_mysql/mysql_driver.c:458: undefined reference to `pdo_attr_strval' collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 1 Previous Comments: [2005-10-21 17:44:29] marcel dot bariou at brasnah dot com Yes, I add enable-pdo=shared (last line of ./configure as you can see..) [2005-10-21 16:51:45] [EMAIL PROTECTED] Did you --enable-pdo ? [2005-10-21 14:16:01] [EMAIL PROTECTED] Wez, take a look at it please. [2005-10-21 06:20:54] marcel dot bariou at brasnah dot com Description: I start with this configure directive : ./configure --prefix=/etc/httpd --with-apxs2=/usr/sbin/apxs --with-config-file-path=/etc/httpd/conf --with-mysql=/usr/local/mysql --enable-bc-math --enable-calendar --with-curl=/usr --enable-exif --with-gettext --with-gmp --enable-id3 --with-java=/usr/local/java=/usr/local/j2sdk --with-mcrypt=/usr/local --with-mhash=/usr/local --enable-overload --enable-pcntl --with-regex=PHP --enable-soap --enable-sockets --with-tidy=/usr/local --enable-wddx --with-xsl=/usr/local --enable-xslt --with-xslt-sablot --with-expat-dir=/usr --enable-php-streams --enable-memory-limit --enable-cli --enable-posix --enable-pcre --enable-sysvmsg --enable-sysvsem --enable-sysvshm --enable-shmop --with-pear --with-xmlrpc --with-zlib=/usr --with-iconv --with-iconv-dir=/usr/local --with-pdo-mysql=/usr/local/mysql --enable-pdo=shared Make message => : ext/pdo_mysql/.libs/pdo_mysql.o(.text+0x13): In function `zm_startup_pdo_mysql': /usr/local/xtra_targz/php5-200510202030/ext/pdo_mysql/pdo_mysql.c:78: undefined reference to `php_pdo_declare_long_constant' ext/pdo_mysql/.libs/pdo_mysql.o(.text+0x34): In function `zm_shutdown_pdo_mysql': /usr/local/xtra_targz/php5-200510202030/ext/pdo_mysql/pdo_mysql.c:88: undefined reference to `php_pdo_unregister_driver' ext/pdo_mysql/.libs/pdo_mysql.o(.text+0x23): In function `zm_startup_pdo_mysql': /usr/local/xtra_targz/php5-200510202030/ext/pdo_mysql/pdo_mysql.c:80: undefined reference to `php_pdo_register_driver' ext/pdo_mysql/.libs/mysql_driver.o(.text+0x197): In function `_pdo_mysql_error': /usr/local/xtra_targz/php5-200510202030/ext/pdo_mysql/mysql_driver.c:100: undefined reference to `php_pdo_get_exception' ext/pdo_mysql/.libs/mysql_driver.o(.text+0x378): In function `mysql_handle_preparer': /usr/local/xtra_targz/php5-200510202030/ext/pdo_mysql/mysql_driver.c:169: undefined reference to `pdo_parse_params' ext/pdo_mysql/.libs/mysql_driver.o(.text+0x57a): In function `pdo_mysql_last_insert_id': /usr/local/xtra_targz/php5-200510202030/ext/pdo_mysql/mysql_driver.c:250: undefined reference to `php_pdo_int64_to_str' ext/pdo_mysql/.libs/mysql_driver.o(.text+0x84e): In func
#34927 [Asn->Bgs]: WebSphere IBM server HTTPS CURL connection failure
ID: 34927
Updated by: [EMAIL PROTECTED]
Reported By: fjsignes at computerxabia dot com
-Status: Assigned
+Status: Bogus
Bug Type: cURL related
Operating System: Windows
PHP Version: 4.4.0
Assigned To: mike
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.
Please make sure that the server is properly configured.
Apache Jakarta suggest to use the following Test class to verify a SSL
enabled server is properly configured:
http://dev.iworks.at/PATCHES/Test.java.txt
Thanks.
Previous Comments:
[2005-10-25 17:21:58] [EMAIL PROTECTED]
Going to be fixed in 4.4.2
[2005-10-20 17:16:06] [EMAIL PROTECTED]
Probably related to bug #33760
I reproduced with 5.1-CVS, and had no problems with pecl/http which has
implemented the SSL crypto lock callbacks.
[2005-10-20 10:52:10] fjsignes at computerxabia dot com
Description:
When i try the following by command line:
curl.exe -k https://websphereserver:9084/SOAP
(command line curl version:
curl 7.14.0 (i586-pc-mingw32msvc) libcurl/7.14.0
OpenSSL/0.9.8 zlib/1.2.2
Protocols: ftp gopher telnet dict ldap http file https ftps
Features: Largefile NTLM SSL SSPI libz)
I can connect to the server.
In a PHP script executing then comand "exec" like this:
https://websphereserver:9084/SOAP";;
$data="something";
exec("$curl -k --verbose -d \"$data\" $_url", $result);
print_r($result);
?>
I can connect to the server too.
But when i try to use libcurl library as in the reproduce code
section, i can't establish the connection.
PHP versions ckecked:
-- PHP-5.0.5Win32 with libcurl/7.14.0 OpenSSL/0.9.8 zlib/1.2.3- or
-- PHP-4.4.0Win32 with libcurl/7.11.2 OpenSSL/0.9.8 zlib/1.1.4 -
or
-- PHP-5.1.0RC1-Win32 with libcurl/7.14.0 OpenSSL/0.9.8
zlib/1.2.3-
-- php4-win32-STABLE-200510200430 with libcurl/7.14.0
OpenSSL/0.9.8 zlib/1.2.3
In all of them shows me the same error.
(I just verified that i am using the DLLs shipped with the PHP-
in each case with Filemon Software)
Reproduce code:
---
$_url = 'https://websphereserver:9084/SOAP';
$ch = curl_init();
curl_setopt($ch,CURLOPT_SSLVERSION,3);
curl_setopt($ch, CURLOPT_URL,$_url);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE);
curl_setopt($ch, CURLOPT_USERAGENT,
$defined_vars['HTTP_USER_AGENT']);
curl_setopt($ch, CURLOPT_RETURNTRANSFER,1);
$result=curl_exec ($ch);
$cErr = curl_error($ch);
if ($cErr != '') {
$err = 'cURL ERROR: '.curl_errno($ch).': '.$cErr.'';
foreach(curl_getinfo($ch) as $k => $v){
$err .= "$k: $v";
}
echo("Error $err");
curl_close($ch);
return false;
}
curl_close ($ch);
echo("Output: ".$result);
Expected result:
Establish connection with the server as in the command line:
curl.exe -k https://websphereserver:9084/SOAP or
curl.exe -3 -k https://websphereserver:9084/SOAP
Actual result:
--
Without forcing any SSLVersion:
(without writing:curl_setopt($ch,CURLOPT_SSLVERSION,3);
in the php code)
Error cURL ERROR: 35: error:140770FC:SSL
routines:SSL23_GET_SERVER_HELLO:unknown protocol
Forcing SSLv3:
Error cURL ERROR: 35: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong
version number
--
Edit this bug report at http://bugs.php.net/?id=34927&edit=1
#34515 [Com]: mysqli_fetch_assoc crashes application
ID: 34515
Comment by: mark at tranchant dot plus dot com
Reported By: jaba at inbox dot lv
Status: Feedback
Bug Type: MySQLi related
Operating System: Debian GNU/Linux
PHP Version: 5.0.5
New Comment:
Upgraded from gcc-3.3.2 to gcc-3.4.4, completely recompiled PHP-5.0.5.
No change: bug still there.
Also tried allocating a static buffer (char tmp[64];) and strcpy'ing
fields[i].name to it, then using that in the add_assoc calls. No joy
there, either.
Previous Comments:
[2005-10-27 16:10:31] mark at tranchant dot plus dot com
Gah. I think I've got as far as my abilities allow.
Basically, if either add_assoc_zval or add_assoc_null are called with
anything other than a static string, crash. Even:
char *tmp;
...
sprintf(tmp, "hello");
add_assoc_zval(return_value, tmp, res);
fails, although:
add_assoc_zval(return_value, "hello", res);
does not, and $array['hello'] returns the first value as expected.
There is no issue with the mysql_fetch_fields() function: the failure
occurs even with that commented out.
I've traced the code path down to _zend_hash_add_or_update(), but I
don't know enough to see any problems on the way there.
***
#define add_assoc_zval(__arg, __key, __value) add_assoc_zval_ex(__arg,
__key, strlen(__key)+1, __value)
***
ZEND_API int add_assoc_zval_ex(zval *arg, char *key, uint key_len, zval
*value)
{
return zend_symtable_update(Z_ARRVAL_P(arg), key, key_len, (void *)
&value, sizeof(zval *), NULL);
}
***
static inline int zend_symtable_update(HashTable *ht, char *arKey, uint
nKeyLength, void *pData, uint nDa
taSize, void **pDest) \
{
HANDLE_NUMERIC(arKey, nKeyLength, zend_hash_index_update(ht, idx,
pData, nDataSize, pDest));
return zend_hash_update(ht, arKey, nKeyLength, pData, nDataSize,
pDest);
}
***
#define zend_hash_update(ht, arKey, nKeyLength, pData, nDataSize,
pDest) \
_zend_hash_add_or_update(ht, arKey, nKeyLength, pData, nDataSize,
pDest, HASH_UPDATE ZEND_FILE_LINE_CC)
***
[2005-10-27 14:22:43] mark at tranchant dot plus dot com
I've just written a quick C program using the MySQL C API and can
confirm that mysql_fetch_fields() works fine. The problem does appear
to be with the PHP code. I'll keep looking.
[2005-10-27 13:09:52] mark at tranchant dot plus dot com
Not easily, no. I'm not set up for external users. If it would really
help, I could try. I've done some more digging:
In ext/mysqli/mysqli.c, there is the following code:
line 653:
if (fetchtype & MYSQLI_ASSOC) {
fields = mysql_fetch_fields(result);
}
line 677:
if (fetchtype & MYSQLI_ASSOC) {
if (fetchtype & MYSQLI_NUM) {
ZVAL_ADDREF(res);
}
add_assoc_zval(return_value, fields[i].name, res);
}
line 687:
if (fetchtype & MYSQLI_ASSOC) {
add_assoc_null(return_value, fields[i].name);
}
If I change the fields[i].name argument to "hello", the offending
functions then work. I successfully used fetch_array with MYSQLI_BOTH,
and $array['hello'] referred to the last element in the fetched array.
It seems as though the call to mysql_fetch_fields (part of the MySQL
API) is failing, which is not being detected by the PHP code. More
soon...
[2005-10-27 12:34:42] [EMAIL PROTECTED]
Is there any chance to get an account on this server?
[2005-10-27 12:29:06] mark at tranchant dot plus dot com
Yeah, I was right. Latest CVS snapshot (php5-STABLE-200510270836) does
not fix the issue.
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/34515
--
Edit this bug report at http://bugs.php.net/?id=34515&edit=1
#34482 [Opn->Asn]: LDAP Searches cause Access Violation when connecting via LDAPS
ID: 34482
Updated by: [EMAIL PROTECTED]
Reported By: zbowden at vt dot edu
-Status: Open
+Status: Assigned
Bug Type: LDAP related
Operating System: Windows 2003
PHP Version: 5CVS-2005-09-12 (snap)
Assigned To: edink
Previous Comments:
[2005-10-27 17:25:23] zbowden at vt dot edu
tried the latest snapshot; I not longer get the access violation,
however I cannot connect to any ldap server via LDAPS URI (says it
can't contact server).
I did use ntfilemon to make sure the ldap.conf (and ldaprc) files were
being read and they are. Not sure where the problem is though? I rolled
back to the release version of 5.0.4 just to be sure it would still work
and I can connect & bind to the ldap servers via LDAPS (& start_tls).
[2005-10-24 01:14:59] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
[2005-09-12 19:41:55] [EMAIL PROTECTED]
Someone updated some libs..assigned to that someone. :)
[2005-09-12 18:49:18] zbowden at vt dot edu
Description:
After moving to 5.0.5 from 5.0.4 I can no longer do ldap searches when
connecting via LDAPS URI -> ldap_connect(ldaps://server.com). I'm only
using Windows 2003/IIS6/ISAPI but it might occur on other platforms.
Replacing the libeay32.dll and ssleay32.dll with the versions
distributed with 5.0.4 fix the problem.
On the LDAP Server side I've tested against a Windows 2000 Active
Directory LDAP server and an OpenLDAP server and get the same results.
Reproduce code:
---
$host = "ldaps://server.com";
$ldap = ldap_connect($host);
$baseDn = "ou=accounts,dc=com";
// access violation will occur here
$result = ldap_search($ldap, $baseDn, "name=user", array('dn'));
Expected result:
PHP has encountered an Access Violation at _
--
Edit this bug report at http://bugs.php.net/?id=34482&edit=1
#34945 [Opn]: exec(): Problem with quotes in commandline
ID: 34945
User updated by: mplomer at gmx dot de
Reported By: mplomer at gmx dot de
Status: Open
Bug Type: Feature/Change Request
Operating System: WinXP
PHP Version: 5CVS-2005-10-21 (snap)
New Comment:
cmd.exe /C accepts only two quotes in a commandline. If there are more,
then the first and the last quote is removed.
This makes it impossible to pass commandlines like:
"C:/Program Files/bla/bla.exe" "c:/my files/bla.txt"
So it is IMHO the best way, if we create an option to bypass the
command-interpreter.
Previous Comments:
[2005-10-21 14:58:25] cspeer at gmx dot de
I have the same problem. I have also no solution to execute commands
with many quotes.
[2005-10-21 14:18:37] mplomer at gmx dot de
Sure, it's not directly a Bug in PHP, but it's a feature-request to
workaround a bug/feature of cmd.exe:
We need a possibility to bypass the command-interpreter for execution
of commands, since cmd.exe can't execute it complete correctly.
Or someone finds a solution to escape quotes correctly. I will check
this out over the weekend ;-)
[2005-10-21 12:58:36] [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.
[2005-10-21 12:54:39] mplomer at gmx dot de
Description:
If i have a complicated commandline with quotes and spaces in it, and
pass it to exec(), system(), ..., then i get under Windows "path or
filename not found" despite the filenames are correct.
The Problem is the following:
PHP starts a command over the command-interpreter by prefixing the
commandline with "cmd.exe /c ".
Test in DOS-Box:
If I enter the command in a "DOS-Box", the result is ok, but if I
prefix it with "cmd.exe /c ", then i get the same failure as in PHP.
If you read the "manpage" ("cmd.exe /?"), there is a hint, that
"cmd.exe /c" has problems with quotes. And IMHO there is no way to
escape theese quotes.
My solutions are:
- Someone finds a way to escape quotes for cmd.exe
- A new Parameter for system()/exec()/...
- ... or better: A php.ini-setting, ... which controls, if the command
is executed over the shell, or executed directly.
Reproduce code:
---
system('"D:\Program Files\fop\fop.bat" "path with blanks/to/bla.fo"
"output path/bla.pdf"');
Expected result:
Successful execution.
Actual result:
--
cmd.exe says: "path/file not found"
--
Edit this bug report at http://bugs.php.net/?id=34945&edit=1
#34978 [Opn]: php out of memory or segmentation fault while installing sugarcrm 3.5.1a
ID: 34978
User updated by: cdc at ccicon dot com
Reported By: cdc at ccicon dot com
Status: Open
Bug Type: Reproducible crash
Operating System: linux i386
PHP Version: 5.0.5
New Comment:
The zend.ze_compatiblity_mode is set to 1 in the index.php file and
several other files using the following test for php version number
if (substr(phpversion(), 0, 1) == "5") {
ini_set("zend.ze1_compatibility_mode", "1");
}
Disabling this option (ie zend.ze_compatiblity_mode=0) under php 5.0.5
and under the last cvs snapshot that was recommended seems to solve
this race condition. I have not tested the code fully to see that this
hasn't introduced other problems. However, it does remove the out of
memory and segfault problems.
Were there changes made in php 5.0.5 and later that make this option
obsolete. Or, will disabling this condition lead to other compatility
issues?
TTYL
CDC
Previous Comments:
[2005-10-27 18:53:57] cdc at ccicon dot com
I assume you meant ze1_compatiblity_mode and compact was just a typo?
Yes compatibility_mode is set. It is explicitly set numerous places
within the Sugar Code. I can try changing it, but I'm assuming it was
set within the code for a reason.
I'll try changing it and see what happens.
[2005-10-27 17:27:49] [EMAIL PROTECTED]
When getting the error is ze1 compact mode enabled or disabled and does
changing the setting alter the behaviour in any way?
[2005-10-27 11:56:02] [EMAIL PROTECTED]
I can't say the exact point of failure (though its due to how the
objects are linked to each other), but I recently had to get a highly
modified version of this running under 5.1 and it was falling into
infinite loops. Had to disable the ze1.compatibility_mode, remove the
majority of explicit reference usage (xxx = & object) and use some
explcit clone calls in spots. Runs stable after those changes, so not
sure if this is just a PHP compatbility issue.
[2005-10-26 21:00:22] cdc at ccicon dot com
>From the application logs, it is apparent that many hundreds, even
thousands of lines of code are executing successfully after the post
before this out of memory condition occurs. I have not yet been able
to trace the exact code location as I cannot step the code in my Zend
Studios environment using php 5.1. It appears the the code may be
dying on either and array_merge or in a mysql call. I will roll back
to php 5.0.5, which I can step in the Zend debugger, and attempt to
isolate the exact section of code which is generating these errors. If
I can locate it, I can perhaps write a small test script to reproduce
the error under the CVS snapshot release.
This will likely take me a day or two to complete.
Thanks for your continued attention to this problem.
TTYL
CDC
[2005-10-26 17:10:04] [EMAIL PROTECTED]
Can you create some sort of a simple test case?
For example if you pass all get/post/cookie data from the failing
request to script do you get the same error?
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/34978
--
Edit this bug report at http://bugs.php.net/?id=34978&edit=1
#35003 [Com]: Warning: PDOStatement::fetch(): column 0 data was too large for buffer and was
ID: 35003
Comment by: vs at ez dot no
Reported By: [EMAIL PROTECTED]
Status: Assigned
Bug Type: Oracle related
Operating System: Linux - Fedora Core 1
PHP Version: 5.1.0RC3
Assigned To: tony2001
New Comment:
Note that the query result is wrong. There actually should have been 0
instead of "". This is probably caused by the same problem.
Previous Comments:
[2005-10-27 18:22:56] [EMAIL PROTECTED]
Description:
Strange warning when fetching data from an Oracle DB with PDO:
"column N data was too large for buffer and was truncated to fit it"
Reproduce code:
---
Environment:
PHP version: 5.1.0RC3
Server version: Oracle9i Enterprise Edition Release 9.2.0.4.0 -
Production
Client libraries: oracle-instantclient 10.1.0.4
OS: Fedora Core 1
How to reproduce:
=
1. Execute the following query on your Oracle database:
CREATE TABLE pdotest (some_num INTEGER DEFAULT 0 NOT NULL);
2. Run the following script:
===
query( $query );
for( $i=0; ( $row = $sth->fetch( PDO::FETCH_ASSOC ) ); $i++ )
var_dump( $row );
echo "$i rows fetched.\n";
?>
===
Expected result:
No warnings.
Actual result:
--
Warning: PDOStatement::fetch(): column 0 data was too large for buffer
and was truncated to fit it in /path/to/test.php on
line 7
array(1) {
["DATA_DEFAULT"]=>
string(0) ""
}
1 rows fetched.
--
Edit this bug report at http://bugs.php.net/?id=35003&edit=1
#34978 [Opn]: php out of memory or segmentation fault while installing sugarcrm 3.5.1a
ID: 34978 User updated by: cdc at ccicon dot com Reported By: cdc at ccicon dot com Status: Open Bug Type: Reproducible crash Operating System: linux i386 PHP Version: 5.0.5 New Comment: I assume you meant ze1_compatiblity_mode and compact was just a typo? Yes compatibility_mode is set. It is explicitly set numerous places within the Sugar Code. I can try changing it, but I'm assuming it was set within the code for a reason. I'll try changing it and see what happens. Previous Comments: [2005-10-27 17:27:49] [EMAIL PROTECTED] When getting the error is ze1 compact mode enabled or disabled and does changing the setting alter the behaviour in any way? [2005-10-27 11:56:02] [EMAIL PROTECTED] I can't say the exact point of failure (though its due to how the objects are linked to each other), but I recently had to get a highly modified version of this running under 5.1 and it was falling into infinite loops. Had to disable the ze1.compatibility_mode, remove the majority of explicit reference usage (xxx = & object) and use some explcit clone calls in spots. Runs stable after those changes, so not sure if this is just a PHP compatbility issue. [2005-10-26 21:00:22] cdc at ccicon dot com >From the application logs, it is apparent that many hundreds, even thousands of lines of code are executing successfully after the post before this out of memory condition occurs. I have not yet been able to trace the exact code location as I cannot step the code in my Zend Studios environment using php 5.1. It appears the the code may be dying on either and array_merge or in a mysql call. I will roll back to php 5.0.5, which I can step in the Zend debugger, and attempt to isolate the exact section of code which is generating these errors. If I can locate it, I can perhaps write a small test script to reproduce the error under the CVS snapshot release. This will likely take me a day or two to complete. Thanks for your continued attention to this problem. TTYL CDC [2005-10-26 17:10:04] [EMAIL PROTECTED] Can you create some sort of a simple test case? For example if you pass all get/post/cookie data from the failing request to script do you get the same error? [2005-10-26 16:43:04] cdc at ccicon dot com I realize that a general out of memory condition is not a bug. However, this appears to be some kind of race condition that is consumming memory. This problem in new since version 5.0.4. The same code runs fine under 5.0.4 but generates this race condition in 5.0.5 and newer. As you can see from the error message below, I already have the memlimit set at 64M. I started at 16. It makes no difference where I have it set, the race condition consumes all available memory and fails with an out of memory error. I will attempt to isolate the code in sugar which is resulting in the race condition, however, the fact remains that this code runs fine under 5.0.4 and does not run under new versions. 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/34978 -- Edit this bug report at http://bugs.php.net/?id=34978&edit=1
#34904 [Opn]: Relocation error in libphp5.so when starting Apache2
ID: 34904 User updated by: sean dot healey at bayernlb dot co dot uk Reported By: sean dot healey at bayernlb dot co dot uk Status: Open Bug Type: Sybase-ct (ctlib) related Operating System: Solaris 8 PHP Version: 5.0.5 New Comment: Just another thing to note: The following message appears during 'make install' ... "libtool: install: warning: remember to run `libtool --finish /var/build/php-5.0.5/libs'" I would expect to see the message ... -- Libraries have been installed in: /var/build/php-5.0.5/libs If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the `LD_LIBRARY_PATH' environment variable during execution - use the `-RLIBDIR' linker flag See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages. -- ... during the install phase, but this is missing. I presume this is purely informational? Sorry - I know this is unrelated to the above, just thought I should bring it to your attention. Previous Comments: [2005-10-27 18:18:23] sean dot healey at bayernlb dot co dot uk I have managed to get around the build problem by sym-linking libintl.so -> libintl.so.1 in the Sybase libraries path. Apache2 now starts with the php5 module configured. This seems to me to be an issue with the PHP build - we have no such problems compiling other CTLIB applications! Please note - the 'duplicate' name of the libintl library is NOT Sybase's problem. Sybase support say that they created that library 'years' before Solaris introduced one of the same name. Bittersweet victory though, because now sybase_connect() won't connect despite the interfaces file being present, correct and configured in php.ini. [2005-10-27 11:30:54] sean dot healey at bayernlb dot co dot uk Whoah! Please don't be misled by the configure script I submitted in this bug report - the LDFLAGS and CPPFLAGS variables were set during my attempts to work around the problem because I originally thought that the build was picking up the wrong libtcl.so. I have since verified that the only copies of this library on my system are under the Sybase paths. It does appear that the wrong libintl.so library is being picked up - it should be using the one under the Sybase path, but is ignoring it and using the one under /usr/lib instead. I have tried this build against both the Sybase 12.0 and 12.5 client libraries with identical results. My original configure script is: #!/usr/bin/sh DSQUERY=fx_dbserver2_ds SYBASE=/dpkg/sybase/sybase12_5 SYBASE_OCS=OCS-12_5 LD_LIBRARY_PATH=$SYBASE/$SYBASE_OCS/lib:/usr/local/lib:$LD_LIBRARY_PATH PATH=/usr/ccs/bin:$PATH export DSQUERY SYBASE SYBASE_OCS LD_LIBRARY_PATH PATH cd php-5.0.5 ./configure \ --prefix=/usr/local/php \ --with-apxs2=/usr/local/apache2/bin/apxs \ --with-sybase-ct=$SYBASE/$SYBASE_OCS \ --without-bz2 This produces a libphp5.so which is linked as follows: ldd /usr/local/apache2/modules/libphp5.so libtcl.so => /dpkg/sybase/sybase12_5/OCS-12_5/lib/libtcl.so libintl.so.1 => /usr/lib/libintl.so.1 libcomn.so => /dpkg/sybase/sybase12_5/OCS-12_5/lib/libcomn.so libct.so => /dpkg/sybase/sybase12_5/OCS-12_5/lib/libct.so libcs.so => /dpkg/sybase/sybase12_5/OCS-12_5/lib/libcs.so libresolv.so.2 =>/usr/lib/libresolv.so.2 libm.so.1 => /usr/lib/libm.so.1 libdl.so.1 =>/usr/lib/libdl.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libsocket.so.1 =>/usr/lib/libsocket.so.1 libz.so.1 => /usr/lib/libz.so.1 libxml2.so.2 => /usr/local/lib/libxml2.so.2 libiconv.so.2 => /usr/local/lib/libiconv.so.2 libc.so.1 => /usr/lib/libc.so.1 libmp.so.2 =>/usr/lib/libmp.so.2 libpthread.so.1 => /usr/lib/libpthread.so.1 libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 /usr/platform/SUNW,Ultra-80/lib/libc_psr.so.1 libthread.so.1 =>/usr/lib/libthread.so.1 NOTE that the reference to libintl is still linked to the wrong library. I have investigated further and found that libintl.so.1 doesn't exist under the Sybase path - only libintl.so is found there. I need to somehow force the build to pick up the Sybase library instead of the Solaris library. A solved case on the Sybase site mentions that the Solaris library /usr/lib/libintl.so.1 has nothing to do with the Sybase library of the sam
#35003 [Opn->Asn]: Warning: PDOStatement::fetch(): column 0 data was too large for buffer and was
ID: 35003
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Assigned
Bug Type: Oracle related
Operating System: Linux - Fedora Core 1
PHP Version: 5.1.0RC3
-Assigned To:
+Assigned To: tony2001
Previous Comments:
[2005-10-27 18:22:56] [EMAIL PROTECTED]
Description:
Strange warning when fetching data from an Oracle DB with PDO:
"column N data was too large for buffer and was truncated to fit it"
Reproduce code:
---
Environment:
PHP version: 5.1.0RC3
Server version: Oracle9i Enterprise Edition Release 9.2.0.4.0 -
Production
Client libraries: oracle-instantclient 10.1.0.4
OS: Fedora Core 1
How to reproduce:
=
1. Execute the following query on your Oracle database:
CREATE TABLE pdotest (some_num INTEGER DEFAULT 0 NOT NULL);
2. Run the following script:
===
query( $query );
for( $i=0; ( $row = $sth->fetch( PDO::FETCH_ASSOC ) ); $i++ )
var_dump( $row );
echo "$i rows fetched.\n";
?>
===
Expected result:
No warnings.
Actual result:
--
Warning: PDOStatement::fetch(): column 0 data was too large for buffer
and was truncated to fit it in /path/to/test.php on
line 7
array(1) {
["DATA_DEFAULT"]=>
string(0) ""
}
1 rows fetched.
--
Edit this bug report at http://bugs.php.net/?id=35003&edit=1
#35003 [NEW]: Warning: PDOStatement::fetch(): column 0 data was too large for buffer and was
From: [EMAIL PROTECTED]
Operating system: Linux - Fedora Core 1
PHP version: 5.1.0RC3
PHP Bug Type: Oracle related
Bug description: Warning: PDOStatement::fetch(): column 0 data was too large
for buffer and was
Description:
Strange warning when fetching data from an Oracle DB with PDO:
"column N data was too large for buffer and was truncated to fit it"
Reproduce code:
---
Environment:
PHP version: 5.1.0RC3
Server version: Oracle9i Enterprise Edition Release 9.2.0.4.0 -
Production
Client libraries: oracle-instantclient 10.1.0.4
OS: Fedora Core 1
How to reproduce:
=
1. Execute the following query on your Oracle database:
CREATE TABLE pdotest (some_num INTEGER DEFAULT 0 NOT NULL);
2. Run the following script:
===
query( $query );
for( $i=0; ( $row = $sth->fetch( PDO::FETCH_ASSOC ) ); $i++ )
var_dump( $row );
echo "$i rows fetched.\n";
?>
===
Expected result:
No warnings.
Actual result:
--
Warning: PDOStatement::fetch(): column 0 data was too large for buffer and
was truncated to fit it in /path/to/test.php on
line 7
array(1) {
["DATA_DEFAULT"]=>
string(0) ""
}
1 rows fetched.
--
Edit bug report at http://bugs.php.net/?id=35003&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=35003&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=35003&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=35003&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=35003&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=35003&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=35003&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=35003&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=35003&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=35003&r=support
Expected behavior: http://bugs.php.net/fix.php?id=35003&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=35003&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=35003&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=35003&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35003&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=35003&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=35003&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=35003&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=35003&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=35003&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=35003&r=mysqlcfg
#34904 [Opn]: Relocation error in libphp5.so when starting Apache2
ID: 34904 User updated by: sean dot healey at bayernlb dot co dot uk Reported By: sean dot healey at bayernlb dot co dot uk Status: Open Bug Type: Sybase-ct (ctlib) related Operating System: Solaris 8 PHP Version: 5.0.5 New Comment: I have managed to get around the build problem by sym-linking libintl.so -> libintl.so.1 in the Sybase libraries path. Apache2 now starts with the php5 module configured. This seems to me to be an issue with the PHP build - we have no such problems compiling other CTLIB applications! Please note - the 'duplicate' name of the libintl library is NOT Sybase's problem. Sybase support say that they created that library 'years' before Solaris introduced one of the same name. Bittersweet victory though, because now sybase_connect() won't connect despite the interfaces file being present, correct and configured in php.ini. Previous Comments: [2005-10-27 11:30:54] sean dot healey at bayernlb dot co dot uk Whoah! Please don't be misled by the configure script I submitted in this bug report - the LDFLAGS and CPPFLAGS variables were set during my attempts to work around the problem because I originally thought that the build was picking up the wrong libtcl.so. I have since verified that the only copies of this library on my system are under the Sybase paths. It does appear that the wrong libintl.so library is being picked up - it should be using the one under the Sybase path, but is ignoring it and using the one under /usr/lib instead. I have tried this build against both the Sybase 12.0 and 12.5 client libraries with identical results. My original configure script is: #!/usr/bin/sh DSQUERY=fx_dbserver2_ds SYBASE=/dpkg/sybase/sybase12_5 SYBASE_OCS=OCS-12_5 LD_LIBRARY_PATH=$SYBASE/$SYBASE_OCS/lib:/usr/local/lib:$LD_LIBRARY_PATH PATH=/usr/ccs/bin:$PATH export DSQUERY SYBASE SYBASE_OCS LD_LIBRARY_PATH PATH cd php-5.0.5 ./configure \ --prefix=/usr/local/php \ --with-apxs2=/usr/local/apache2/bin/apxs \ --with-sybase-ct=$SYBASE/$SYBASE_OCS \ --without-bz2 This produces a libphp5.so which is linked as follows: ldd /usr/local/apache2/modules/libphp5.so libtcl.so => /dpkg/sybase/sybase12_5/OCS-12_5/lib/libtcl.so libintl.so.1 => /usr/lib/libintl.so.1 libcomn.so => /dpkg/sybase/sybase12_5/OCS-12_5/lib/libcomn.so libct.so => /dpkg/sybase/sybase12_5/OCS-12_5/lib/libct.so libcs.so => /dpkg/sybase/sybase12_5/OCS-12_5/lib/libcs.so libresolv.so.2 =>/usr/lib/libresolv.so.2 libm.so.1 => /usr/lib/libm.so.1 libdl.so.1 =>/usr/lib/libdl.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libsocket.so.1 =>/usr/lib/libsocket.so.1 libz.so.1 => /usr/lib/libz.so.1 libxml2.so.2 => /usr/local/lib/libxml2.so.2 libiconv.so.2 => /usr/local/lib/libiconv.so.2 libc.so.1 => /usr/lib/libc.so.1 libmp.so.2 =>/usr/lib/libmp.so.2 libpthread.so.1 => /usr/lib/libpthread.so.1 libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 /usr/platform/SUNW,Ultra-80/lib/libc_psr.so.1 libthread.so.1 =>/usr/lib/libthread.so.1 NOTE that the reference to libintl is still linked to the wrong library. I have investigated further and found that libintl.so.1 doesn't exist under the Sybase path - only libintl.so is found there. I need to somehow force the build to pick up the Sybase library instead of the Solaris library. A solved case on the Sybase site mentions that the Solaris library /usr/lib/libintl.so.1 has nothing to do with the Sybase library of the same name, which is possibly why the object not found error since my build is linking to the wrong library! [2005-10-26 17:43:50] [EMAIL PROTECTED] Don't try outsmarting the configure. User error -> not PHP bug. [2005-10-18 11:03:24] sean dot healey at bayernlb dot co dot uk Description: I am getting the following error when trying to start Apache2 with the PHP plugin configured: # ./apachectl start Syntax error on line 232 of /usr/local/apache2/conf/httpd.conf: Cannot load /usr/local/apache2/modules/libphp5.so into server: ld.so.1: /usr/local/apache2/bin/httpd: fatal: relocation error: file /dpkg/sybase/OCS-12_0/lib/libtcl.so: symbol comn_free: referenced symbol not found When built without Sybase client library, the plugin starts up just fine. The php module DOES appear to be linked against the correct copy of libtcl.so - here are the without-sybase and with-sybase ldd outputs: # ldd libphp5.so.without_sybase libresolv.so.2 =>/usr/lib/libresolv.so.2 libm.so.1 => /usr/lib/libm.so.1 libdl.so.1 =>/usr/lib/libdl.so.1 libn
#34955 [Opn->Asn]: PEAR install fails
ID: 34955 Updated by: [EMAIL PROTECTED] Reported By: squasar at eternalviper dot net -Status: Open +Status: Assigned Bug Type: Compile Failure Operating System: Mac OS X 10.4.2/Darwin 8.2.0 PHP Version: 5.1.0RC3 Assigned To: cellog Previous Comments: [2005-10-27 13:30:26] squasar at eternalviper dot net No; PEAR does not install. As far as I can tell, install-pear- nozlib.phar never runs at all; php parses it and spits out 800K worth of ? characters. [2005-10-27 05:29:23] [EMAIL PROTECTED] I can't reproduce this on gentoo linux. Does PEAR actually install? [2005-10-22 11:50:54] [EMAIL PROTECTED] Greg, check it out please. [2005-10-22 05:58:17] squasar at eternalviper dot net Description: The "Installing PEAR environment" phase of the "make install" command results in several pages of garbage output and no installed PEAR. The error occurs when make attempts to run the install-pear-nozlib.phar script. Reproduce code: --- $ ./buildconf --force $ ./configure --prefix=/usr --with-apxs --enable-cli --disable-short-tags --with-zlib --with-bz2 --enable-ftp --with-iconv --enable-mbstring --with-mysql=/usr --enable-sockets --enable-debug --enable-simplexml --with-xsl=/usr --with-curl=/usr --with-curlwrappers --enable-bcmath --with-gmp=/usr/local --with-gd --with-freetype-dir=/usr/X11R6 --enable-gd-native-ttf --with-imap=/usr/local/imap --with-imap-ssl=/usr --with-xmlrpc --with-xml-dir=/usr --with-expat-dir=/usr --with-iconv-dir=/usr --with-mysqli=/usr/bin/mysql_config --with-pdo-mysql=/usr --with-embedded-mysqli --enable-maintainer-zts --enable-zend-multibyte --enable-memory-limit --with-svn=/usr $ make -j 3 $ sudo make install Expected result: Installing PHP SAPI module: apache [activating module `php5' in /etc/httpd/httpd.conf] cp libs/libphp5.so /usr/libexec/httpd/libphp5.so chmod 755 /usr/libexec/httpd/libphp5.so cp /etc/httpd/httpd.conf /etc/httpd/httpd.conf.bak cp /etc/httpd/httpd.conf.new /etc/httpd/httpd.conf rm /etc/httpd/httpd.conf.new Installing PHP CLI binary:/usr/bin/ Installing PHP CLI man page: /usr/man/man1/ Installing build environment: /usr/lib/php/build/ Installing header files: /usr/include/php/ Installing helper programs: /usr/bin/ program: phpize program: php-config Installing man pages: /usr/man/man1/ page: phpize.1 page: php-config.1 Installing PEAR environment: /usr/lib/php/ Installing PDO headers: /usr/include/php/ext/pdo/ Actual result: -- Installing PHP SAPI module: apache [activating module `php5' in /etc/httpd/httpd.conf] cp libs/libphp5.so /usr/libexec/httpd/libphp5.so chmod 755 /usr/libexec/httpd/libphp5.so cp /etc/httpd/httpd.conf /etc/httpd/httpd.conf.bak cp /etc/httpd/httpd.conf.new /etc/httpd/httpd.conf rm /etc/httpd/httpd.conf.new Installing PHP CLI binary:/usr/bin/ Installing PHP CLI man page: /usr/man/man1/ Installing build environment: /usr/lib/php/build/ Installing header files: /usr/include/php/ Installing helper programs: /usr/bin/ program: phpize program: php-config Installing man pages: /usr/man/man1/ page: phpize.1 page: php-config.1 Installing PEAR environment: /usr/lib/php/ ???/* this continues for exactly 821228 characters total */???Installing PDO headers: /usr/include/php/ext/pdo/ -- Edit this bug report at http://bugs.php.net/?id=34955&edit=1
#34978 [Opn]: php out of memory or segmentation fault while installing sugarcrm 3.5.1a
ID: 34978 Updated by: [EMAIL PROTECTED] Reported By: cdc at ccicon dot com Status: Open Bug Type: Reproducible crash Operating System: linux i386 PHP Version: 5.0.5 New Comment: When getting the error is ze1 compact mode enabled or disabled and does changing the setting alter the behaviour in any way? Previous Comments: [2005-10-27 11:56:02] [EMAIL PROTECTED] I can't say the exact point of failure (though its due to how the objects are linked to each other), but I recently had to get a highly modified version of this running under 5.1 and it was falling into infinite loops. Had to disable the ze1.compatibility_mode, remove the majority of explicit reference usage (xxx = & object) and use some explcit clone calls in spots. Runs stable after those changes, so not sure if this is just a PHP compatbility issue. [2005-10-26 21:00:22] cdc at ccicon dot com >From the application logs, it is apparent that many hundreds, even thousands of lines of code are executing successfully after the post before this out of memory condition occurs. I have not yet been able to trace the exact code location as I cannot step the code in my Zend Studios environment using php 5.1. It appears the the code may be dying on either and array_merge or in a mysql call. I will roll back to php 5.0.5, which I can step in the Zend debugger, and attempt to isolate the exact section of code which is generating these errors. If I can locate it, I can perhaps write a small test script to reproduce the error under the CVS snapshot release. This will likely take me a day or two to complete. Thanks for your continued attention to this problem. TTYL CDC [2005-10-26 17:10:04] [EMAIL PROTECTED] Can you create some sort of a simple test case? For example if you pass all get/post/cookie data from the failing request to script do you get the same error? [2005-10-26 16:43:04] cdc at ccicon dot com I realize that a general out of memory condition is not a bug. However, this appears to be some kind of race condition that is consumming memory. This problem in new since version 5.0.4. The same code runs fine under 5.0.4 but generates this race condition in 5.0.5 and newer. As you can see from the error message below, I already have the memlimit set at 64M. I started at 16. It makes no difference where I have it set, the race condition consumes all available memory and fails with an out of memory error. I will attempt to isolate the code in sugar which is resulting in the race condition, however, the fact remains that this code runs fine under 5.0.4 and does not run under new versions. [2005-10-26 16:35:53] [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. Out of memory is not a bug in PHP, it simply means the memory limit needs to be increased. Try setting it to 20 megs and see if that solves the problem. 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/34978 -- Edit this bug report at http://bugs.php.net/?id=34978&edit=1
#34482 [Fbk->Opn]: LDAP Searches cause Access Violation when connecting via LDAPS
ID: 34482
User updated by: zbowden at vt dot edu
Reported By: zbowden at vt dot edu
-Status: Feedback
+Status: Open
Bug Type: LDAP related
Operating System: Windows 2003
PHP Version: 5CVS-2005-09-12 (snap)
Assigned To: edink
New Comment:
tried the latest snapshot; I not longer get the access violation,
however I cannot connect to any ldap server via LDAPS URI (says it
can't contact server).
I did use ntfilemon to make sure the ldap.conf (and ldaprc) files were
being read and they are. Not sure where the problem is though? I rolled
back to the release version of 5.0.4 just to be sure it would still work
and I can connect & bind to the ldap servers via LDAPS (& start_tls).
Previous Comments:
[2005-10-24 01:14:59] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
[2005-09-12 19:41:55] [EMAIL PROTECTED]
Someone updated some libs..assigned to that someone. :)
[2005-09-12 18:49:18] zbowden at vt dot edu
Description:
After moving to 5.0.5 from 5.0.4 I can no longer do ldap searches when
connecting via LDAPS URI -> ldap_connect(ldaps://server.com). I'm only
using Windows 2003/IIS6/ISAPI but it might occur on other platforms.
Replacing the libeay32.dll and ssleay32.dll with the versions
distributed with 5.0.4 fix the problem.
On the LDAP Server side I've tested against a Windows 2000 Active
Directory LDAP server and an OpenLDAP server and get the same results.
Reproduce code:
---
$host = "ldaps://server.com";
$ldap = ldap_connect($host);
$baseDn = "ou=accounts,dc=com";
// access violation will occur here
$result = ldap_search($ldap, $baseDn, "name=user", array('dn'));
Expected result:
PHP has encountered an Access Violation at _
--
Edit this bug report at http://bugs.php.net/?id=34482&edit=1
#33997 [Asn]: Returned: Bug #16069 - ICONV transliteration failure
ID: 33997 Updated by: [EMAIL PROTECTED] Reported By: RVaughn at pheedo dot com Status: Assigned Bug Type: ICONV related Operating System: * PHP Version: 5CVS, 4CVS (2005-08-30) Assigned To: derick New Comment: Jani, I tried your patch and it does not fix the bug, at least on my system. Previous Comments: [2005-08-08 00:10:15] [EMAIL PROTECTED] Assigning to Derick who's comment about my patch was "It's funny" and other comment about the iconv code "this is a mess" :) [2005-08-07 23:47:31] RVaughn at pheedo dot com The patch Sniper referred to: http://www.php.net/~jani/patches/bug33997.patch Does fix the bug properly and completely, we've tested it thoroughly, so I won't close this bug but I do think you can roll that patch forward into 4.4.1 as a fix and close this once that's done? Please let me know if there's anything else I can provide? Do you really need the .out and .exp if I can assure you the patch fixes the bug? Or do you want to see the results from the patched install? Thanks, Rob [2005-08-07 14:42:23] [EMAIL PROTECTED] Please provide a location where we can download your failed test's .out and .exp file. [2005-08-05 22:15:08] [EMAIL PROTECTED] Well, the patch is not approved/applied to CVS yet so keep this report open. We'll close this once the bug is really fixed. [2005-08-05 01:18:33] RVaughn at pheedo dot com Works perfectly! Hopefully this patch can be rolled into PHP 4.4.1? This one can be closed, that was the fix. Thanks much! Cheers! 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/33997 -- Edit this bug report at http://bugs.php.net/?id=33997&edit=1
#35001 [Opn->Fbk]: PDO unexpected crash on update
ID: 35001 Updated by: [EMAIL PROTECTED] Reported By: antleclercq at online dot fr -Status: Open +Status: Feedback Bug Type: PDO related Operating System: Win2000 PHP Version: 5CVS-2005-10-27 (snap) New Comment: Add var_dump($sql); just before $res->prepare() and paste the output here. Previous Comments: [2005-10-27 16:26:11] antleclercq at online dot fr Description: Hi, I get this stange bug with the following code. I thought it was fixed when I read the bug report: bugs.php.net/?id=34861, but it seems only partially. Create the folowing table in a "test" db under mysql : CREATE TABLE `test` ( `id` int(11) NOT NULL default '0', `test1` text NOT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8; INSERT INTO `test` VALUES (1, 'test', ''); Using the code below, try posting the following string : x"'"x:a (magic_quotes_gpc is on) I took the latest snapshot for Win2000. Info : that doesn't crash when using $db->exec($sql). Antoine Reproduce code: --- prepare($sql); $res->execute(); } ?> " name="string"> Expected result: It should update the record. Actual result: -- Warning: PDOStatement::execute() [function.execute]: SQLSTATE[HY093]: Invalid parameter number: no parameters were bound in C:\Program Files\Apache Group\Apache2\htdocs\test.php on line 16 -- Edit this bug report at http://bugs.php.net/?id=35001&edit=1
#34895 [Opn]: headers_list functionality regression
ID: 34895
User updated by: alex at weej dot com
Reported By: alex at weej dot com
Status: Open
Bug Type: Feature/Change Request
Operating System: GNU Linux
PHP Version: 5.0.5
New Comment:
The documentation has been updated now.
Is there going to be a replacement function in the very near future? I
need this for a caching problem!
Previous Comments:
[2005-10-17 18:39:08] alex at weej dot com
Description:
The documented behaviour is exactly what I need for a project I am
working on, but now the behaviour has changed (even though the docs
haven't yet). :(
As far as I can see, there is no way to tell what headers PHP is
sending and their values, now.
apache_response_headers() is /not/ a replacement, as it omits
Content-Type (the most important header in my situation) and processes
the headers PHP passes to it. I really don't want to resort to wrapper
functions to maintain my own list. The documentation describes EXACTLY
the functionality I want.
I am upset! :(
http://uk.php.net/manual/en/function.headers-list.php
Reproduce code:
---
Expected result:
array(4) {
[0]=>
string(29) "X-Powered-By: PHP/5.0.0"
[1]=>
string(19) "Set-Cookie: foo=bar"
[2]=>
string(18) "X-Sample-Test: foo"
[3]=>
string(24) "Content-type: text/plain"
}
Actual result:
--
array(4) {
[0]=>
string(12) "X-Powered-By"
[1]=>
string(10) "Set-Cookie"
[2]=>
string(13) "X-Sample-Test"
[3]=>
string(12) "Content-Type"
}
--
Edit this bug report at http://bugs.php.net/?id=34895&edit=1
#35001 [NEW]: PDO unexpected crash on update
From: antleclercq at online dot fr Operating system: Win2000 PHP version: 5CVS-2005-10-27 (snap) PHP Bug Type: PDO related Bug description: PDO unexpected crash on update Description: Hi, I get this stange bug with the following code. I thought it was fixed when I read the bug report: bugs.php.net/?id=34861, but it seems only partially. Create the folowing table in a "test" db under mysql : CREATE TABLE `test` ( `id` int(11) NOT NULL default '0', `test1` text NOT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8; INSERT INTO `test` VALUES (1, 'test', ''); Using the code below, try posting the following string : x"'"x:a (magic_quotes_gpc is on) I took the latest snapshot for Win2000. Info : that doesn't crash when using $db->exec($sql). Antoine Reproduce code: --- prepare($sql); $res->execute(); } ?> " name="string"> Expected result: It should update the record. Actual result: -- Warning: PDOStatement::execute() [function.execute]: SQLSTATE[HY093]: Invalid parameter number: no parameters were bound in C:\Program Files\Apache Group\Apache2\htdocs\test.php on line 16 -- Edit bug report at http://bugs.php.net/?id=35001&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=35001&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=35001&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=35001&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=35001&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=35001&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=35001&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=35001&r=needscript Try newer version: http://bugs.php.net/fix.php?id=35001&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=35001&r=support Expected behavior: http://bugs.php.net/fix.php?id=35001&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=35001&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=35001&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=35001&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35001&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=35001&r=dst IIS Stability: http://bugs.php.net/fix.php?id=35001&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=35001&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=35001&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=35001&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=35001&r=mysqlcfg
#35000 [Opn->Fbk]: mail() function freezes server (Postfix)
ID: 35000 Updated by: [EMAIL PROTECTED] Reported By: william at knowmad dot com -Status: Open +Status: Feedback Bug Type: Mail related Operating System: Mandriva Linux 10.1 PHP Version: 4.4.0 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Previous Comments: [2005-10-27 16:18:39] william at knowmad dot com Description: Using the mail function in a script that gets called 5-10 times in parallel appears to be causing the entire system to freeze when used in conjuction with Postfix under Mandriva Linux 10.1. A hard reboot is necessary to restore function to the system. Because the system is frozen, debugging is difficult. By removing the mail() call, no further freezes have been experienced. -- Edit this bug report at http://bugs.php.net/?id=35000&edit=1
#35000 [NEW]: mail() function freezes server (Postfix)
From: william at knowmad dot com Operating system: Mandriva Linux 10.1 PHP version: 4.4.0 PHP Bug Type: Mail related Bug description: mail() function freezes server (Postfix) Description: Using the mail function in a script that gets called 5-10 times in parallel appears to be causing the entire system to freeze when used in conjuction with Postfix under Mandriva Linux 10.1. A hard reboot is necessary to restore function to the system. Because the system is frozen, debugging is difficult. By removing the mail() call, no further freezes have been experienced. -- Edit bug report at http://bugs.php.net/?id=35000&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=35000&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=35000&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=35000&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=35000&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=35000&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=35000&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=35000&r=needscript Try newer version: http://bugs.php.net/fix.php?id=35000&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=35000&r=support Expected behavior: http://bugs.php.net/fix.php?id=35000&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=35000&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=35000&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=35000&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35000&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=35000&r=dst IIS Stability: http://bugs.php.net/fix.php?id=35000&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=35000&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=35000&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=35000&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=35000&r=mysqlcfg
#34515 [Com]: mysqli_fetch_assoc crashes application
ID: 34515
Comment by: mark at tranchant dot plus dot com
Reported By: jaba at inbox dot lv
Status: Feedback
Bug Type: MySQLi related
Operating System: Debian GNU/Linux
PHP Version: 5.0.5
New Comment:
Gah. I think I've got as far as my abilities allow.
Basically, if either add_assoc_zval or add_assoc_null are called with
anything other than a static string, crash. Even:
char *tmp;
...
sprintf(tmp, "hello");
add_assoc_zval(return_value, tmp, res);
fails, although:
add_assoc_zval(return_value, "hello", res);
does not, and $array['hello'] returns the first value as expected.
There is no issue with the mysql_fetch_fields() function: the failure
occurs even with that commented out.
I've traced the code path down to _zend_hash_add_or_update(), but I
don't know enough to see any problems on the way there.
***
#define add_assoc_zval(__arg, __key, __value) add_assoc_zval_ex(__arg,
__key, strlen(__key)+1, __value)
***
ZEND_API int add_assoc_zval_ex(zval *arg, char *key, uint key_len, zval
*value)
{
return zend_symtable_update(Z_ARRVAL_P(arg), key, key_len, (void *)
&value, sizeof(zval *), NULL);
}
***
static inline int zend_symtable_update(HashTable *ht, char *arKey, uint
nKeyLength, void *pData, uint nDa
taSize, void **pDest) \
{
HANDLE_NUMERIC(arKey, nKeyLength, zend_hash_index_update(ht, idx,
pData, nDataSize, pDest));
return zend_hash_update(ht, arKey, nKeyLength, pData, nDataSize,
pDest);
}
***
#define zend_hash_update(ht, arKey, nKeyLength, pData, nDataSize,
pDest) \
_zend_hash_add_or_update(ht, arKey, nKeyLength, pData, nDataSize,
pDest, HASH_UPDATE ZEND_FILE_LINE_CC)
***
Previous Comments:
[2005-10-27 14:22:43] mark at tranchant dot plus dot com
I've just written a quick C program using the MySQL C API and can
confirm that mysql_fetch_fields() works fine. The problem does appear
to be with the PHP code. I'll keep looking.
[2005-10-27 13:09:52] mark at tranchant dot plus dot com
Not easily, no. I'm not set up for external users. If it would really
help, I could try. I've done some more digging:
In ext/mysqli/mysqli.c, there is the following code:
line 653:
if (fetchtype & MYSQLI_ASSOC) {
fields = mysql_fetch_fields(result);
}
line 677:
if (fetchtype & MYSQLI_ASSOC) {
if (fetchtype & MYSQLI_NUM) {
ZVAL_ADDREF(res);
}
add_assoc_zval(return_value, fields[i].name, res);
}
line 687:
if (fetchtype & MYSQLI_ASSOC) {
add_assoc_null(return_value, fields[i].name);
}
If I change the fields[i].name argument to "hello", the offending
functions then work. I successfully used fetch_array with MYSQLI_BOTH,
and $array['hello'] referred to the last element in the fetched array.
It seems as though the call to mysql_fetch_fields (part of the MySQL
API) is failing, which is not being detected by the PHP code. More
soon...
[2005-10-27 12:34:42] [EMAIL PROTECTED]
Is there any chance to get an account on this server?
[2005-10-27 12:29:06] mark at tranchant dot plus dot com
Yeah, I was right. Latest CVS snapshot (php5-STABLE-200510270836) does
not fix the issue.
[2005-10-27 12:05:40] mark at tranchant dot plus dot com
In fact, any function that tries to do the assoc thing fails:
fetch_object fails, as does fetch_array with a resulttype of
MYSQLI_ASSOC or MYSQLI_BOTH. fetch_array works when called with
MYSQLI_NUM.
I'm just compiling the latest CVS snapshot, although the diff 'twixt
5.05's ext/mysqli directory and the CVS one doesn't give me much
hope...
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/34515
--
Edit this bug report at http://bugs.php.net/?id=34515&edit=1
#34983 [Opn->Bgs]: glob/opendir (path limit)
ID: 34983 Updated by: [EMAIL PROTECTED] Reported By: trustpunk at hotmail dot com -Status: Open +Status: Bogus Bug Type: Directory function related Operating System: Windows XP PHP Version: 5.0.5 New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. This bug is a duplicate of an existing bug #31347 Previous Comments: [2005-10-27 06:19:18] trustpunk at hotmail dot com I found the real problem! Lets say I choose a download directory "dir" When I put a 255 char(s) file/dir inside the "dir" folder , I want to be able to see it listed from PHP , is there a way you guy's can fix this problem im having ? Note: Apache has no problems with letting me download a file so it can't be the 255 char(s) limit in Windows. :-) Also , im only using Apache to test this. I use (Abyss)! [2005-10-26 21:38:47] trustpunk at hotmail dot com Directory Tree 01234567891011121314 - oh no - example - Silverstein - music - 10 - Three Hours Back - 02 - Smile In Your Sleep - 01 - Your Sword Versus My Dagger - 05 - Discovering The Waterfront - 08 - Always And Never - I like inside the last folder , put the file named "testing_for_bug - oops_a_404_error.txt and rename that last folder to "I like you the way you are" , hope this helps. The path to a file is limited to 315 char(s) if your including the begining / and end / Now I know its not very possible for Windows to have so many folders but I proved that it can be done and that you should fix this , I believe this could lead to problems. [2005-10-26 21:30:51] [EMAIL PROTECTED] So, what should one do to reproduce it? What should be the directory structure etc. ? [2005-10-26 20:04:36] trustpunk at hotmail dot com Im sorry to say but PHP - v5.0.6 Dev did not fix it. Here's the path I was using , you can see if from the PHP error. Warning: filesize() [function.filesize]: stat failed for 6c7695d7af/ohn/example/Silverstein/music/10 - Three Hours Back/02 - Smile In Your Sleep/01 - Your Sword Versus My Dagger/05 - Discovering The Waterfront/08 - Always And Never/I like you the way you are/01 - Your Sword Versus My Dagger.mp3 in C:\Website\directory_listing.php on line 82 [2005-10-26 03:55:19] [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. Fixed already according to user. 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/34983 -- Edit this bug report at http://bugs.php.net/?id=34983&edit=1
#34998 [Opn->Asn]: zend.ze1_compatibility_mode doesn't implict clone when passed in array
ID: 34998 Updated by: [EMAIL PROTECTED] Reported By: jason at jasonjustman dot com -Status: Open +Status: Assigned Bug Type: Scripting Engine problem Operating System: * PHP Version: 5CVS-2005-10-27 (snap) -Assigned To: +Assigned To: dmitry Previous Comments: [2005-10-27 10:14:07] jason at jasonjustman dot com PHP Version 5.1.0RC4-dev Oct 27 2005 08:24:52 [2005-10-27 10:12:02] jason at jasonjustman dot com Description: Again, with zend.ze1_compatibility_mode, it fails to properly clone objects when calling as an argument for the array() function. This BC break is getting annoying... Reproduce code: --- value = 5; $single_container[1] = $x; $double_container[1] = array($x); $x->value = 10; $single_container[2] = $x; $double_container[2] = array($x); $x->value = 15; $single_container[3] = $x; $double_container[3] = array($x); print_r($single_container); print_r($double_container); Expected result: //single Array ( [1] => base_object Object ( [value] => 5 ) [2] => base_object Object ( [value] => 10 ) [3] => base_object Object ( [value] => 15 ) ) //double, values are correct Array ( [1] => Array ( [0] => base_object Object ( [value] => 5 ) ) [2] => Array ( [0] => base_object Object ( [value] => 10 ) ) [3] => Array ( [0] => base_object Object ( [value] => 15 ) ) ) Actual result: -- //single Array ( [1] => base_object Object ( [value] => 5 ) [2] => base_object Object ( [value] => 10 ) [3] => base_object Object ( [value] => 15 ) ) //double - values are incorrect Array ( [1] => Array ( [0] => base_object Object ( [value] => 15 ) ) [2] => Array ( [0] => base_object Object ( [value] => 15 ) ) [3] => Array ( [0] => base_object Object ( [value] => 15 ) ) ) -- Edit this bug report at http://bugs.php.net/?id=34998&edit=1
#34999 [Opn->Fbk]: setcookie() uses wrong format for expiry date in http header
ID: 34999 Updated by: [EMAIL PROTECTED] Reported By: giunta dot gaetano at sea-aeroportimilano dot it -Status: Open +Status: Feedback Bug Type: HTTP related Operating System: Solaris 8 PHP Version: 4.4.0 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Previous Comments: [2005-10-27 15:12:13] giunta dot gaetano at sea-aeroportimilano dot it Description: The day-of-week part of the expiry date in the set-cookie http header generated by PHP uses the full day name instead of the 3 letters abbreviation (as per RFC 822) on Solaris8 + Apache 2.0.54 + PHP 4.4.0. It also puts dashes between date parts insted of spaces. Note that the cookie spec that PHP follows is 'version 0' cookies, available at: http://wp.netscape.com/newsref/std/cookie_spec.html In that spec the mentioned format for time is rfc 822 (which has been superseded by rfc 1123), which explicitly mentions using 3 letters for day-of-week and spaces between date parts. PHP bug #33597 (closed) mentions explicitly rfc 2616 as permitting the long weekday format, but, imho, it does not applicate to the cookie header, which should follow only rfc 1123. BTW: on Linux and Windows, php 4.4.0 uses the rfc 1123 format... Reproduce code: --- + use mozilla LiveHTTPHeader to see results: Expected result: HTTP/1.x 200 OK Date: Thu, 27 Oct 2005 12:44:11 GMT Server: Apache/2.0.54 (Unix) PHP/4.4.0 X-Powered-By: PHP/4.4.0 Set-Cookie: hello=12345; expires=Thu, 27-Oct-05 13:44:11 GMT Content-Length: 0 Keep-Alive: timeout=15, max=1000 Connection: Keep-Alive Content-Type: text/html Actual result: -- HTTP/1.x 200 OK Date: Thu, 27 Oct 2005 12:44:11 GMT Server: Apache/2.0.54 (Unix) PHP/4.4.0 X-Powered-By: PHP/4.4.0 Set-Cookie: hello=12345; expires=Thursday, 27Oct 2005 13:44:11 GMT Content-Length: 0 Keep-Alive: timeout=15, max=1000 Connection: Keep-Alive Content-Type: text/html -- Edit this bug report at http://bugs.php.net/?id=34999&edit=1
#34999 [NEW]: setcookie() uses wrong format for expiry date in http header
From: giunta dot gaetano at sea-aeroportimilano dot it Operating system: Solaris 8 PHP version: 4.4.0 PHP Bug Type: HTTP related Bug description: setcookie() uses wrong format for expiry date in http header Description: The day-of-week part of the expiry date in the set-cookie http header generated by PHP uses the full day name instead of the 3 letters abbreviation (as per RFC 822) on Solaris8 + Apache 2.0.54 + PHP 4.4.0. It also puts dashes between date parts insted of spaces. Note that the cookie spec that PHP follows is 'version 0' cookies, available at: http://wp.netscape.com/newsref/std/cookie_spec.html In that spec the mentioned format for time is rfc 822 (which has been superseded by rfc 1123), which explicitly mentions using 3 letters for day-of-week and spaces between date parts. PHP bug #33597 (closed) mentions explicitly rfc 2616 as permitting the long weekday format, but, imho, it does not applicate to the cookie header, which should follow only rfc 1123. BTW: on Linux and Windows, php 4.4.0 uses the rfc 1123 format... Reproduce code: --- + use mozilla LiveHTTPHeader to see results: Expected result: HTTP/1.x 200 OK Date: Thu, 27 Oct 2005 12:44:11 GMT Server: Apache/2.0.54 (Unix) PHP/4.4.0 X-Powered-By: PHP/4.4.0 Set-Cookie: hello=12345; expires=Thu, 27-Oct-05 13:44:11 GMT Content-Length: 0 Keep-Alive: timeout=15, max=1000 Connection: Keep-Alive Content-Type: text/html Actual result: -- HTTP/1.x 200 OK Date: Thu, 27 Oct 2005 12:44:11 GMT Server: Apache/2.0.54 (Unix) PHP/4.4.0 X-Powered-By: PHP/4.4.0 Set-Cookie: hello=12345; expires=Thursday, 27Oct 2005 13:44:11 GMT Content-Length: 0 Keep-Alive: timeout=15, max=1000 Connection: Keep-Alive Content-Type: text/html -- Edit bug report at http://bugs.php.net/?id=34999&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34999&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34999&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34999&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34999&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34999&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34999&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34999&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34999&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34999&r=support Expected behavior: http://bugs.php.net/fix.php?id=34999&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34999&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34999&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34999&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34999&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34999&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34999&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34999&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34999&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34999&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34999&r=mysqlcfg
#34515 [Com]: mysqli_fetch_assoc crashes application
ID: 34515
Comment by: mark at tranchant dot plus dot com
Reported By: jaba at inbox dot lv
Status: Feedback
Bug Type: MySQLi related
Operating System: Debian GNU/Linux
PHP Version: 5.0.5
New Comment:
I've just written a quick C program using the MySQL C API and can
confirm that mysql_fetch_fields() works fine. The problem does appear
to be with the PHP code. I'll keep looking.
Previous Comments:
[2005-10-27 13:09:52] mark at tranchant dot plus dot com
Not easily, no. I'm not set up for external users. If it would really
help, I could try. I've done some more digging:
In ext/mysqli/mysqli.c, there is the following code:
line 653:
if (fetchtype & MYSQLI_ASSOC) {
fields = mysql_fetch_fields(result);
}
line 677:
if (fetchtype & MYSQLI_ASSOC) {
if (fetchtype & MYSQLI_NUM) {
ZVAL_ADDREF(res);
}
add_assoc_zval(return_value, fields[i].name, res);
}
line 687:
if (fetchtype & MYSQLI_ASSOC) {
add_assoc_null(return_value, fields[i].name);
}
If I change the fields[i].name argument to "hello", the offending
functions then work. I successfully used fetch_array with MYSQLI_BOTH,
and $array['hello'] referred to the last element in the fetched array.
It seems as though the call to mysql_fetch_fields (part of the MySQL
API) is failing, which is not being detected by the PHP code. More
soon...
[2005-10-27 12:34:42] [EMAIL PROTECTED]
Is there any chance to get an account on this server?
[2005-10-27 12:29:06] mark at tranchant dot plus dot com
Yeah, I was right. Latest CVS snapshot (php5-STABLE-200510270836) does
not fix the issue.
[2005-10-27 12:05:40] mark at tranchant dot plus dot com
In fact, any function that tries to do the assoc thing fails:
fetch_object fails, as does fetch_array with a resulttype of
MYSQLI_ASSOC or MYSQLI_BOTH. fetch_array works when called with
MYSQLI_NUM.
I'm just compiling the latest CVS snapshot, although the diff 'twixt
5.05's ext/mysqli directory and the CVS one doesn't give me much
hope...
[2005-10-27 11:15:40] mark at tranchant dot plus dot com
I have the same problem. System is self-compiled PHP-5.05 and binary
distribution of MySQL-5.0.13, running on self-compiled Apache 2.0.55 on
x86 Linux.
mysqli_fetch_row() works as advertised, but mysqli_fetch_assoc() fails
silently, both called procedurally or in OO style.
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/34515
--
Edit this bug report at http://bugs.php.net/?id=34515&edit=1
#34955 [Fbk->Opn]: PEAR install fails
ID: 34955 User updated by: squasar at eternalviper dot net Reported By: squasar at eternalviper dot net -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: Mac OS X 10.4.2/Darwin 8.2.0 PHP Version: 5.1.0RC3 Assigned To: cellog New Comment: No; PEAR does not install. As far as I can tell, install-pear- nozlib.phar never runs at all; php parses it and spits out 800K worth of ? characters. Previous Comments: [2005-10-27 05:29:23] [EMAIL PROTECTED] I can't reproduce this on gentoo linux. Does PEAR actually install? [2005-10-22 11:50:54] [EMAIL PROTECTED] Greg, check it out please. [2005-10-22 05:58:17] squasar at eternalviper dot net Description: The "Installing PEAR environment" phase of the "make install" command results in several pages of garbage output and no installed PEAR. The error occurs when make attempts to run the install-pear-nozlib.phar script. Reproduce code: --- $ ./buildconf --force $ ./configure --prefix=/usr --with-apxs --enable-cli --disable-short-tags --with-zlib --with-bz2 --enable-ftp --with-iconv --enable-mbstring --with-mysql=/usr --enable-sockets --enable-debug --enable-simplexml --with-xsl=/usr --with-curl=/usr --with-curlwrappers --enable-bcmath --with-gmp=/usr/local --with-gd --with-freetype-dir=/usr/X11R6 --enable-gd-native-ttf --with-imap=/usr/local/imap --with-imap-ssl=/usr --with-xmlrpc --with-xml-dir=/usr --with-expat-dir=/usr --with-iconv-dir=/usr --with-mysqli=/usr/bin/mysql_config --with-pdo-mysql=/usr --with-embedded-mysqli --enable-maintainer-zts --enable-zend-multibyte --enable-memory-limit --with-svn=/usr $ make -j 3 $ sudo make install Expected result: Installing PHP SAPI module: apache [activating module `php5' in /etc/httpd/httpd.conf] cp libs/libphp5.so /usr/libexec/httpd/libphp5.so chmod 755 /usr/libexec/httpd/libphp5.so cp /etc/httpd/httpd.conf /etc/httpd/httpd.conf.bak cp /etc/httpd/httpd.conf.new /etc/httpd/httpd.conf rm /etc/httpd/httpd.conf.new Installing PHP CLI binary:/usr/bin/ Installing PHP CLI man page: /usr/man/man1/ Installing build environment: /usr/lib/php/build/ Installing header files: /usr/include/php/ Installing helper programs: /usr/bin/ program: phpize program: php-config Installing man pages: /usr/man/man1/ page: phpize.1 page: php-config.1 Installing PEAR environment: /usr/lib/php/ Installing PDO headers: /usr/include/php/ext/pdo/ Actual result: -- Installing PHP SAPI module: apache [activating module `php5' in /etc/httpd/httpd.conf] cp libs/libphp5.so /usr/libexec/httpd/libphp5.so chmod 755 /usr/libexec/httpd/libphp5.so cp /etc/httpd/httpd.conf /etc/httpd/httpd.conf.bak cp /etc/httpd/httpd.conf.new /etc/httpd/httpd.conf rm /etc/httpd/httpd.conf.new Installing PHP CLI binary:/usr/bin/ Installing PHP CLI man page: /usr/man/man1/ Installing build environment: /usr/lib/php/build/ Installing header files: /usr/include/php/ Installing helper programs: /usr/bin/ program: phpize program: php-config Installing man pages: /usr/man/man1/ page: phpize.1 page: php-config.1 Installing PEAR environment: /usr/lib/php/ ???/* this continues for exactly 821228 characters total */???Installing PDO headers: /usr/include/php/ext/pdo/ -- Edit this bug report at http://bugs.php.net/?id=34955&edit=1
#34515 [Com]: mysqli_fetch_assoc crashes application
ID: 34515
Comment by: mark at tranchant dot plus dot com
Reported By: jaba at inbox dot lv
Status: Feedback
Bug Type: MySQLi related
Operating System: Debian GNU/Linux
PHP Version: 5.0.5
New Comment:
Not easily, no. I'm not set up for external users. If it would really
help, I could try. I've done some more digging:
In ext/mysqli/mysqli.c, there is the following code:
line 653:
if (fetchtype & MYSQLI_ASSOC) {
fields = mysql_fetch_fields(result);
}
line 677:
if (fetchtype & MYSQLI_ASSOC) {
if (fetchtype & MYSQLI_NUM) {
ZVAL_ADDREF(res);
}
add_assoc_zval(return_value, fields[i].name, res);
}
line 687:
if (fetchtype & MYSQLI_ASSOC) {
add_assoc_null(return_value, fields[i].name);
}
If I change the fields[i].name argument to "hello", the offending
functions then work. I successfully used fetch_array with MYSQLI_BOTH,
and $array['hello'] referred to the last element in the fetched array.
It seems as though the call to mysql_fetch_fields (part of the MySQL
API) is failing, which is not being detected by the PHP code. More
soon...
Previous Comments:
[2005-10-27 12:34:42] [EMAIL PROTECTED]
Is there any chance to get an account on this server?
[2005-10-27 12:29:06] mark at tranchant dot plus dot com
Yeah, I was right. Latest CVS snapshot (php5-STABLE-200510270836) does
not fix the issue.
[2005-10-27 12:05:40] mark at tranchant dot plus dot com
In fact, any function that tries to do the assoc thing fails:
fetch_object fails, as does fetch_array with a resulttype of
MYSQLI_ASSOC or MYSQLI_BOTH. fetch_array works when called with
MYSQLI_NUM.
I'm just compiling the latest CVS snapshot, although the diff 'twixt
5.05's ext/mysqli directory and the CVS one doesn't give me much
hope...
[2005-10-27 11:15:40] mark at tranchant dot plus dot com
I have the same problem. System is self-compiled PHP-5.05 and binary
distribution of MySQL-5.0.13, running on self-compiled Apache 2.0.55 on
x86 Linux.
mysqli_fetch_row() works as advertised, but mysqli_fetch_assoc() fails
silently, both called procedurally or in OO style.
[2005-09-23 01:00:02] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
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/34515
--
Edit this bug report at http://bugs.php.net/?id=34515&edit=1
#34515 [NoF->Fbk]: mysqli_fetch_assoc crashes application
ID: 34515 Updated by: [EMAIL PROTECTED] Reported By: jaba at inbox dot lv -Status: No Feedback +Status: Feedback Bug Type: MySQLi related Operating System: Debian GNU/Linux PHP Version: 5.0.5 New Comment: Is there any chance to get an account on this server? Previous Comments: [2005-10-27 12:29:06] mark at tranchant dot plus dot com Yeah, I was right. Latest CVS snapshot (php5-STABLE-200510270836) does not fix the issue. [2005-10-27 12:05:40] mark at tranchant dot plus dot com In fact, any function that tries to do the assoc thing fails: fetch_object fails, as does fetch_array with a resulttype of MYSQLI_ASSOC or MYSQLI_BOTH. fetch_array works when called with MYSQLI_NUM. I'm just compiling the latest CVS snapshot, although the diff 'twixt 5.05's ext/mysqli directory and the CVS one doesn't give me much hope... [2005-10-27 11:15:40] mark at tranchant dot plus dot com I have the same problem. System is self-compiled PHP-5.05 and binary distribution of MySQL-5.0.13, running on self-compiled Apache 2.0.55 on x86 Linux. mysqli_fetch_row() works as advertised, but mysqli_fetch_assoc() fails silently, both called procedurally or in OO style. [2005-09-23 01:00:02] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2005-09-15 17:18:57] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip 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/34515 -- Edit this bug report at http://bugs.php.net/?id=34515&edit=1
#34515 [Com]: mysqli_fetch_assoc crashes application
ID: 34515
Comment by: mark at tranchant dot plus dot com
Reported By: jaba at inbox dot lv
Status: No Feedback
Bug Type: MySQLi related
Operating System: Debian GNU/Linux
PHP Version: 5.0.5
New Comment:
Yeah, I was right. Latest CVS snapshot (php5-STABLE-200510270836) does
not fix the issue.
Previous Comments:
[2005-10-27 12:05:40] mark at tranchant dot plus dot com
In fact, any function that tries to do the assoc thing fails:
fetch_object fails, as does fetch_array with a resulttype of
MYSQLI_ASSOC or MYSQLI_BOTH. fetch_array works when called with
MYSQLI_NUM.
I'm just compiling the latest CVS snapshot, although the diff 'twixt
5.05's ext/mysqli directory and the CVS one doesn't give me much
hope...
[2005-10-27 11:15:40] mark at tranchant dot plus dot com
I have the same problem. System is self-compiled PHP-5.05 and binary
distribution of MySQL-5.0.13, running on self-compiled Apache 2.0.55 on
x86 Linux.
mysqli_fetch_row() works as advertised, but mysqli_fetch_assoc() fails
silently, both called procedurally or in OO style.
[2005-09-23 01:00:02] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2005-09-15 17:18:57] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
[2005-09-15 17:12:54] jaba at inbox dot lv
Description:
I am developing on Windows XP but the application production version is
supposed to be on Debian. Seems like debian MySQLi is not working
properly. I can use mysqli_fetch_row or $result->fetch_row, but
whenever I use $result->fetch_assoc() or mysqli_fetch_assoc($result) on
the same result, the application crashes and I receive no output at all.
Reproduce code:
---
query($query)) {
while ($row = $result->fetch_assoc()) {
echo '';
print_r($row);
echo '';
}
$result->close();
}
$mysqli->close();
?>
Expected result:
string representation of associated arrays of table rows
Actual result:
--
nothing. application dies whenever you call mysqli_fetch_assoc
--
Edit this bug report at http://bugs.php.net/?id=34515&edit=1
#34515 [Com]: mysqli_fetch_assoc crashes application
ID: 34515
Comment by: mark at tranchant dot plus dot com
Reported By: jaba at inbox dot lv
Status: No Feedback
Bug Type: MySQLi related
Operating System: Debian GNU/Linux
PHP Version: 5.0.5
New Comment:
In fact, any function that tries to do the assoc thing fails:
fetch_object fails, as does fetch_array with a resulttype of
MYSQLI_ASSOC or MYSQLI_BOTH. fetch_array works when called with
MYSQLI_NUM.
I'm just compiling the latest CVS snapshot, although the diff 'twixt
5.05's ext/mysqli directory and the CVS one doesn't give me much
hope...
Previous Comments:
[2005-10-27 11:15:40] mark at tranchant dot plus dot com
I have the same problem. System is self-compiled PHP-5.05 and binary
distribution of MySQL-5.0.13, running on self-compiled Apache 2.0.55 on
x86 Linux.
mysqli_fetch_row() works as advertised, but mysqli_fetch_assoc() fails
silently, both called procedurally or in OO style.
[2005-09-23 01:00:02] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2005-09-15 17:18:57] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
[2005-09-15 17:12:54] jaba at inbox dot lv
Description:
I am developing on Windows XP but the application production version is
supposed to be on Debian. Seems like debian MySQLi is not working
properly. I can use mysqli_fetch_row or $result->fetch_row, but
whenever I use $result->fetch_assoc() or mysqli_fetch_assoc($result) on
the same result, the application crashes and I receive no output at all.
Reproduce code:
---
query($query)) {
while ($row = $result->fetch_assoc()) {
echo '';
print_r($row);
echo '';
}
$result->close();
}
$mysqli->close();
?>
Expected result:
string representation of associated arrays of table rows
Actual result:
--
nothing. application dies whenever you call mysqli_fetch_assoc
--
Edit this bug report at http://bugs.php.net/?id=34515&edit=1
#34978 [Opn]: php out of memory or segmentation fault while installing sugarcrm 3.5.1a
ID: 34978 Updated by: [EMAIL PROTECTED] Reported By: cdc at ccicon dot com Status: Open Bug Type: Reproducible crash Operating System: linux i386 PHP Version: 5.0.5 New Comment: I can't say the exact point of failure (though its due to how the objects are linked to each other), but I recently had to get a highly modified version of this running under 5.1 and it was falling into infinite loops. Had to disable the ze1.compatibility_mode, remove the majority of explicit reference usage (xxx = & object) and use some explcit clone calls in spots. Runs stable after those changes, so not sure if this is just a PHP compatbility issue. Previous Comments: [2005-10-26 21:00:22] cdc at ccicon dot com >From the application logs, it is apparent that many hundreds, even thousands of lines of code are executing successfully after the post before this out of memory condition occurs. I have not yet been able to trace the exact code location as I cannot step the code in my Zend Studios environment using php 5.1. It appears the the code may be dying on either and array_merge or in a mysql call. I will roll back to php 5.0.5, which I can step in the Zend debugger, and attempt to isolate the exact section of code which is generating these errors. If I can locate it, I can perhaps write a small test script to reproduce the error under the CVS snapshot release. This will likely take me a day or two to complete. Thanks for your continued attention to this problem. TTYL CDC [2005-10-26 17:10:04] [EMAIL PROTECTED] Can you create some sort of a simple test case? For example if you pass all get/post/cookie data from the failing request to script do you get the same error? [2005-10-26 16:43:04] cdc at ccicon dot com I realize that a general out of memory condition is not a bug. However, this appears to be some kind of race condition that is consumming memory. This problem in new since version 5.0.4. The same code runs fine under 5.0.4 but generates this race condition in 5.0.5 and newer. As you can see from the error message below, I already have the memlimit set at 64M. I started at 16. It makes no difference where I have it set, the race condition consumes all available memory and fails with an out of memory error. I will attempt to isolate the code in sugar which is resulting in the race condition, however, the fact remains that this code runs fine under 5.0.4 and does not run under new versions. [2005-10-26 16:35:53] [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. Out of memory is not a bug in PHP, it simply means the memory limit needs to be increased. Try setting it to 20 megs and see if that solves the problem. [2005-10-26 06:38:36] cdc at ccicon dot com I have tested this latest snap shot. Like the previous 5.1RC4 snap shot, the installer phase completes successfully, however, first login results in an out of memory error as follows: ( Fatal error: Allowed memory size of 67108864 bytes exhausted at /usr/local/apache_src/php5-200510260230/Zend/zend_hash.c:242 (tried to allocate 58 bytes) in /home/www/dev/htdocs/sugarsuite-3.5.1a/data/SugarBean.php on line 1087) This occurs with register_long_arrays=on. Unlike the previous snapshot, which segfaulted when register_long_arrays=off, this one generates the same out of memory error regardless of the register_long_arrays setting. As this drop is not segfaulting I'm not sure how to provide a backtrace of this problem. Please advise. TTYL CDC 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/34978 -- Edit this bug report at http://bugs.php.net/?id=34978&edit=1
#34904 [Bgs->Opn]: Relocation error in libphp5.so when starting Apache2
ID: 34904 User updated by: sean dot healey at bayernlb dot co dot uk Reported By: sean dot healey at bayernlb dot co dot uk -Status: Bogus +Status: Open Bug Type: Sybase-ct (ctlib) related Operating System: Solaris 8 PHP Version: 5.0.5 New Comment: Whoah! Please don't be misled by the configure script I submitted in this bug report - the LDFLAGS and CPPFLAGS variables were set during my attempts to work around the problem because I originally thought that the build was picking up the wrong libtcl.so. I have since verified that the only copies of this library on my system are under the Sybase paths. It does appear that the wrong libintl.so library is being picked up - it should be using the one under the Sybase path, but is ignoring it and using the one under /usr/lib instead. I have tried this build against both the Sybase 12.0 and 12.5 client libraries with identical results. My original configure script is: #!/usr/bin/sh DSQUERY=fx_dbserver2_ds SYBASE=/dpkg/sybase/sybase12_5 SYBASE_OCS=OCS-12_5 LD_LIBRARY_PATH=$SYBASE/$SYBASE_OCS/lib:/usr/local/lib:$LD_LIBRARY_PATH PATH=/usr/ccs/bin:$PATH export DSQUERY SYBASE SYBASE_OCS LD_LIBRARY_PATH PATH cd php-5.0.5 ./configure \ --prefix=/usr/local/php \ --with-apxs2=/usr/local/apache2/bin/apxs \ --with-sybase-ct=$SYBASE/$SYBASE_OCS \ --without-bz2 This produces a libphp5.so which is linked as follows: ldd /usr/local/apache2/modules/libphp5.so libtcl.so => /dpkg/sybase/sybase12_5/OCS-12_5/lib/libtcl.so libintl.so.1 => /usr/lib/libintl.so.1 libcomn.so => /dpkg/sybase/sybase12_5/OCS-12_5/lib/libcomn.so libct.so => /dpkg/sybase/sybase12_5/OCS-12_5/lib/libct.so libcs.so => /dpkg/sybase/sybase12_5/OCS-12_5/lib/libcs.so libresolv.so.2 =>/usr/lib/libresolv.so.2 libm.so.1 => /usr/lib/libm.so.1 libdl.so.1 =>/usr/lib/libdl.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libsocket.so.1 =>/usr/lib/libsocket.so.1 libz.so.1 => /usr/lib/libz.so.1 libxml2.so.2 => /usr/local/lib/libxml2.so.2 libiconv.so.2 => /usr/local/lib/libiconv.so.2 libc.so.1 => /usr/lib/libc.so.1 libmp.so.2 =>/usr/lib/libmp.so.2 libpthread.so.1 => /usr/lib/libpthread.so.1 libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 /usr/platform/SUNW,Ultra-80/lib/libc_psr.so.1 libthread.so.1 =>/usr/lib/libthread.so.1 NOTE that the reference to libintl is still linked to the wrong library. I have investigated further and found that libintl.so.1 doesn't exist under the Sybase path - only libintl.so is found there. I need to somehow force the build to pick up the Sybase library instead of the Solaris library. A solved case on the Sybase site mentions that the Solaris library /usr/lib/libintl.so.1 has nothing to do with the Sybase library of the same name, which is possibly why the object not found error since my build is linking to the wrong library! Previous Comments: [2005-10-26 17:43:50] [EMAIL PROTECTED] Don't try outsmarting the configure. User error -> not PHP bug. [2005-10-18 11:03:24] sean dot healey at bayernlb dot co dot uk Description: I am getting the following error when trying to start Apache2 with the PHP plugin configured: # ./apachectl start Syntax error on line 232 of /usr/local/apache2/conf/httpd.conf: Cannot load /usr/local/apache2/modules/libphp5.so into server: ld.so.1: /usr/local/apache2/bin/httpd: fatal: relocation error: file /dpkg/sybase/OCS-12_0/lib/libtcl.so: symbol comn_free: referenced symbol not found When built without Sybase client library, the plugin starts up just fine. The php module DOES appear to be linked against the correct copy of libtcl.so - here are the without-sybase and with-sybase ldd outputs: # ldd libphp5.so.without_sybase libresolv.so.2 =>/usr/lib/libresolv.so.2 libm.so.1 => /usr/lib/libm.so.1 libdl.so.1 =>/usr/lib/libdl.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libsocket.so.1 =>/usr/lib/libsocket.so.1 libz.so.1 => /usr/lib/libz.so.1 libxml2.so.2 => /usr/local/lib/libxml2.so.2 libiconv.so.2 => /usr/local/lib/libiconv.so.2 libc.so.1 => /usr/lib/libc.so.1 libmp.so.2 =>/usr/lib/libmp.so.2 libpthread.so.1 => /usr/lib/libpthread.so.1 libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 /usr/platform/SUNW,Ultra-80/lib/libc_psr.so.1 libthread.so.1 =>/usr/lib/libthread.so.1 # ldd libphp5.so libtcl.so => /dpkg/sybase/sybase12_5/OCS-12_5/lib/libtcl.so libintl.so.1 => /usr/lib/libintl.so.1 libcomn.so => /dpkg/sy
#34515 [Com]: mysqli_fetch_assoc crashes application
ID: 34515
Comment by: mark at tranchant dot plus dot com
Reported By: jaba at inbox dot lv
Status: No Feedback
Bug Type: MySQLi related
Operating System: Debian GNU/Linux
PHP Version: 5.0.5
New Comment:
I have the same problem. System is self-compiled PHP-5.05 and binary
distribution of MySQL-5.0.13, running on self-compiled Apache 2.0.55 on
x86 Linux.
mysqli_fetch_row() works as advertised, but mysqli_fetch_assoc() fails
silently, both called procedurally or in OO style.
Previous Comments:
[2005-09-23 01:00:02] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2005-09-15 17:18:57] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
[2005-09-15 17:12:54] jaba at inbox dot lv
Description:
I am developing on Windows XP but the application production version is
supposed to be on Debian. Seems like debian MySQLi is not working
properly. I can use mysqli_fetch_row or $result->fetch_row, but
whenever I use $result->fetch_assoc() or mysqli_fetch_assoc($result) on
the same result, the application crashes and I receive no output at all.
Reproduce code:
---
query($query)) {
while ($row = $result->fetch_assoc()) {
echo '';
print_r($row);
echo '';
}
$result->close();
}
$mysqli->close();
?>
Expected result:
string representation of associated arrays of table rows
Actual result:
--
nothing. application dies whenever you call mysqli_fetch_assoc
--
Edit this bug report at http://bugs.php.net/?id=34515&edit=1
#34998 [Opn]: zend.ze1_compatibility_mode doesn't implict clone when passed in array
ID: 34998 User updated by: jason at jasonjustman dot com Reported By: jason at jasonjustman dot com Status: Open Bug Type: Scripting Engine problem Operating System: irrelv PHP Version: 5CVS-2005-10-27 (snap) New Comment: PHP Version 5.1.0RC4-dev Oct 27 2005 08:24:52 Previous Comments: [2005-10-27 10:12:02] jason at jasonjustman dot com Description: Again, with zend.ze1_compatibility_mode, it fails to properly clone objects when calling as an argument for the array() function. This BC break is getting annoying... Reproduce code: --- value = 5; $single_container[1] = $x; $double_container[1] = array($x); $x->value = 10; $single_container[2] = $x; $double_container[2] = array($x); $x->value = 15; $single_container[3] = $x; $double_container[3] = array($x); print_r($single_container); print_r($double_container); Expected result: //single Array ( [1] => base_object Object ( [value] => 5 ) [2] => base_object Object ( [value] => 10 ) [3] => base_object Object ( [value] => 15 ) ) //double, values are correct Array ( [1] => Array ( [0] => base_object Object ( [value] => 5 ) ) [2] => Array ( [0] => base_object Object ( [value] => 10 ) ) [3] => Array ( [0] => base_object Object ( [value] => 15 ) ) ) Actual result: -- //single Array ( [1] => base_object Object ( [value] => 5 ) [2] => base_object Object ( [value] => 10 ) [3] => base_object Object ( [value] => 15 ) ) //double - values are incorrect Array ( [1] => Array ( [0] => base_object Object ( [value] => 15 ) ) [2] => Array ( [0] => base_object Object ( [value] => 15 ) ) [3] => Array ( [0] => base_object Object ( [value] => 15 ) ) ) -- Edit this bug report at http://bugs.php.net/?id=34998&edit=1
#34998 [NEW]: zend.ze1_compatibility_mode doesn't implict clone when passed in array
From: jason at jasonjustman dot com Operating system: irrelv PHP version: 5CVS-2005-10-27 (snap) PHP Bug Type: Scripting Engine problem Bug description: zend.ze1_compatibility_mode doesn't implict clone when passed in array Description: Again, with zend.ze1_compatibility_mode, it fails to properly clone objects when calling as an argument for the array() function. This BC break is getting annoying... Reproduce code: --- value = 5; $single_container[1] = $x; $double_container[1] = array($x); $x->value = 10; $single_container[2] = $x; $double_container[2] = array($x); $x->value = 15; $single_container[3] = $x; $double_container[3] = array($x); print_r($single_container); print_r($double_container); Expected result: //single Array ( [1] => base_object Object ( [value] => 5 ) [2] => base_object Object ( [value] => 10 ) [3] => base_object Object ( [value] => 15 ) ) //double, values are correct Array ( [1] => Array ( [0] => base_object Object ( [value] => 5 ) ) [2] => Array ( [0] => base_object Object ( [value] => 10 ) ) [3] => Array ( [0] => base_object Object ( [value] => 15 ) ) ) Actual result: -- //single Array ( [1] => base_object Object ( [value] => 5 ) [2] => base_object Object ( [value] => 10 ) [3] => base_object Object ( [value] => 15 ) ) //double - values are incorrect Array ( [1] => Array ( [0] => base_object Object ( [value] => 15 ) ) [2] => Array ( [0] => base_object Object ( [value] => 15 ) ) [3] => Array ( [0] => base_object Object ( [value] => 15 ) ) ) -- Edit bug report at http://bugs.php.net/?id=34998&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34998&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34998&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34998&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34998&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34998&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34998&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34998&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34998&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34998&r=support Expected behavior: http://bugs.php.net/fix.php?id=34998&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34998&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34998&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34998&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34998&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34998&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34998&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34998&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34998&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34998&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34998&r=mysqlcfg
