#35465 [Asn-Bgs]: link error Text relocation remains
ID: 35465
Updated by: [EMAIL PROTECTED]
Reported By: rusty at socrates dot berkeley dot edu
-Status: Assigned
+Status: Bogus
Bug Type: Compile Failure
Operating System: solaris 9
PHP Version: 5.1.1
Assigned To: sniper
New Comment:
This is the expected failure from trying to link non-PIC code into a
shared library on most platforms. If you really insist on using a
static MySQL library you must rebuild it with -fPIC in CFLAGS.
If it worked previously I'd guess it was only because the static
libmysql.a wasn't being found.
Previous Comments:
[2005-11-29 23:35:03] rusty at socrates dot berkeley dot edu
Yes, almost all of my add-on libraries are .a files because long ago I
used to have problem with .so ones. Plus, I like to find out about any
missing symbols at compile time, not run time, which was part of the
problem I used to have.
[2005-11-29 22:58:14] [EMAIL PROTECTED]
See also bug #35475
[2005-11-29 17:19:13] rusty at socrates dot berkeley dot edu
Yes, it compiles with
./configure --disable-all --with-apxs2=/${WWWROOT}/bin/apxs
[2005-11-29 09:25:56] [EMAIL PROTECTED]
Does this work:
# rm config.cache
# ./configure --disable-all --with-apxs2=/${WWWROOT}/bin/apxs
# make clean ; make
Also you shouldn't need to use these options because they either don't
even exist or configure handles them for you automatically:
--enable-inline-optimization (it's enabled by default)
--enable-libgcc (detected automatically when needed)
--enable-trans-sid (has not existed for years)
--with-tsrm-pthreads (detected automatically)
[2005-11-29 03:17:47] rusty at socrates dot berkeley dot edu
Description:
At the final linking stage I get thousands of lines like the following
(at the end of this message). My configure wrapper shell script is
configure \
--prefix=${WWWROOT} \
--enable-bcmath \
--enable-inline-optimization \
--enable-libgcc \
--enable-track-vars \
--enable-trans-sid \
--with-apxs2=/${WWWROOT}/bin/apxs \
--with-config-file-path=${WWWROOT}/conf \
--with-gmp \
--with-ldap=${LOCAL} \
--with-mysql=${MYSQLROOT} \
--with-openssl=${LOCAL} \
--with-tsrm-pthreads
With php 5.0.5 it compiles without a squeek.
Here's the start of the error output; thousands of lines like this
(about 94,000) for many/all of the libraries:
Text relocation remains referenced
against symbol offset in file
unknown 0x570
/local_a/servers/mysql/lib/mysql/libmysqlclient.a(libmysql.o)
unknown 0x574
/local_a/servers/mysql/lib/mysql/libmysqlclient.a(libmysql.o)
unknown 0x578
/local_a/servers/mysql/lib/mysql/libmysqlclient.a(libmysql.o)
unknown 0x57c
/local_a/servers/mysql/lib/mysql/libmysqlclient.a(libmysql.o)
unknown 0x580
/local_a/servers/mysql/lib/mysql/libmysqlclient.a(libmysql.o)
--
Edit this bug report at http://bugs.php.net/?id=35465edit=1
#35482 [Opn-Fbk]: Bad performance of filesystem functions
ID: 35482
Updated by: [EMAIL PROTECTED]
Reported By: tobias-bender at web dot de
-Status: Open
+Status: Feedback
Bug Type: Filesystem function related
Operating System: Windows XP Professional
PHP Version: 5.1.1
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.
Can't reproduce on Linux.
Previous Comments:
[2005-11-30 01:25:57] tobias-bender at web dot de
Description:
All filesystem functions got much slower with PHP 5.x.
With short relative paths PHP 4 is about twice as fast as PHP 5. PHP 5
is nearly 10 times slower when using absolute paths compared to PHP 4.
Reproduce code:
---
function getMicrotime(){
list($usec, $sec) = explode(' ', microtime());
return ((float)$usec + (float)$sec);
}
$iTime = getMicrotime();
$rHandle = opendir('C:/Apache2/htdocs/phpXplorer/test/vollvoll');
while (false !== ($sName = readdir($rHandle))) {
if (is_dir('C:/Apache2/htdocs/phpXplorer/test/vollvoll/' . $sName)){
echo 'C:/Apache2/htdocs/phpXplorer/test/vollvoll/' . $sName .
'br/';
}
}
echo getMicrotime() - $iTime;
--
Edit this bug report at http://bugs.php.net/?id=35482edit=1
#35465 [Bgs]: link error Text relocation remains
ID: 35465
Updated by: [EMAIL PROTECTED]
Reported By: rusty at socrates dot berkeley dot edu
Status: Bogus
Bug Type: Compile Failure
Operating System: solaris 9
PHP Version: 5.1.1
Assigned To: sniper
New Comment:
Joe, I agree, this is most likely not PHP issue, but I'm still able to
reproduce it on Solaris 8 and -fPIC doesn't help.
Previous Comments:
[2005-11-30 09:46:26] [EMAIL PROTECTED]
This is the expected failure from trying to link non-PIC code into a
shared library on most platforms. If you really insist on using a
static MySQL library you must rebuild it with -fPIC in CFLAGS.
If it worked previously I'd guess it was only because the static
libmysql.a wasn't being found.
[2005-11-29 23:35:03] rusty at socrates dot berkeley dot edu
Yes, almost all of my add-on libraries are .a files because long ago I
used to have problem with .so ones. Plus, I like to find out about any
missing symbols at compile time, not run time, which was part of the
problem I used to have.
[2005-11-29 22:58:14] [EMAIL PROTECTED]
See also bug #35475
[2005-11-29 17:19:13] rusty at socrates dot berkeley dot edu
Yes, it compiles with
./configure --disable-all --with-apxs2=/${WWWROOT}/bin/apxs
[2005-11-29 09:25:56] [EMAIL PROTECTED]
Does this work:
# rm config.cache
# ./configure --disable-all --with-apxs2=/${WWWROOT}/bin/apxs
# make clean ; make
Also you shouldn't need to use these options because they either don't
even exist or configure handles them for you automatically:
--enable-inline-optimization (it's enabled by default)
--enable-libgcc (detected automatically when needed)
--enable-trans-sid (has not existed for years)
--with-tsrm-pthreads (detected automatically)
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/35465
--
Edit this bug report at http://bugs.php.net/?id=35465edit=1
#35470 [Asn-Csd]: Assigning global using variable name from array doesn't function
ID: 35470
Updated by: [EMAIL PROTECTED]
Reported By: prgallier at yahoo dot com
-Status: Assigned
+Status: Closed
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5CVS-2005-11-29 (cvs)
Assigned To: dmitry
New Comment:
Fixed in CVS HEAD and PHP_5_1.
Previous Comments:
[2005-11-29 20:11:25] [EMAIL PROTECTED]
?php
function dotest()
{
$array = array(array(test, blah),array(test, blah));
$i = 0;
while ($row = $array[$i++])
{
global ${$row[0]};
${$row[0]} = $row[1];
}
}
dotest();
?
Valgrind shows several errors:
==3742== Invalid read of size 4
==3742==at 0x823AAEA: zend_fetch_dimension_address
(zend_execute.c:1092)
==3742==by 0x826DEE0: ZEND_FETCH_DIM_R_SPEC_CV_CONST_HANDLER
(zend_vm_execute.h:20390)
==3742==by 0x823B348: execute (zend_vm_execute.h:88)
==3742==by 0x823B7A9: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:222)
==3742==by 0x823E294: ZEND_DO_FCALL_SPEC_CONST_HANDLER
(zend_vm_execute.h:1578)
==3742==by 0x823B348: execute (zend_vm_execute.h:88)
==3742==by 0x8214E75: zend_execute_scripts (zend.c:1090)
==3742==by 0x81D43AD: php_execute_script (main.c:1704)
==3742==by 0x828025D: main (php_cli.c:1039)
etc.
[2005-11-29 19:58:50] prgallier at yahoo dot com
The following generates a segfault on my system:
function dotest()
{
$link = mysql_connect(localhost,test,test);
mysql_select_db(test);
mysql_query(CREATE TABLE config (num smallint(5) unsigned NOT NULL
auto_increment, conf varchar(20) NOT NULL default ''));
mysql_query(INSERT INTO config (conf,type) VALUES('Test1','33'));
$result = mysql_query(SELECT conf,value FROM config);
while ($row = mysql_fetch_row($result))
{
global ${$row[0]};
${$row[0]} = $row[1];
}
mysql_free_result($result);
}
dotest();
echo Test: $testbr\n;
[2005-11-29 13:09:49] [EMAIL PROTECTED]
Dmitry, can you check this out please.
[2005-11-29 11:33:26] prgallier at yahoo dot com
Oops...the expected and actual result fields are switched.
[2005-11-29 11:32:20] prgallier at yahoo dot com
Description:
The below code does not store the value 55 in the variable test as
it should, and did in PHP 5.0.5. Leaving out the global declaration
allows the output to display properly. I have also had segmentation
faults caused by similar routines, but have been unable to reproduce
this outside of the full program.
Reproduce code:
---
$x = array(test, 55);
global ${$x[0]};
${$x[0]} = $x[1];
echo Test: $testbr\n;;
Expected result:
Displays:
Test:
Actual result:
--
Should display:
Test: 55
--
Edit this bug report at http://bugs.php.net/?id=35470edit=1
#35029 [Com]: segmentation faults with multiple include virtual requests
ID: 35029 Comment by: minnoce at polito dot it Reported By: markus-php at anthill dot de Status: No Feedback Bug Type: Apache2 related Operating System: linux / solaris PHP Version: 4.4.0 New Comment: I have the same problem under this platform: - Red Hat Enterprise Linux 4 (i386) fully updated - Apache 2.0.55 compiled from sources - PHP 4.3.11 / 4.4.1 / LATEST 4.4 from CVS compiled from sources The bug is NOT present under Apache 2.0.54. Previous Comments: [2005-11-15 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-11-07 23:43:06] markus-php at anthill dot de with PHP 4.4.0 I had a segmentation fault (see above). According to the backtrace the problems seems to be in the PHP code. When switching from PHP 4.4.0 to 4.4.1 the segmentation fault seems to have gone, but the result isn't ok yet. As I am not that familiar with gdb I can't really tell if it is a problem with Apache or PHP or something else. I'll make some tests during the next days and try to dig further into this. [2005-11-07 16:50:40] markus-php at anthill dot de In tests with PHP 4.4.1 under solaris I don't get the segmentation faults any more, but the SSI seems to be simply ignored now. [2005-10-31 15:47:13] markus-php at anthill dot de I tried the STABLE-200510311345 snapshot under linux and it works so far. Thanks. Could someone please point me to the changes which fixed the problem? [2005-10-31 08:08:14] [EMAIL PROTECTED] 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 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/35029 -- Edit this bug report at http://bugs.php.net/?id=35029edit=1
#35373 [Asn-Csd]: alias not allowed in this configuration
ID: 35373 Updated by: [EMAIL PROTECTED] Reported By: remi at FamilleCollet dot com -Status: Assigned +Status: Closed Bug Type: Compile Failure Operating System: HP-UX 11.11 PHP Version: 5.1.1 Assigned To: dmitry New Comment: Should be fixed in CVS HEAD and PHP_5_1. Previous Comments: [2005-11-28 17:26:44] [EMAIL PROTECTED] Assigned to the person responsible for adding this line.. :) Dmitry, simply adding !defined(HPUX) propably is the quick fix, but isn't there really no other way? [2005-11-26 08:57:04] remi at FamilleCollet dot com When runnning gmake : /bin/sh /home/sys/install/php-5.1.0/libtool --silent --preserve-dup-deps --mode=compile gcc -IZend/ -I/home/sys/install/php-5.1.0/Zend/ -DPHP_ATOM_INC -I/home/sys/install/php-5.1.0/include -I/home/sys/install/php-5.1.0/main -I/home/sys/install/php-5.1.0 -I/usr/local/include/libxml2 -I/usr/local/include -I/home/sys/install/php-5.1.0/ext/date/lib -I/usr/local/include/freetype2 -I/usr/local/imap/include -I/home/sys/install/php-5.1.0/ext/mbstring/oniguruma -I/home/sys/install/php-5.1.0/ext/mbstring/libmbfl -I/home/sys/install/php-5.1.0/ext/mbstring/libmbfl/mbfl -I/opt/mysql/include/mysql -I/oracle/app/oracle/product/8.1.7/rdbms/public -I/oracle/app/oracle/product/8.1.7/rdbms/demo -I/opt/pgsql/include -I/home/sys/install/php-5.1.0/TSRM -I/home/sys/install/php-5.1.0/Zend -D_XOPEN_SOURCE_EXTENDED -g -O2 -c /home/sys/install/php-5.1.0/Zend/zend.c -o Zend/zend.lo /home/sys/install/php-5.1.0/Zend/zend.c:1039: error: alias definitions not supported in this configuration gmake: *** [Zend/zend.lo] Error 1 [2005-11-25 20:42:14] [EMAIL PROTECTED] What was the exact error? [2005-11-25 17:39:14] remi at FamilleCollet dot com Oups, sorry, i forget this very useful information. I'm using gcc version 4.0.2 (from The Porting and Archiving Centre for HP-UX) http://hpux.connect.org.uk/hppd/hpux/Gnu/gcc-4.0.2/ [2005-11-25 12:33:59] [EMAIL PROTECTED] What compiler are you using? Which version? 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/35373 -- Edit this bug report at http://bugs.php.net/?id=35373edit=1
#35483 [Opn-Fbk]: safe_mode_exec_dir
ID: 35483 Updated by: [EMAIL PROTECTED] Reported By: marcl at vo dot lu -Status: Open +Status: Feedback Bug Type: Program Execution Operating System: Windows 2003 PHP Version: 4.4.1 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-11-30 11:58:48] marcl at vo dot lu Description: I can't execute binaries which are in safe_mode_exec_dir (safe_mode=on) I tried all variants! -- Edit this bug report at http://bugs.php.net/?id=35483edit=1
#35484 [NEW]: segmentation faults with multiple include virtual
From: minnoce at polito dot it Operating system: Linux RHEL 4 PHP version: 4.4.2RC1 PHP Bug Type: Apache2 related Bug description: segmentation faults with multiple include virtual Description: I'm compiling PHP with this configuration line: ./configure \ --prefix=/services/php-4.4-CVS \ --with-apxs2=/services/apache/bin/apxs \ --with-openssl \ --with-config-file-path=/services/httpd/conf \ --with-mysql=/usr \ --with-zlib \ --with-gd \ --with-jpeg-dir \ --with-png-dir \ --with-ldap \ --with-freetype-dir \ --with-mcrypt=/services/libmcrypt \ --with-curl \ --with-freetds=/services/freetds \ --enable-mbstring All the PHP 4.3.11, 4.4.1, 4.4-LATEST-CVS used as module under Apache 2.0.54 work fine. All the PHP 4.3.11, 4.4.1m 4.4-LATEST-CVS used as module under Apache 2.0.55 cause a segmentation fault when I try to include some PHP script with more than one Apache's include virtual (even a simple ? echo 'TEST'; ?). Examples: - test.html html body !--#include virtual=test.php -- !--#include virtual=test.php -- /body /html - test.php ? echo 'TEST'; ? With only one include virtual all works fine. With the two include virtual the Apache child process associated exit with segmentation fault after the output of the first include. -- Edit bug report at http://bugs.php.net/?id=35484edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=35484r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=35484r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=35484r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=35484r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=35484r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=35484r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=35484r=needscript Try newer version:http://bugs.php.net/fix.php?id=35484r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=35484r=support Expected behavior:http://bugs.php.net/fix.php?id=35484r=notwrong Not enough info: http://bugs.php.net/fix.php?id=35484r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=35484r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=35484r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35484r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=35484r=dst IIS Stability:http://bugs.php.net/fix.php?id=35484r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=35484r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=35484r=float No Zend Extensions: http://bugs.php.net/fix.php?id=35484r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=35484r=mysqlcfg
#35484 [Opn-Bgs]: segmentation faults with multiple include virtual
ID: 35484 Updated by: [EMAIL PROTECTED] Reported By: minnoce at polito dot it -Status: Open +Status: Bogus Bug Type: Apache2 related Operating System: Linux RHEL 4 PHP Version: 4.4.2RC1 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. See bug #35029. Previous Comments: [2005-11-30 12:31:36] minnoce at polito dot it Description: I'm compiling PHP with this configuration line: ./configure \ --prefix=/services/php-4.4-CVS \ --with-apxs2=/services/apache/bin/apxs \ --with-openssl \ --with-config-file-path=/services/httpd/conf \ --with-mysql=/usr \ --with-zlib \ --with-gd \ --with-jpeg-dir \ --with-png-dir \ --with-ldap \ --with-freetype-dir \ --with-mcrypt=/services/libmcrypt \ --with-curl \ --with-freetds=/services/freetds \ --enable-mbstring All the PHP 4.3.11, 4.4.1, 4.4-LATEST-CVS used as module under Apache 2.0.54 work fine. All the PHP 4.3.11, 4.4.1m 4.4-LATEST-CVS used as module under Apache 2.0.55 cause a segmentation fault when I try to include some PHP script with more than one Apache's include virtual (even a simple ? echo 'TEST'; ?). Examples: - test.html html body !--#include virtual=test.php -- !--#include virtual=test.php -- /body /html - test.php ? echo 'TEST'; ? With only one include virtual all works fine. With the two include virtual the Apache child process associated exit with segmentation fault after the output of the first include. -- Edit this bug report at http://bugs.php.net/?id=35484edit=1
#35029 [NoF-Fbk]: segmentation faults with multiple include virtual requests
ID: 35029 Updated by: [EMAIL PROTECTED] Reported By: markus-php at anthill dot de -Status: No Feedback +Status: Feedback Bug Type: Apache2 related Operating System: linux / solaris PHP Version: 4.4.0 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip Previous Comments: [2005-11-30 11:28:25] minnoce at polito dot it I have the same problem under this platform: - Red Hat Enterprise Linux 4 (i386) fully updated - Apache 2.0.55 compiled from sources - PHP 4.3.11 / 4.4.1 / LATEST 4.4 from CVS compiled from sources The bug is NOT present under Apache 2.0.54. [2005-11-15 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-11-07 23:43:06] markus-php at anthill dot de with PHP 4.4.0 I had a segmentation fault (see above). According to the backtrace the problems seems to be in the PHP code. When switching from PHP 4.4.0 to 4.4.1 the segmentation fault seems to have gone, but the result isn't ok yet. As I am not that familiar with gdb I can't really tell if it is a problem with Apache or PHP or something else. I'll make some tests during the next days and try to dig further into this. [2005-11-07 16:50:40] markus-php at anthill dot de In tests with PHP 4.4.1 under solaris I don't get the segmentation faults any more, but the SSI seems to be simply ignored now. [2005-10-31 15:47:13] markus-php at anthill dot de I tried the STABLE-200510311345 snapshot under linux and it works so far. Thanks. Could someone please point me to the changes which fixed 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/35029 -- Edit this bug report at http://bugs.php.net/?id=35029edit=1
#35485 [NEW]: foreach is not working correctly
From: vma1 at abv dot bg
Operating system: Slackware 10.1, kernel 2.4.31
PHP version: 5CVS-2005-11-30 (snap)
PHP Bug Type: Arrays related
Bug description: foreach is not working correctly
Description:
When using foreach($arr as $index = $item), the $item reference does not
always allow a modification of the referenced element.
Reproduce code:
---
?
$items = array (array (1), array (1));
foreach ($items as $index = $one_item) {
printf (C1 IDENTICAL: %u\n, $items [$index] === $one_item);
each ($items [$index]);
printf (C2 IDENTICAL: %u\n, $items [$index] === $one_item);
$one_item = 678;
printf (C3 IDENTICAL: %u\n, $items [$index] === $one_item);
}
?
Expected result:
C1 IDENTICAL: 1
C2 IDENTICAL: 1
C3 IDENTICAL: 1
C1 IDENTICAL: 1
C2 IDENTICAL: 1
C3 IDENTICAL: 1
Actual result:
--
C1 IDENTICAL: 1
C2 IDENTICAL: 1
C3 IDENTICAL: 1
C1 IDENTICAL: 1
C2 IDENTICAL: 1
C3 IDENTICAL: 0
--
Edit bug report at http://bugs.php.net/?id=35485edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=35485r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=35485r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=35485r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=35485r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=35485r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=35485r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=35485r=needscript
Try newer version:http://bugs.php.net/fix.php?id=35485r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=35485r=support
Expected behavior:http://bugs.php.net/fix.php?id=35485r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=35485r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=35485r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=35485r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35485r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=35485r=dst
IIS Stability:http://bugs.php.net/fix.php?id=35485r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=35485r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=35485r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=35485r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=35485r=mysqlcfg
#35470 [Csd]: Assigning global using variable name from array doesn't function
ID: 35470
User updated by: prgallier at yahoo dot com
Reported By: prgallier at yahoo dot com
Status: Closed
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5CVS-2005-11-29 (cvs)
Assigned To: dmitry
New Comment:
Tested and working great here. Kudos to Dmitry!
Previous Comments:
[2005-11-30 11:10:53] [EMAIL PROTECTED]
Fixed in CVS HEAD and PHP_5_1.
[2005-11-29 20:11:25] [EMAIL PROTECTED]
?php
function dotest()
{
$array = array(array(test, blah),array(test, blah));
$i = 0;
while ($row = $array[$i++])
{
global ${$row[0]};
${$row[0]} = $row[1];
}
}
dotest();
?
Valgrind shows several errors:
==3742== Invalid read of size 4
==3742==at 0x823AAEA: zend_fetch_dimension_address
(zend_execute.c:1092)
==3742==by 0x826DEE0: ZEND_FETCH_DIM_R_SPEC_CV_CONST_HANDLER
(zend_vm_execute.h:20390)
==3742==by 0x823B348: execute (zend_vm_execute.h:88)
==3742==by 0x823B7A9: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:222)
==3742==by 0x823E294: ZEND_DO_FCALL_SPEC_CONST_HANDLER
(zend_vm_execute.h:1578)
==3742==by 0x823B348: execute (zend_vm_execute.h:88)
==3742==by 0x8214E75: zend_execute_scripts (zend.c:1090)
==3742==by 0x81D43AD: php_execute_script (main.c:1704)
==3742==by 0x828025D: main (php_cli.c:1039)
etc.
[2005-11-29 19:58:50] prgallier at yahoo dot com
The following generates a segfault on my system:
function dotest()
{
$link = mysql_connect(localhost,test,test);
mysql_select_db(test);
mysql_query(CREATE TABLE config (num smallint(5) unsigned NOT NULL
auto_increment, conf varchar(20) NOT NULL default ''));
mysql_query(INSERT INTO config (conf,type) VALUES('Test1','33'));
$result = mysql_query(SELECT conf,value FROM config);
while ($row = mysql_fetch_row($result))
{
global ${$row[0]};
${$row[0]} = $row[1];
}
mysql_free_result($result);
}
dotest();
echo Test: $testbr\n;
[2005-11-29 13:09:49] [EMAIL PROTECTED]
Dmitry, can you check this out please.
[2005-11-29 11:33:26] prgallier at yahoo dot com
Oops...the expected and actual result fields are switched.
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/35470
--
Edit this bug report at http://bugs.php.net/?id=35470edit=1
#35485 [Opn-Bgs]: foreach is not working correctly
ID: 35485
Updated by: [EMAIL PROTECTED]
Reported By: vma1 at abv dot bg
-Status: Open
+Status: Bogus
Bug Type: Arrays related
Operating System: Slackware 10.1, kernel 2.4.31
PHP Version: 5CVS-2005-11-30 (snap)
New Comment:
Do not modify array in the foreach() loop.
Previous Comments:
[2005-11-30 12:41:39] vma1 at abv dot bg
Description:
When using foreach($arr as $index = $item), the $item reference does
not always allow a modification of the referenced element.
Reproduce code:
---
?
$items = array (array (1), array (1));
foreach ($items as $index = $one_item) {
printf (C1 IDENTICAL: %u\n, $items [$index] === $one_item);
each ($items [$index]);
printf (C2 IDENTICAL: %u\n, $items [$index] === $one_item);
$one_item = 678;
printf (C3 IDENTICAL: %u\n, $items [$index] === $one_item);
}
?
Expected result:
C1 IDENTICAL: 1
C2 IDENTICAL: 1
C3 IDENTICAL: 1
C1 IDENTICAL: 1
C2 IDENTICAL: 1
C3 IDENTICAL: 1
Actual result:
--
C1 IDENTICAL: 1
C2 IDENTICAL: 1
C3 IDENTICAL: 1
C1 IDENTICAL: 1
C2 IDENTICAL: 1
C3 IDENTICAL: 0
--
Edit this bug report at http://bugs.php.net/?id=35485edit=1
#35486 [NEW]: multiple definition of `all_args_by_ref`
From: jasonlamkk at gmail dot com Operating system: Redhat PHP version: 5.1.1 PHP Bug Type: Compile Failure Bug description: multiple definition of `all_args_by_ref` Description: there are many multiple definition of occur when i compile php-5.1.1 most of them related to pdo, ext/pdo/.libs/pdo_stmt.o(.data+0x178):/tmp/php-5.1.1/ext/pdo/pdo_stmt.c:214: first defined here i choose -without-pdo-sqlite and -without-pdo-sqlite2 since they cause samiliar errors, --enable-pdo=shared cause error too Thanks and Regards Reproduce code: --- ./configure --with-apxs \ --with-curl=/usr/lib/include/curl \ --with-freetype-dir=/usr/local/lib \ --with-gd \ --with-gettext \ --with-gmp \ --with-jpeg-dir=/usr/local/lib \ --with-java=/usr/java \ --with-kerberos \ --with-mcrypt \ --with-mhash \ --with-mysql=/usr/lib,shared \ --with-readline=/usr/lib \ --with-pear \ --with-regex=php \ --with-xml \ --without-pdo-sqlite \ --without-pdo-sqlite2 \ --with-zlib \ --with-zip \ --with-openssl \ make Expected result: complete 'make' as normal Actual result: -- ... -o libphp5.la Zend/.libs/zend_builtin_functions.o(.data+0x0): In function `zend_startup_builtin_functions': /usr/local/directadmin/customapache/php-5.1.1/Zend/zend_builtin_functions.c:152: multiple definition of `first_arg_force_ref' ext/pdo/.libs/pdo_stmt.o(.data+0x0):/usr/local/directadmin/customapache/php-5.1.1/ext/pdo/pdo_stmt.c:79: first defined here Zend/.libs/zend_builtin_functions.o(.data+0x40): In function `zif_func_num_args': /usr/local/directadmin/customapache/php-5.1.1/Zend/zend_builtin_functions.c:169: multiple definition of `second_arg_force_ref' ext/pdo/.libs/pdo_stmt.o(.data+0x40):/usr/local/directadmin/customapache/php-5.1.1/ext/pdo/pdo_stmt.c:135: first defined here Zend/.libs/zend_builtin_functions.o(.data+0xa0): In function `zif_func_num_args': /usr/local/directadmin/customapache/php-5.1.1/Zend/zend_builtin_functions.c:177: multiple definition of `third_arg_force_ref' ext/pdo/.libs/pdo_stmt.o(.data+0xa0):/usr/local/directadmin/customapache/php-5.1.1/ext/pdo/pdo_stmt.c:150: first defined here Zend/.libs/zend_builtin_functions.o(.data+0x100): In function `zif_func_get_arg': /usr/local/directadmin/customapache/php-5.1.1/Zend/zend_builtin_functions.c:203: multiple definition of `fourth_arg_force_ref' ext/pdo/.libs/pdo_stmt.o(.data+0x100):/usr/local/directadmin/customapache/php-5.1.1/ext/pdo/pdo_stmt.c:174: first defined here Zend/.libs/zend_builtin_functions.o(.data+0x178): In function `zif_func_get_arg': /usr/local/directadmin/customapache/php-5.1.1/Zend/zend_builtin_functions.c:232: multiple definition of `all_args_by_ref' ext/pdo/.libs/pdo_stmt.o(.data+0x178):/usr/local/directadmin/customapache/php-5.1.1/ext/pdo/pdo_stmt.c:214: first defined here collect2: ld returned 1 exit status make: *** [libphp5.la] Error 1 -- Edit bug report at http://bugs.php.net/?id=35486edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=35486r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=35486r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=35486r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=35486r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=35486r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=35486r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=35486r=needscript Try newer version:http://bugs.php.net/fix.php?id=35486r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=35486r=support Expected behavior:http://bugs.php.net/fix.php?id=35486r=notwrong Not enough info: http://bugs.php.net/fix.php?id=35486r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=35486r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=35486r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35486r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=35486r=dst IIS Stability:http://bugs.php.net/fix.php?id=35486r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=35486r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=35486r=float No Zend Extensions: http://bugs.php.net/fix.php?id=35486r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=35486r=mysqlcfg
#35485 [Bgs-Opn]: foreach is not working correctly
ID: 35485
User updated by: vma1 at abv dot bg
Reported By: vma1 at abv dot bg
-Status: Bogus
+Status: Open
Bug Type: Arrays related
Operating System: Slackware 10.1, kernel 2.4.31
PHP Version: 5CVS-2005-11-30 (snap)
New Comment:
The array is not being modified.
Previous Comments:
[2005-11-30 12:54:27] [EMAIL PROTECTED]
Do not modify array in the foreach() loop.
[2005-11-30 12:41:39] vma1 at abv dot bg
Description:
When using foreach($arr as $index = $item), the $item reference does
not always allow a modification of the referenced element.
Reproduce code:
---
?
$items = array (array (1), array (1));
foreach ($items as $index = $one_item) {
printf (C1 IDENTICAL: %u\n, $items [$index] === $one_item);
each ($items [$index]);
printf (C2 IDENTICAL: %u\n, $items [$index] === $one_item);
$one_item = 678;
printf (C3 IDENTICAL: %u\n, $items [$index] === $one_item);
}
?
Expected result:
C1 IDENTICAL: 1
C2 IDENTICAL: 1
C3 IDENTICAL: 1
C1 IDENTICAL: 1
C2 IDENTICAL: 1
C3 IDENTICAL: 1
Actual result:
--
C1 IDENTICAL: 1
C2 IDENTICAL: 1
C3 IDENTICAL: 1
C1 IDENTICAL: 1
C2 IDENTICAL: 1
C3 IDENTICAL: 0
--
Edit this bug report at http://bugs.php.net/?id=35485edit=1
#35485 [Opn]: foreach is not working correctly
ID: 35485
User updated by: vma1 at abv dot bg
Reported By: vma1 at abv dot bg
Status: Open
Bug Type: Arrays related
Operating System: Slackware 10.1, kernel 2.4.31
PHP Version: 5CVS-2005-11-30 (snap)
New Comment:
In my previous comment I meant that no array elements are being
added/removed. Besides try removing the each() operator and behaviour
becomes correct. Something that should not happen.
Previous Comments:
[2005-11-30 13:19:05] vma1 at abv dot bg
The array is not being modified.
[2005-11-30 12:54:27] [EMAIL PROTECTED]
Do not modify array in the foreach() loop.
[2005-11-30 12:41:39] vma1 at abv dot bg
Description:
When using foreach($arr as $index = $item), the $item reference does
not always allow a modification of the referenced element.
Reproduce code:
---
?
$items = array (array (1), array (1));
foreach ($items as $index = $one_item) {
printf (C1 IDENTICAL: %u\n, $items [$index] === $one_item);
each ($items [$index]);
printf (C2 IDENTICAL: %u\n, $items [$index] === $one_item);
$one_item = 678;
printf (C3 IDENTICAL: %u\n, $items [$index] === $one_item);
}
?
Expected result:
C1 IDENTICAL: 1
C2 IDENTICAL: 1
C3 IDENTICAL: 1
C1 IDENTICAL: 1
C2 IDENTICAL: 1
C3 IDENTICAL: 1
Actual result:
--
C1 IDENTICAL: 1
C2 IDENTICAL: 1
C3 IDENTICAL: 1
C1 IDENTICAL: 1
C2 IDENTICAL: 1
C3 IDENTICAL: 0
--
Edit this bug report at http://bugs.php.net/?id=35485edit=1
#35484 [Opn-Bgs]: segmentation faults with multiple include virtual
ID: 35484 Updated by: [EMAIL PROTECTED] Reported By: minnoce at polito dot it -Status: Open +Status: Bogus Bug Type: Apache2 related Operating System: Linux RHEL 4 PHP Version: 4.4.2RC1 New Comment: Actually it wasn't even closed. Previous Comments: [2005-11-30 13:29:13] minnoce at polito dot it Please, the bug #35029 seem's to be fixed (for the user who entered) with latest PHP from CVS. But that's NOT true for me! Maybe You want to reopen the bug #35029... [2005-11-30 12:35:05] [EMAIL PROTECTED] 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. See bug #35029. [2005-11-30 12:31:36] minnoce at polito dot it Description: I'm compiling PHP with this configuration line: ./configure \ --prefix=/services/php-4.4-CVS \ --with-apxs2=/services/apache/bin/apxs \ --with-openssl \ --with-config-file-path=/services/httpd/conf \ --with-mysql=/usr \ --with-zlib \ --with-gd \ --with-jpeg-dir \ --with-png-dir \ --with-ldap \ --with-freetype-dir \ --with-mcrypt=/services/libmcrypt \ --with-curl \ --with-freetds=/services/freetds \ --enable-mbstring All the PHP 4.3.11, 4.4.1, 4.4-LATEST-CVS used as module under Apache 2.0.54 work fine. All the PHP 4.3.11, 4.4.1m 4.4-LATEST-CVS used as module under Apache 2.0.55 cause a segmentation fault when I try to include some PHP script with more than one Apache's include virtual (even a simple ? echo 'TEST'; ?). Examples: - test.html html body !--#include virtual=test.php -- !--#include virtual=test.php -- /body /html - test.php ? echo 'TEST'; ? With only one include virtual all works fine. With the two include virtual the Apache child process associated exit with segmentation fault after the output of the first include. -- Edit this bug report at http://bugs.php.net/?id=35484edit=1
#35485 [Bgs-Opn]: foreach is not working correctly
ID: 35485
User updated by: vma1 at abv dot bg
Reported By: vma1 at abv dot bg
-Status: Bogus
+Status: Open
Bug Type: Arrays related
Operating System: Slackware 10.1, kernel 2.4.31
PHP Version: 5CVS-2005-11-30 (snap)
New Comment:
So what? each() is not touching the $items array, it is touching the
$items [0], and $items [1] elements which are arrays as well.
Previous Comments:
[2005-11-30 13:30:05] [EMAIL PROTECTED]
http://php.net/each
each -- Return the current key and value pair from an array and
*advance the array cursor*
[2005-11-30 13:23:51] vma1 at abv dot bg
In my previous comment I meant that no array elements are being
added/removed. Besides try removing the each() operator and behaviour
becomes correct. Something that should not happen.
[2005-11-30 13:19:05] vma1 at abv dot bg
The array is not being modified.
[2005-11-30 12:54:27] [EMAIL PROTECTED]
Do not modify array in the foreach() loop.
[2005-11-30 12:41:39] vma1 at abv dot bg
Description:
When using foreach($arr as $index = $item), the $item reference does
not always allow a modification of the referenced element.
Reproduce code:
---
?
$items = array (array (1), array (1));
foreach ($items as $index = $one_item) {
printf (C1 IDENTICAL: %u\n, $items [$index] === $one_item);
each ($items [$index]);
printf (C2 IDENTICAL: %u\n, $items [$index] === $one_item);
$one_item = 678;
printf (C3 IDENTICAL: %u\n, $items [$index] === $one_item);
}
?
Expected result:
C1 IDENTICAL: 1
C2 IDENTICAL: 1
C3 IDENTICAL: 1
C1 IDENTICAL: 1
C2 IDENTICAL: 1
C3 IDENTICAL: 1
Actual result:
--
C1 IDENTICAL: 1
C2 IDENTICAL: 1
C3 IDENTICAL: 1
C1 IDENTICAL: 1
C2 IDENTICAL: 1
C3 IDENTICAL: 0
--
Edit this bug report at http://bugs.php.net/?id=35485edit=1
#35029 [Com]: segmentation faults with multiple include virtual requests
ID: 35029 Comment by: minnoce at polito dot it Reported By: markus-php at anthill dot de Status: Feedback Bug Type: Apache2 related Operating System: linux / solaris PHP Version: 4.4.0 New Comment: Same problem also with PHP 5.1 LATEST from CVS. Previous Comments: [2005-11-30 12:36:07] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip [2005-11-30 11:28:25] minnoce at polito dot it I have the same problem under this platform: - Red Hat Enterprise Linux 4 (i386) fully updated - Apache 2.0.55 compiled from sources - PHP 4.3.11 / 4.4.1 / LATEST 4.4 from CVS compiled from sources The bug is NOT present under Apache 2.0.54. [2005-11-15 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-11-07 23:43:06] markus-php at anthill dot de with PHP 4.4.0 I had a segmentation fault (see above). According to the backtrace the problems seems to be in the PHP code. When switching from PHP 4.4.0 to 4.4.1 the segmentation fault seems to have gone, but the result isn't ok yet. As I am not that familiar with gdb I can't really tell if it is a problem with Apache or PHP or something else. I'll make some tests during the next days and try to dig further into this. [2005-11-07 16:50:40] markus-php at anthill dot de In tests with PHP 4.4.1 under solaris I don't get the segmentation faults any more, but the SSI seems to be simply ignored now. 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/35029 -- Edit this bug report at http://bugs.php.net/?id=35029edit=1
#35488 [NEW]: serialize() segmentation fault
From: kenashkov at gmail dot com Operating system: Fedora Core 4 PHP version: 4.4.1 PHP Bug Type: Unknown/Other Function Bug description: serialize() segmentation fault Description: Segmentation fault when serializing multidimentional recursive arrays. The code below works fine with 4.3.11 (again on FC4). When the argument is passend by reference (which is deprecated): print_r(unserialize(serialize($arr1))); it is fine. Or passing a reference: print_r(unserialize(serialize($ref=$arr1))); also works. No problem with serializing just $arr1[0]=$arr; Reproduce code: --- ? $arr1[0][0] = $arr1; print_r(unserialize(serialize($arr1))); ? Expected result: Array ( [0] = Array ( [0] = Array ( [0] = Array ( [0] = Array *RECURSION* ) ) ) ) Actual result: -- Segmentation fault -- Edit bug report at http://bugs.php.net/?id=35488edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=35488r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=35488r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=35488r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=35488r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=35488r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=35488r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=35488r=needscript Try newer version:http://bugs.php.net/fix.php?id=35488r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=35488r=support Expected behavior:http://bugs.php.net/fix.php?id=35488r=notwrong Not enough info: http://bugs.php.net/fix.php?id=35488r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=35488r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=35488r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35488r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=35488r=dst IIS Stability:http://bugs.php.net/fix.php?id=35488r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=35488r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=35488r=float No Zend Extensions: http://bugs.php.net/fix.php?id=35488r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=35488r=mysqlcfg
#35486 [Opn-Bgs]: multiple definition of `all_args_by_ref`
ID: 35486 Updated by: [EMAIL PROTECTED] Reported By: jasonlamkk at gmail dot com -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: Redhat PHP Version: 5.1.1 New Comment: Try using correct configure options next time. Passing '/lib' to any option does not work. Previous Comments: [2005-11-30 13:07:34] jasonlamkk at gmail dot com Description: there are many multiple definition of occur when i compile php-5.1.1 most of them related to pdo, ext/pdo/.libs/pdo_stmt.o(.data+0x178):/tmp/php-5.1.1/ext/pdo/pdo_stmt.c:214: first defined here i choose -without-pdo-sqlite and -without-pdo-sqlite2 since they cause samiliar errors, --enable-pdo=shared cause error too Thanks and Regards Reproduce code: --- ./configure --with-apxs \ --with-curl=/usr/lib/include/curl \ --with-freetype-dir=/usr/local/lib \ --with-gd \ --with-gettext \ --with-gmp \ --with-jpeg-dir=/usr/local/lib \ --with-java=/usr/java \ --with-kerberos \ --with-mcrypt \ --with-mhash \ --with-mysql=/usr/lib,shared \ --with-readline=/usr/lib \ --with-pear \ --with-regex=php \ --with-xml \ --without-pdo-sqlite \ --without-pdo-sqlite2 \ --with-zlib \ --with-zip \ --with-openssl \ make Expected result: complete 'make' as normal Actual result: -- ... -o libphp5.la Zend/.libs/zend_builtin_functions.o(.data+0x0): In function `zend_startup_builtin_functions': /usr/local/directadmin/customapache/php-5.1.1/Zend/zend_builtin_functions.c:152: multiple definition of `first_arg_force_ref' ext/pdo/.libs/pdo_stmt.o(.data+0x0):/usr/local/directadmin/customapache/php-5.1.1/ext/pdo/pdo_stmt.c:79: first defined here Zend/.libs/zend_builtin_functions.o(.data+0x40): In function `zif_func_num_args': /usr/local/directadmin/customapache/php-5.1.1/Zend/zend_builtin_functions.c:169: multiple definition of `second_arg_force_ref' ext/pdo/.libs/pdo_stmt.o(.data+0x40):/usr/local/directadmin/customapache/php-5.1.1/ext/pdo/pdo_stmt.c:135: first defined here Zend/.libs/zend_builtin_functions.o(.data+0xa0): In function `zif_func_num_args': /usr/local/directadmin/customapache/php-5.1.1/Zend/zend_builtin_functions.c:177: multiple definition of `third_arg_force_ref' ext/pdo/.libs/pdo_stmt.o(.data+0xa0):/usr/local/directadmin/customapache/php-5.1.1/ext/pdo/pdo_stmt.c:150: first defined here Zend/.libs/zend_builtin_functions.o(.data+0x100): In function `zif_func_get_arg': /usr/local/directadmin/customapache/php-5.1.1/Zend/zend_builtin_functions.c:203: multiple definition of `fourth_arg_force_ref' ext/pdo/.libs/pdo_stmt.o(.data+0x100):/usr/local/directadmin/customapache/php-5.1.1/ext/pdo/pdo_stmt.c:174: first defined here Zend/.libs/zend_builtin_functions.o(.data+0x178): In function `zif_func_get_arg': /usr/local/directadmin/customapache/php-5.1.1/Zend/zend_builtin_functions.c:232: multiple definition of `all_args_by_ref' ext/pdo/.libs/pdo_stmt.o(.data+0x178):/usr/local/directadmin/customapache/php-5.1.1/ext/pdo/pdo_stmt.c:214: first defined here collect2: ld returned 1 exit status make: *** [libphp5.la] Error 1 -- Edit this bug report at http://bugs.php.net/?id=35486edit=1
#35485 [Opn-Bgs]: foreach is not working correctly
ID: 35485 Updated by: [EMAIL PROTECTED] Reported By: vma1 at abv dot bg -Status: Open +Status: Bogus Bug Type: Arrays related Operating System: Slackware 10.1, kernel 2.4.31 PHP Version: 5CVS-2005-11-30 (snap) New Comment: This is expected behaviour, no bug. Previous Comments: [2005-11-30 13:35:58] vma1 at abv dot bg So what? each() is not touching the $items array, it is touching the $items [0], and $items [1] elements which are arrays as well. [2005-11-30 13:30:05] [EMAIL PROTECTED] http://php.net/each each -- Return the current key and value pair from an array and *advance the array cursor* [2005-11-30 13:23:51] vma1 at abv dot bg In my previous comment I meant that no array elements are being added/removed. Besides try removing the each() operator and behaviour becomes correct. Something that should not happen. [2005-11-30 13:19:05] vma1 at abv dot bg The array is not being modified. [2005-11-30 12:54:27] [EMAIL PROTECTED] Do not modify array in the foreach() loop. 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/35485 -- Edit this bug report at http://bugs.php.net/?id=35485edit=1
#35428 [Asn-Fbk]: crash when using mysqli with MySQL 5.0.16
ID: 35428 Updated by: [EMAIL PROTECTED] Reported By: marcing at smlw dot pl -Status: Assigned +Status: Feedback Bug Type: MySQLi related Operating System: WinXP SP2 PHP Version: 5CVS-2005-11-28 (snap) Assigned To: georg New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip Previous Comments: [2005-11-29 01:55:17] [EMAIL PROTECTED] Assigned to the maintainer. [2005-11-29 01:54:13] [EMAIL PROTECTED] Extract them? And copy wherever you have the binaries and dlls for each file.. [2005-11-28 18:00:04] marcing at smlw dot pl What do i do with these *.pdb files? [2005-11-28 16:11:50] [EMAIL PROTECTED] If you'd install the latest CVS snapshot and the debug symbols, you'd propably get a bit better backtrace: http://snaps.php.net/ (c) Jani [2005-11-28 15:27:02] marcing at smlw dot pl I forgot i was running mysql 4.1.15:) The backtrace from php 5.1.2-dev and mysql 5.0.16: Program received signal SIGSEGV, Segmentation fault. 0x00e654de in ?? () (gdb) bt #0 0x00e654de in ?? () #1 0x0021 in ?? () #2 0x00374128 in ?? () 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/35428 -- Edit this bug report at http://bugs.php.net/?id=35428edit=1
#35488 [Opn-Bgs]: serialize() segmentation fault
ID: 35488 Updated by: [EMAIL PROTECTED] Reported By: kenashkov at gmail dot com -Status: Open +Status: Bogus -Bug Type: Unknown/Other Function +Bug Type: *General Issues Operating System: Fedora Core 4 PHP Version: 4.4.1 New Comment: Don't use references with serialize(). Previous Comments: [2005-11-30 13:58:20] kenashkov at gmail dot com Description: Segmentation fault when serializing multidimentional recursive arrays. The code below works fine with 4.3.11 (again on FC4). When the argument is passend by reference (which is deprecated): print_r(unserialize(serialize($arr1))); it is fine. Or passing a reference: print_r(unserialize(serialize($ref=$arr1))); also works. No problem with serializing just $arr1[0]=$arr; Reproduce code: --- ? $arr1[0][0] = $arr1; print_r(unserialize(serialize($arr1))); ? Expected result: Array ( [0] = Array ( [0] = Array ( [0] = Array ( [0] = Array *RECURSION* ) ) ) ) Actual result: -- Segmentation fault -- Edit this bug report at http://bugs.php.net/?id=35488edit=1
#35489 [NEW]: Memory crash
From: dark_soul279 at hotmail dot com Operating system: Windows 2000 PHP version: 5.1.1 PHP Bug Type: Scripting Engine problem Bug description: Memory crash Description: I placed php.ini (recommended version) in the same path as the executable that was going to run the script. My program uses Microsoft Script Control and i have a class module which i use to collect feedback from my scripts. I add the class module as an object using Dim rep as class1 set rep = new class1 ScriptControl1.AddObject rep,rep,false (reply is a method in the class module) hence, rep.reply hello world will display a message box saying hello world the script doesn't run and when the program exits php crashes with a memory cannot be read error message. also, the same thing happens with WScript but it displays the message and when the script ends PHP crashes Reproduce code: --- $rep-reply(Hello world); Expected result: message box appears saying Hello World Actual result: -- php crashes with memory cannot be read error -- Edit bug report at http://bugs.php.net/?id=35489edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=35489r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=35489r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=35489r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=35489r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=35489r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=35489r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=35489r=needscript Try newer version:http://bugs.php.net/fix.php?id=35489r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=35489r=support Expected behavior:http://bugs.php.net/fix.php?id=35489r=notwrong Not enough info: http://bugs.php.net/fix.php?id=35489r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=35489r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=35489r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35489r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=35489r=dst IIS Stability:http://bugs.php.net/fix.php?id=35489r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=35489r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=35489r=float No Zend Extensions: http://bugs.php.net/fix.php?id=35489r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=35489r=mysqlcfg
#35489 [Opn-Bgs]: Memory crash
ID: 35489 Updated by: [EMAIL PROTECTED] Reported By: dark_soul279 at hotmail dot com -Status: Open +Status: Bogus -Bug Type: Scripting Engine problem +Bug Type: COM related Operating System: Windows 2000 PHP Version: 5.1.1 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-11-30 14:03:58] dark_soul279 at hotmail dot com Description: I placed php.ini (recommended version) in the same path as the executable that was going to run the script. My program uses Microsoft Script Control and i have a class module which i use to collect feedback from my scripts. I add the class module as an object using Dim rep as class1 set rep = new class1 ScriptControl1.AddObject rep,rep,false (reply is a method in the class module) hence, rep.reply hello world will display a message box saying hello world the script doesn't run and when the program exits php crashes with a memory cannot be read error message. also, the same thing happens with WScript but it displays the message and when the script ends PHP crashes Reproduce code: --- $rep-reply(Hello world); Expected result: message box appears saying Hello World Actual result: -- php crashes with memory cannot be read error -- Edit this bug report at http://bugs.php.net/?id=35489edit=1
#35485 [Bgs]: foreach is not working correctly
ID: 35485 User updated by: vma1 at abv dot bg Reported By: vma1 at abv dot bg Status: Bogus Bug Type: Arrays related Operating System: Slackware 10.1, kernel 2.4.31 PHP Version: 5CVS-2005-11-30 (snap) New Comment: So what language construct should I use if I want to modify all array elements inside a loop? Previous Comments: [2005-11-30 14:01:37] [EMAIL PROTECTED] This is expected behaviour, no bug. [2005-11-30 13:35:58] vma1 at abv dot bg So what? each() is not touching the $items array, it is touching the $items [0], and $items [1] elements which are arrays as well. [2005-11-30 13:30:05] [EMAIL PROTECTED] http://php.net/each each -- Return the current key and value pair from an array and *advance the array cursor* [2005-11-30 13:23:51] vma1 at abv dot bg In my previous comment I meant that no array elements are being added/removed. Besides try removing the each() operator and behaviour becomes correct. Something that should not happen. [2005-11-30 13:19:05] vma1 at abv dot bg The array is not being modified. 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/35485 -- Edit this bug report at http://bugs.php.net/?id=35485edit=1
#35029 [Fbk]: segmentation faults with multiple include virtual requests
ID: 35029 Updated by: [EMAIL PROTECTED] Reported By: markus-php at anthill dot de Status: Feedback Bug Type: Apache2 related Operating System: linux / solaris PHP Version: 4.4.0 New Comment: Provide a short reproduce case and the GDB backtrace if you still able to replicate it. Previous Comments: [2005-11-30 13:55:46] minnoce at polito dot it Same problem also with PHP 5.1 LATEST from CVS. [2005-11-30 12:36:07] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip [2005-11-30 11:28:25] minnoce at polito dot it I have the same problem under this platform: - Red Hat Enterprise Linux 4 (i386) fully updated - Apache 2.0.55 compiled from sources - PHP 4.3.11 / 4.4.1 / LATEST 4.4 from CVS compiled from sources The bug is NOT present under Apache 2.0.54. [2005-11-15 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-11-07 23:43:06] markus-php at anthill dot de with PHP 4.4.0 I had a segmentation fault (see above). According to the backtrace the problems seems to be in the PHP code. When switching from PHP 4.4.0 to 4.4.1 the segmentation fault seems to have gone, but the result isn't ok yet. As I am not that familiar with gdb I can't really tell if it is a problem with Apache or PHP or something else. I'll make some tests during the next days and try to dig further into this. 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/35029 -- Edit this bug report at http://bugs.php.net/?id=35029edit=1
#35480 [Asn-Fbk]: Persistent connections + unknown column crashes
ID: 35480
Updated by: [EMAIL PROTECTED]
Reported By: tim at komta dot com
-Status: Assigned
+Status: Feedback
Bug Type: PDO related
Operating System: Windows XP
PHP Version: 5.1.1
Assigned To: georg
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
Previous Comments:
[2005-11-30 03:35:09] [EMAIL PROTECTED]
tim, can you provide a backtrace?
[2005-11-29 23:09:53] [EMAIL PROTECTED]
Georg, this seems to be the same issue caused by protocol binary
incompatibility.
[2005-11-29 23:04:24] tim at komta dot com
Oops, sorry about that, it's MySQL 5.0.15
[2005-11-29 21:55:05] [EMAIL PROTECTED]
And what MySQL version?
[2005-11-29 21:10:03] tim at komta dot com
Description:
Using a persistent connection with PDO (mysql tested) and then
executing a query with an unknown column will crash PHP 5.1.1, and take
Apache with it.
This has been reproduced on two seperate systems here at the office
already. Both systems use Apache 2.0.54 as a module, with PHP 5.1.1
Reproduce code:
---
?php
$pdo = new PDO('mysql:host=HOST;dbname=mysql',
USER, PASSWORD, array(PDO::ATTR_PERSISTENT = TRUE));
$pdo-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_WARNING);
$pdo-query('SELECT frank FROM mysql.user LIMIT 20');
?
Expected result:
Expect a warning, such as Warning: PDO::query() [function.query]:
SQLSTATE[42S22]: Column not found: 1054 Unknown column 'frank' in
'field list' in C:\Documents and Settings\Tim\workspace\hxpa
SVN\temp.php on line 5
Actual result:
--
PHP (Apache is reported) crashes.
--
Edit this bug report at http://bugs.php.net/?id=35480edit=1
#35415 [Asn-Fbk]: crash with persistent connection
ID: 35415 Updated by: [EMAIL PROTECTED] Reported By: gm at html dot it -Status: Assigned +Status: Feedback Bug Type: PDO related Operating System: Linux Fedora Core 4 PHP Version: 5.1.1 Assigned To: wez New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip Previous Comments: [2005-11-29 08:24:53] gm at html dot it MySql 4.0.26 [2005-11-28 20:02:07] [EMAIL PROTECTED] What version of mysql are you running? [2005-11-28 18:24:26] gm at html dot it Always the same #0 0x080cc965 in shutdown_memory_manager (silent=0, full_shutdown=0) at /home/giancarlo/sorgenti/php5-200511281530/Zend/zend_alloc.c:511 #1 0x080b349d in php_request_shutdown (dummy=0x0) at /home/giancarlo/sorgenti/php5-200511281530/main/main.c:1287 #2 0x0815e822 in apache_php_module_main (r=0x9752bb4, display_source_mode=0) at /home/giancarlo/sorgenti/php5-200511281530/sapi/apache/sapi_apache.c:59 #3 0x080ac725 in send_php () #4 0x080ac78a in send_parsed_php () #5 0x082fd123 in ap_invoke_handler () #6 0x083129de in process_request_internal () #7 0x08312a3e in ap_process_request () #8 0x0830952d in child_main () #9 0x08309750 in make_child () #10 0x083098a4 in startup_children () #11 0x08309f3a in standalone_main () #12 0x0830a741 in main () [2005-11-28 17:53:19] [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 Can't reproduce. [2005-11-28 17:37:10] gm at html dot it Here is the backtrace #0 0x080cc915 in shutdown_memory_manager (silent=0, full_shutdown=0) at /home/giancarlo/sorgenti/php-5.1.1/Zend/zend_alloc.c:511 #1 0x080b344d in php_request_shutdown (dummy=0x0) at /home/giancarlo/sorgenti/php-5.1.1/main/main.c:1287 #2 0x0815e7be in apache_php_module_main (r=0x920ab84, display_source_mode=0) at /home/giancarlo/sorgenti/php-5.1.1/sapi/apache/sapi_apache.c:59 #3 0x080ac6d5 in send_php () #4 0x080ac73a in send_parsed_php () #5 0x082fcf3f in ap_invoke_handler () #6 0x083127fa in process_request_internal () #7 0x0831285a in ap_process_request () #8 0x08309349 in child_main () #9 0x0830956c in make_child () #10 0x083096c0 in startup_children () #11 0x08309d56 in standalone_main () #12 0x0830a55d in main () 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/35415 -- Edit this bug report at http://bugs.php.net/?id=35415edit=1
#35388 [Asn-Fbk]: crash on new object when passed incorrect access details
ID: 35388 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Feedback Bug Type: MySQLi related Operating System: Windows XP Home SP2 PHP Version: 5.1.0 Assigned To: georg New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip Previous Comments: [2005-11-28 23:18:31] [EMAIL PROTECTED] Looks like there is a binary incompatibility in protocol when connecting from 4.1 client to 5.0.16. I was able to reproduce the problem under linux too. As a possible workaround you should compile PHP against 5.0.16 client lib. [2005-11-28 17:19:22] [EMAIL PROTECTED] I've downloaded the latest snapshot (problem still exists) and the win32 debug pack with the .pdb files. I've had a look on the PHP mailing lists and Google but can't find any help for actually using the debug pack. Can you point me in the right direction? [2005-11-28 10:03:21] [EMAIL PROTECTED] If you'd install the latest CVS snapshot and the debug symbols, you'd propably get a bit better backtrace: http://snaps.php.net/ [2005-11-25 18:55:48] [EMAIL PROTECTED] I've tested this on Linux (SuSe 9.3)/PHP 5.0.5/MySQL 4.1/MySQL 5.0/Apache 2.0.55 and the reproduce code works fine. This suggests that it is a Windows problem. I am testing on Windows XP/PHP 5.1/MySQL 5.0/Apache 2.0.55. So, I have installed GDB onto my Windows machine to get a backtrace: gdb (gdb) target exec C:\php\php.exe (gdb) run test.php Starting program: C:\php\.php.exe test.php warning: 3744:2900 Initializing all chains with next layer = 1002 A new command prompt appears with the test.php file output. This includes the standard HTML headers but also shows the PHP warning that should be displayed: Warning: mysqli::mysqli(): (28000/1045): Access denied for user 'root'@'localhost (using password: YES) in test.php on line 7 However, the gdb window then shows: Program received signal SIGSEGV, Segmentation fault. Type return to continue or q return to quit. I hit return and get this output: 0x77ea3c00 in ?? () Then running the bt command: (gdb) bt #0 0x77ea3c00 in ?? () #1 0x0012faa0 in ?? () #2 0x77ef360b in ?? () #3 0x77de69bc in ?? () #4 0x77de697d in ?? () #5 0x77de6950 in ?? () #6 0x100dce85 in ?? () #7 0x8528488b in ?? () Cannot access memory at address 0x424448b The Apache error log shows Parent: Child process exited with status 3221225477 [2005-11-25 17:25:31] [EMAIL PROTECTED] I've no idea, really. I thought you should know it better, 'cause it's you're running windows. Try on another host, do some research, maybe you'll be able to give some more information about it. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/35388 -- Edit this bug report at http://bugs.php.net/?id=35388edit=1
#35428 [Fbk-Opn]: crash when using mysqli with MySQL 5.0.16
ID: 35428 User updated by: marcing at smlw dot pl Reported By: marcing at smlw dot pl -Status: Feedback +Status: Open Bug Type: MySQLi related Operating System: WinXP SP2 PHP Version: 5CVS-2005-11-28 (snap) Assigned To: georg New Comment: What's the point of checking the same and unchanged file again? Previous Comments: [2005-11-30 14:02:48] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip [2005-11-29 01:55:17] [EMAIL PROTECTED] Assigned to the maintainer. [2005-11-29 01:54:13] [EMAIL PROTECTED] Extract them? And copy wherever you have the binaries and dlls for each file.. [2005-11-28 18:00:04] marcing at smlw dot pl What do i do with these *.pdb files? [2005-11-28 16:11:50] [EMAIL PROTECTED] If you'd install the latest CVS snapshot and the debug symbols, you'd propably get a bit better backtrace: http://snaps.php.net/ (c) Jani 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/35428 -- Edit this bug report at http://bugs.php.net/?id=35428edit=1
#35428 [Opn-Bgs]: crash when using mysqli with MySQL 5.0.16
ID: 35428 Updated by: [EMAIL PROTECTED] Reported By: marcing at smlw dot pl -Status: Open +Status: Bogus Bug Type: MySQLi related Operating System: WinXP SP2 PHP Version: 5CVS-2005-11-28 (snap) Assigned To: georg New Comment: No, nothing. Don't bother, it's fixed. And reported by dozen other people too.. Previous Comments: [2005-11-30 14:45:16] marcing at smlw dot pl What's the point of checking the same and unchanged file again? [2005-11-30 14:02:48] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip [2005-11-29 01:55:17] [EMAIL PROTECTED] Assigned to the maintainer. [2005-11-29 01:54:13] [EMAIL PROTECTED] Extract them? And copy wherever you have the binaries and dlls for each file.. [2005-11-28 18:00:04] marcing at smlw dot pl What do i do with these *.pdb files? 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/35428 -- Edit this bug report at http://bugs.php.net/?id=35428edit=1
#35428 [Bgs-Fbk]: crash when using mysqli with MySQL 5.0.16
ID: 35428 Updated by: [EMAIL PROTECTED] Reported By: marcing at smlw dot pl -Status: Bogus +Status: Feedback Bug Type: MySQLi related Operating System: WinXP SP2 PHP Version: 5CVS-2005-11-28 (snap) Assigned To: georg New Comment: Why do you think it's unchanged? The url is the same, while file is regenerated every time. Previous Comments: [2005-11-30 14:47:43] [EMAIL PROTECTED] No, nothing. Don't bother, it's fixed. And reported by dozen other people too.. [2005-11-30 14:45:16] marcing at smlw dot pl What's the point of checking the same and unchanged file again? [2005-11-30 14:02:48] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip [2005-11-29 01:55:17] [EMAIL PROTECTED] Assigned to the maintainer. [2005-11-29 01:54:13] [EMAIL PROTECTED] Extract them? And copy wherever you have the binaries and dlls for each file.. 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/35428 -- Edit this bug report at http://bugs.php.net/?id=35428edit=1
#35072 [Opn-Bgs]: ftps:// fopen wrapper: FTP server reports 501 wrong number of parameters
ID: 35072
Updated by: [EMAIL PROTECTED]
Reported By: bill dot finn at sellingsource dot com
-Status: Open
+Status: Bogus
Bug Type: Filesystem function related
Operating System: *
PHP Version: 5CVS-2005-11-29 (snap)
New Comment:
See also bug #23220 for information why this isn't PHP bug.
Previous Comments:
[2005-11-29 17:57:43] bill dot finn at sellingsource dot com
It now retrieves the file, but is still generating an error:
PHP Warning: file(): SSL: fatal protocol error in
/home/wfinn/test/ftps.php on line 21
Warning: file(): SSL: fatal protocol error in /home/wfinn/test/ftps.php
on line 21
[2005-11-28 15:03:35] [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-11-02 22:10:52] bill dot finn at sellingsource dot com
Description:
using ftps in some filesystem functions produces ssl error and fails.
Same effect if only using file() without file_exists before it.
Reproduce code:
---
echo
file_exists(ftps://{$user}:[EMAIL PROTECTED]:{$port}/{$path}{$file})
$contents =
file(ftps://{$user}:[EMAIL PROTECTED]:{$port}/{$path}{$file})
Expected result:
$contents should get the contents of the file I'm requesting from the
server.
Actual result:
--
PHP Warning: file(): SSL/TLS already set-up for this stream in
/home/wfinn/test/ftps.php on line 21
Warning: file(): SSL/TLS already set-up for this stream in
/home/wfinn/test/ftps.php on line 21
PHP Warning: file(ftps://...myinfo...): failed to open stream: Unable
to activate SSL mode
FTP server reports 150 Opening BINARY data connection for
/s-fastcash/343923324-20051019.ddl (1084 bytes)
in /home/wfinn/test/ftps.php on line 21
Warning: file(ftps://...myinfo...): failed to open stream: Unable to
activate SSL mode
FTP server reports 150 Opening BINARY data connection for
/s-fastcash/343923324-20051019.ddl (1084 bytes)
in /home/wfinn/test/ftps.php on line 21
--
Edit this bug report at http://bugs.php.net/?id=35072edit=1
#35490 [NEW]: socket_sendto seems unable to handle IPv6 addresses
From: Xavier dot Redon at polytech-lille dot fr
Operating system: Linux 2.6
PHP version: 5.1.1
PHP Bug Type: Sockets related
Bug description: socket_sendto seems unable to handle IPv6 addresses
Description:
When executing the script below an error occurs.
A trace with strace show that the struct sockaddr of the system call
sendto is uninitialized (or badly initialized) :
sendto(3, Test Message, 12, 0, {sa_family=0x45a0 /* AF_??? */,
sa_data=\10\20\0\0\0\20\0\0\0\250\376\343\277}, 16) = -1 EINVAL
(Invalid argument)
Reproduce code:
---
?
$sh = socket_create(AF_INET6,SOCK_DGRAM,0);
if (socket_bind($sh, '::1', 4242)) {
echo Socket ok\n;
}
$buf = 'Test Message';
$len = strlen($buf);
if (socket_sendto($sh, $buf, $len, 0x00, '::1', 4000) !== FALSE) {
echo Message sent\n;
}
socket_close($sh);
?
Expected result:
an IPv6 UDP datagram should be sent to the IPv6 loopback address.
Actual result:
--
Warning: socket_sendto(): unable to write to socket [22]: Invalid argument
in /tmp/toto.php on line 12
--
Edit bug report at http://bugs.php.net/?id=35490edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=35490r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=35490r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=35490r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=35490r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=35490r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=35490r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=35490r=needscript
Try newer version:http://bugs.php.net/fix.php?id=35490r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=35490r=support
Expected behavior:http://bugs.php.net/fix.php?id=35490r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=35490r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=35490r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=35490r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35490r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=35490r=dst
IIS Stability:http://bugs.php.net/fix.php?id=35490r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=35490r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=35490r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=35490r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=35490r=mysqlcfg
#35491 [NEW]: Nice missbehaviour using arrays in functions.
From: stephan dot skusa at lippe-net dot de
Operating system: Linux
PHP version: 4.4.1
PHP Bug Type: Arrays related
Bug description: Nice missbehaviour using arrays in functions.
Description:
The call of test() results into an endless loop. The first for() works
well, the for() in the function is the problem.
And the Problem appears even if the first for() is left out.
Reproduce code:
---
?PHP
$arr = array ('a' = 1, 'c' = 2);
for (reset ($arr); $key = key ($arr); next ($arr)) {
echo $key;
}
echo PING;
function test() {
global $arr;
for (reset ($arr); $key = key ($arr); next ($arr)) {
echo $key;
}
}
test();
?
Expected result:
Output of acPINGac
Actual result:
--
Endless Loop
Output of acPINGa ... to be continued
--
Edit bug report at http://bugs.php.net/?id=35491edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=35491r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=35491r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=35491r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=35491r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=35491r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=35491r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=35491r=needscript
Try newer version:http://bugs.php.net/fix.php?id=35491r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=35491r=support
Expected behavior:http://bugs.php.net/fix.php?id=35491r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=35491r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=35491r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=35491r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35491r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=35491r=dst
IIS Stability:http://bugs.php.net/fix.php?id=35491r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=35491r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=35491r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=35491r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=35491r=mysqlcfg
#34656 [Opn]: open_basedir restriction in effect although paths are set correctly
ID: 34656 User updated by: wolfram at schlich dot org Reported By: wolfram at schlich dot org Status: Open Bug Type: Safe Mode/open_basedir Operating System: Linux 2.2.16 i586 PHP Version: 4.4.1 New Comment: Do you need more information? Previous Comments: [2005-11-25 13:27:23] wolfram at schlich dot org just tried http://snaps.php.net/php4-STABLE-200511251208.tar.gz with open_basedir in php.ini -- no luck: Warning: touch(): open_basedir restriction in effect. File(/tmp/f5_test) is not within the allowed path(s): (/tmp/) in /home/sites/site15/web/write_tmp.php on line 3 [2005-11-01 22:34:00] [EMAIL PROTECTED] Does it work if you set the open_basedir in php.ini ? [2005-11-01 15:01:35] wolfram at schlich dot org Just tried with the freshly released 4.4.1, without luck: --8-- Warning: fopen(): open_basedir restriction in effect. File(/tmp/foo.bar) is not within the allowed path(s): (/home/sites/site81/:/tmp/:/usr/share/pear/) in /home/sites/site81/web/fopen.php on line 3 Warning: fopen(/tmp/foo.bar): failed to open stream: Operation not permitted in /home/sites/site81/web/fopen.php on line 3 --8-- --8--[ access.conf ]--8-- DirectoryMatch /home/sites/site81/ php_admin_value open_basedir /home/sites/site81/:/tmp/:/usr/share/pear/ /DirectoryMatch --8-- [2005-09-27 12:44:53] wolfram at schlich dot org Description: Warning: touch(): open_basedir restriction in effect. File(/tmp/f5_test) is not within the allowed path(s): (/home/sites/site15/:/tmp) in /home/sites/site15/web/write_tmp.php on line 3 Warning: fopen(): open_basedir restriction in effect. File(/tmp/f5_test) is not within the allowed path(s): (/home/sites/site15/:/tmp) in /home/sites/site15/web/write_tmp.php on line 4 Warning: fopen(/tmp/f5_test): failed to open stream: Operation not permitted in /home/sites/site15/web/write_tmp.php on line 4 Warning: fwrite(): supplied argument is not a valid stream resource in /home/sites/site15/web/write_tmp.php on line 5 Warning: fclose(): supplied argument is not a valid stream resource in /home/sites/site15/web/write_tmp.php on line 6 Reproduce code: --- --8--[ write_tmp.php ]--8-- ?php $tmpfile = /tmp/f5_test; touch($tmpfile); $fp = fopen($tmpfile,w); fwrite($fp, test ); fclose($fp); ? --8--[ httpd.conf ]--8-- DirectoryMatch /home/sites/site15/ ## doesn't work php_admin_value open_basedir /home/sites/site15/:/tmp ## also doesn't work # php_admin_value open_basedir / ## works, but is not what's desired # php_admin_value open_basedir none /DirectoryMatch --8-- Also tried to set open_basedir within the VirtualHost, didn' t work either. Expected result: no errors Actual result: -- open_basedir errors -- Edit this bug report at http://bugs.php.net/?id=34656edit=1
#35415 [Fbk-Opn]: crash with persistent connection
ID: 35415 User updated by: gm at html dot it Reported By: gm at html dot it -Status: Feedback +Status: Open Bug Type: PDO related Operating System: Linux Fedora Core 4 PHP Version: 5.1.1 Assigned To: wez New Comment: It looks like everything works good now Previous Comments: [2005-11-30 14:08:49] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip [2005-11-29 08:24:53] gm at html dot it MySql 4.0.26 [2005-11-28 20:02:07] [EMAIL PROTECTED] What version of mysql are you running? [2005-11-28 18:24:26] gm at html dot it Always the same #0 0x080cc965 in shutdown_memory_manager (silent=0, full_shutdown=0) at /home/giancarlo/sorgenti/php5-200511281530/Zend/zend_alloc.c:511 #1 0x080b349d in php_request_shutdown (dummy=0x0) at /home/giancarlo/sorgenti/php5-200511281530/main/main.c:1287 #2 0x0815e822 in apache_php_module_main (r=0x9752bb4, display_source_mode=0) at /home/giancarlo/sorgenti/php5-200511281530/sapi/apache/sapi_apache.c:59 #3 0x080ac725 in send_php () #4 0x080ac78a in send_parsed_php () #5 0x082fd123 in ap_invoke_handler () #6 0x083129de in process_request_internal () #7 0x08312a3e in ap_process_request () #8 0x0830952d in child_main () #9 0x08309750 in make_child () #10 0x083098a4 in startup_children () #11 0x08309f3a in standalone_main () #12 0x0830a741 in main () [2005-11-28 17:53:19] [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 Can't reproduce. 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/35415 -- Edit this bug report at http://bugs.php.net/?id=35415edit=1
#35491 [Opn-Bgs]: Nice missbehaviour using arrays in functions.
ID: 35491
Updated by: [EMAIL PROTECTED]
Reported By: stephan dot skusa at lippe-net dot de
-Status: Open
+Status: Bogus
Bug Type: Arrays related
Operating System: Linux
PHP Version: 4.4.1
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.
Reported a gazillion of times before.
Fixed long time ago.
Previous Comments:
[2005-11-30 15:02:34] stephan dot skusa at lippe-net dot de
Description:
The call of test() results into an endless loop. The first for() works
well, the for() in the function is the problem.
And the Problem appears even if the first for() is left out.
Reproduce code:
---
?PHP
$arr = array ('a' = 1, 'c' = 2);
for (reset ($arr); $key = key ($arr); next ($arr)) {
echo $key;
}
echo PING;
function test() {
global $arr;
for (reset ($arr); $key = key ($arr); next ($arr)) {
echo $key;
}
}
test();
?
Expected result:
Output of acPINGac
Actual result:
--
Endless Loop
Output of acPINGa ... to be continued
--
Edit this bug report at http://bugs.php.net/?id=35491edit=1
#35415 [Opn-Csd]: crash with persistent connection
ID: 35415 Updated by: [EMAIL PROTECTED] Reported By: gm at html dot it -Status: Open +Status: Closed Bug Type: PDO related Operating System: Linux Fedora Core 4 PHP Version: 5.1.1 Assigned To: wez New Comment: Fixed - closed. Previous Comments: [2005-11-30 15:03:41] gm at html dot it It looks like everything works good now [2005-11-30 14:08:49] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip [2005-11-29 08:24:53] gm at html dot it MySql 4.0.26 [2005-11-28 20:02:07] [EMAIL PROTECTED] What version of mysql are you running? [2005-11-28 18:24:26] gm at html dot it Always the same #0 0x080cc965 in shutdown_memory_manager (silent=0, full_shutdown=0) at /home/giancarlo/sorgenti/php5-200511281530/Zend/zend_alloc.c:511 #1 0x080b349d in php_request_shutdown (dummy=0x0) at /home/giancarlo/sorgenti/php5-200511281530/main/main.c:1287 #2 0x0815e822 in apache_php_module_main (r=0x9752bb4, display_source_mode=0) at /home/giancarlo/sorgenti/php5-200511281530/sapi/apache/sapi_apache.c:59 #3 0x080ac725 in send_php () #4 0x080ac78a in send_parsed_php () #5 0x082fd123 in ap_invoke_handler () #6 0x083129de in process_request_internal () #7 0x08312a3e in ap_process_request () #8 0x0830952d in child_main () #9 0x08309750 in make_child () #10 0x083098a4 in startup_children () #11 0x08309f3a in standalone_main () #12 0x0830a741 in main () 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/35415 -- Edit this bug report at http://bugs.php.net/?id=35415edit=1
#35492 [NEW]: ld
From: dandrikop at cosmote dot gr Operating system: Solaris 9 SPARC PHP version: 5.1.1 PHP Bug Type: Compile Failure Bug description: ld Description: I tried to compile PHP 5.1.1 on Solaris 9 SPARC system. The 'make' or 'gmake' process fails. However, on the same system I have compiled all PHP 5.0.x version and never encountered such a problem. My MySQL version is 4.1.7. Reproduce code: --- ./configure --prefix=/usr/local/php --exec-prefix=/usr/local/php --with-mysql=/opt/sfw/mysql --with-mysqli=/opt/sfw/mysql/bin/mysql_config --with-apxs=/usr/apache/bin/apxs --with-pear --with-config-file-path=/etc/apache --with-zlib --enable-bcmath --with-bz2 --enable-calendar --with-jpeg-dir=/usr/sfw/lib --with-tiff-dir=/usr/sfw/lib --enable-ftp --enable-soap --enable-dba --with-gdbm Actual result: -- .. errno 0x38 /opt/sfw/mysql/lib/libmysqlclient.a(my_getwd.o) errno 0x1f0 /opt/sfw/mysql/lib/libmysqlclient.a(my_getwd.o) errno 0x1f4 /opt/sfw/mysql/lib/libmysqlclient.a(my_getwd.o) errno 0x1c0 /opt/sfw/mysql/lib/libmysqlclient.a(strtod.o) errno 0x1c4 /opt/sfw/mysql/lib/libmysqlclient.a(strtod.o) errno 0x2c /opt/sfw/mysql/lib/libmysqlclient.a(my_fopen.o) errno 0x108 /opt/sfw/mysql/lib/libmysqlclient.a(my_fopen.o) errno 0x138 /opt/sfw/mysql/lib/libmysqlclient.a(my_fopen.o) errno 0x198 /opt/sfw/mysql/lib/libmysqlclient.a(my_fopen.o) errno 0x1b8 /opt/sfw/mysql/lib/libmysqlclient.a(my_fopen.o) errno 0x284 /opt/sfw/mysql/lib/libmysqlclient.a(my_fopen.o) errno 0x288 /opt/sfw/mysql/lib/libmysqlclient.a(my_fopen.o) atoi0xf0 /opt/sfw/mysql/lib/libmysqlclient.a(libmysql.o) atoi0x252c /opt/sfw/mysql/lib/libmysqlclient.a(libmysql.o) atoi0x3b90 /opt/sfw/mysql/lib/libmysqlclient.a(libmysql.o) atoi0x58c /opt/sfw/mysql/lib/libmysqlclient.a(client.o) atoi0x618 /opt/sfw/mysql/lib/libmysqlclient.a(client.o) atoi0x79c /opt/sfw/mysql/lib/libmysqlclient.a(client.o) atoi0x7f4 /opt/sfw/mysql/lib/libmysqlclient.a(client.o) atoi0x160 /opt/sfw/mysql/lib/libmysqlclient.a(typelib.o) realpath0x12c /opt/sfw/mysql/lib/libmysqlclient.a(my_symlink.o) getcwd 0x198 /opt/sfw/mysql/lib/libmysqlclient.a(my_getwd.o) ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status gmake: *** [libphp5.la] Error 1 -- Edit bug report at http://bugs.php.net/?id=35492edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=35492r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=35492r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=35492r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=35492r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=35492r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=35492r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=35492r=needscript Try newer version:http://bugs.php.net/fix.php?id=35492r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=35492r=support Expected behavior:http://bugs.php.net/fix.php?id=35492r=notwrong Not enough info: http://bugs.php.net/fix.php?id=35492r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=35492r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=35492r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35492r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=35492r=dst IIS Stability:http://bugs.php.net/fix.php?id=35492r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=35492r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=35492r=float No Zend Extensions: http://bugs.php.net/fix.php?id=35492r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=35492r=mysqlcfg
#35492 [Opn-Bgs]: ld
ID: 35492 Updated by: [EMAIL PROTECTED] Reported By: dandrikop at cosmote dot gr -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: Solaris 9 SPARC PHP Version: 5.1.1 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. Previous Comments: [2005-11-30 15:14:48] dandrikop at cosmote dot gr Description: I tried to compile PHP 5.1.1 on Solaris 9 SPARC system. The 'make' or 'gmake' process fails. However, on the same system I have compiled all PHP 5.0.x version and never encountered such a problem. My MySQL version is 4.1.7. Reproduce code: --- ./configure --prefix=/usr/local/php --exec-prefix=/usr/local/php --with-mysql=/opt/sfw/mysql --with-mysqli=/opt/sfw/mysql/bin/mysql_config --with-apxs=/usr/apache/bin/apxs --with-pear --with-config-file-path=/etc/apache --with-zlib --enable-bcmath --with-bz2 --enable-calendar --with-jpeg-dir=/usr/sfw/lib --with-tiff-dir=/usr/sfw/lib --enable-ftp --enable-soap --enable-dba --with-gdbm Actual result: -- .. errno 0x38 /opt/sfw/mysql/lib/libmysqlclient.a(my_getwd.o) errno 0x1f0 /opt/sfw/mysql/lib/libmysqlclient.a(my_getwd.o) errno 0x1f4 /opt/sfw/mysql/lib/libmysqlclient.a(my_getwd.o) errno 0x1c0 /opt/sfw/mysql/lib/libmysqlclient.a(strtod.o) errno 0x1c4 /opt/sfw/mysql/lib/libmysqlclient.a(strtod.o) errno 0x2c /opt/sfw/mysql/lib/libmysqlclient.a(my_fopen.o) errno 0x108 /opt/sfw/mysql/lib/libmysqlclient.a(my_fopen.o) errno 0x138 /opt/sfw/mysql/lib/libmysqlclient.a(my_fopen.o) errno 0x198 /opt/sfw/mysql/lib/libmysqlclient.a(my_fopen.o) errno 0x1b8 /opt/sfw/mysql/lib/libmysqlclient.a(my_fopen.o) errno 0x284 /opt/sfw/mysql/lib/libmysqlclient.a(my_fopen.o) errno 0x288 /opt/sfw/mysql/lib/libmysqlclient.a(my_fopen.o) atoi0xf0 /opt/sfw/mysql/lib/libmysqlclient.a(libmysql.o) atoi0x252c /opt/sfw/mysql/lib/libmysqlclient.a(libmysql.o) atoi0x3b90 /opt/sfw/mysql/lib/libmysqlclient.a(libmysql.o) atoi0x58c /opt/sfw/mysql/lib/libmysqlclient.a(client.o) atoi0x618 /opt/sfw/mysql/lib/libmysqlclient.a(client.o) atoi0x79c /opt/sfw/mysql/lib/libmysqlclient.a(client.o) atoi0x7f4 /opt/sfw/mysql/lib/libmysqlclient.a(client.o) atoi0x160 /opt/sfw/mysql/lib/libmysqlclient.a(typelib.o) realpath0x12c /opt/sfw/mysql/lib/libmysqlclient.a(my_symlink.o) getcwd 0x198 /opt/sfw/mysql/lib/libmysqlclient.a(my_getwd.o) ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status gmake: *** [libphp5.la] Error 1 -- Edit this bug report at http://bugs.php.net/?id=35492edit=1
#35492 [Bgs]: ld
ID: 35492 User updated by: dandrikop at cosmote dot gr Reported By: dandrikop at cosmote dot gr Status: Bogus Bug Type: Compile Failure Operating System: Solaris 9 SPARC PHP Version: 5.1.1 New Comment: Is it possible to send me that bug report ID that describes the resolution? Previous Comments: [2005-11-30 15:20:14] [EMAIL PROTECTED] 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. [2005-11-30 15:14:48] dandrikop at cosmote dot gr Description: I tried to compile PHP 5.1.1 on Solaris 9 SPARC system. The 'make' or 'gmake' process fails. However, on the same system I have compiled all PHP 5.0.x version and never encountered such a problem. My MySQL version is 4.1.7. Reproduce code: --- ./configure --prefix=/usr/local/php --exec-prefix=/usr/local/php --with-mysql=/opt/sfw/mysql --with-mysqli=/opt/sfw/mysql/bin/mysql_config --with-apxs=/usr/apache/bin/apxs --with-pear --with-config-file-path=/etc/apache --with-zlib --enable-bcmath --with-bz2 --enable-calendar --with-jpeg-dir=/usr/sfw/lib --with-tiff-dir=/usr/sfw/lib --enable-ftp --enable-soap --enable-dba --with-gdbm Actual result: -- .. errno 0x38 /opt/sfw/mysql/lib/libmysqlclient.a(my_getwd.o) errno 0x1f0 /opt/sfw/mysql/lib/libmysqlclient.a(my_getwd.o) errno 0x1f4 /opt/sfw/mysql/lib/libmysqlclient.a(my_getwd.o) errno 0x1c0 /opt/sfw/mysql/lib/libmysqlclient.a(strtod.o) errno 0x1c4 /opt/sfw/mysql/lib/libmysqlclient.a(strtod.o) errno 0x2c /opt/sfw/mysql/lib/libmysqlclient.a(my_fopen.o) errno 0x108 /opt/sfw/mysql/lib/libmysqlclient.a(my_fopen.o) errno 0x138 /opt/sfw/mysql/lib/libmysqlclient.a(my_fopen.o) errno 0x198 /opt/sfw/mysql/lib/libmysqlclient.a(my_fopen.o) errno 0x1b8 /opt/sfw/mysql/lib/libmysqlclient.a(my_fopen.o) errno 0x284 /opt/sfw/mysql/lib/libmysqlclient.a(my_fopen.o) errno 0x288 /opt/sfw/mysql/lib/libmysqlclient.a(my_fopen.o) atoi0xf0 /opt/sfw/mysql/lib/libmysqlclient.a(libmysql.o) atoi0x252c /opt/sfw/mysql/lib/libmysqlclient.a(libmysql.o) atoi0x3b90 /opt/sfw/mysql/lib/libmysqlclient.a(libmysql.o) atoi0x58c /opt/sfw/mysql/lib/libmysqlclient.a(client.o) atoi0x618 /opt/sfw/mysql/lib/libmysqlclient.a(client.o) atoi0x79c /opt/sfw/mysql/lib/libmysqlclient.a(client.o) atoi0x7f4 /opt/sfw/mysql/lib/libmysqlclient.a(client.o) atoi0x160 /opt/sfw/mysql/lib/libmysqlclient.a(typelib.o) realpath0x12c /opt/sfw/mysql/lib/libmysqlclient.a(my_symlink.o) getcwd 0x198 /opt/sfw/mysql/lib/libmysqlclient.a(my_getwd.o) ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status gmake: *** [libphp5.la] Error 1 -- Edit this bug report at http://bugs.php.net/?id=35492edit=1
#35480 [Fbk-Opn]: Persistent connections + unknown column crashes
ID: 35480 User updated by: tim at komta dot com Reported By: tim at komta dot com -Status: Feedback +Status: Open Bug Type: PDO related Operating System: Windows XP PHP Version: 5.1.1 Assigned To: georg New Comment: With the snapshot linked by Sniper, the problem is still there. Wez, I think I'm misunderstanding what you're asking...The method of getting a backtrace that I know of (debug_backtrace()) requires PHP to be running. The script crashes in such a way that no output ever goes to the user agent, in spite of no output buffering. Is there something else I should be doing? - Tim Previous Comments: [2005-11-30 14:07:51] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip [2005-11-30 03:35:09] [EMAIL PROTECTED] tim, can you provide a backtrace? [2005-11-29 23:09:53] [EMAIL PROTECTED] Georg, this seems to be the same issue caused by protocol binary incompatibility. [2005-11-29 23:04:24] tim at komta dot com Oops, sorry about that, it's MySQL 5.0.15 [2005-11-29 21:55:05] [EMAIL PROTECTED] And what MySQL version? 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/35480 -- Edit this bug report at http://bugs.php.net/?id=35480edit=1
#35480 [Opn-Asn]: Persistent connections + unknown column crashes
ID: 35480 Updated by: [EMAIL PROTECTED] Reported By: tim at komta dot com -Status: Open +Status: Assigned Bug Type: PDO related Operating System: Windows XP PHP Version: 5.1.1 -Assigned To: georg +Assigned To: wez Previous Comments: [2005-11-30 15:26:19] tim at komta dot com With the snapshot linked by Sniper, the problem is still there. Wez, I think I'm misunderstanding what you're asking...The method of getting a backtrace that I know of (debug_backtrace()) requires PHP to be running. The script crashes in such a way that no output ever goes to the user agent, in spite of no output buffering. Is there something else I should be doing? - Tim [2005-11-30 14:07:51] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip [2005-11-30 03:35:09] [EMAIL PROTECTED] tim, can you provide a backtrace? [2005-11-29 23:09:53] [EMAIL PROTECTED] Georg, this seems to be the same issue caused by protocol binary incompatibility. [2005-11-29 23:04:24] tim at komta dot com Oops, sorry about that, it's MySQL 5.0.15 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/35480 -- Edit this bug report at http://bugs.php.net/?id=35480edit=1
#35491 [Bgs]: Nice missbehaviour using arrays in functions.
ID: 35491
User updated by: stephan dot skusa at lippe-net dot de
Reported By: stephan dot skusa at lippe-net dot de
Status: Bogus
Bug Type: Arrays related
Operating System: Linux
PHP Version: 4.4.1
New Comment:
I didn't found an equal bug description.
Not everybody describes a bug the same way, maybe that's the reason!
Previous Comments:
[2005-11-30 15:14:12] [EMAIL PROTECTED]
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.
Reported a gazillion of times before.
Fixed long time ago.
[2005-11-30 15:02:34] stephan dot skusa at lippe-net dot de
Description:
The call of test() results into an endless loop. The first for() works
well, the for() in the function is the problem.
And the Problem appears even if the first for() is left out.
Reproduce code:
---
?PHP
$arr = array ('a' = 1, 'c' = 2);
for (reset ($arr); $key = key ($arr); next ($arr)) {
echo $key;
}
echo PING;
function test() {
global $arr;
for (reset ($arr); $key = key ($arr); next ($arr)) {
echo $key;
}
}
test();
?
Expected result:
Output of acPINGac
Actual result:
--
Endless Loop
Output of acPINGa ... to be continued
--
Edit this bug report at http://bugs.php.net/?id=35491edit=1
#35491 [Bgs]: Nice missbehaviour using arrays in functions.
ID: 35491
Updated by: [EMAIL PROTECTED]
Reported By: stephan dot skusa at lippe-net dot de
Status: Bogus
Bug Type: Arrays related
Operating System: Linux
PHP Version: 4.4.1
New Comment:
http://bugs.php.net/bug.php?id=35444
http://bugs.php.net/bug.php?id=35374
http://bugs.php.net/bug.php?id=35095
http://bugs.php.net/bug.php?id=35092
http://bugs.php.net/bug.php?id=35084
http://bugs.php.net/bug.php?id=35067
http://bugs.php.net/bug.php?id=35084
Most likely you didn't even try to find it.
Previous Comments:
[2005-11-30 15:37:42] stephan dot skusa at lippe-net dot de
I didn't found an equal bug description.
Not everybody describes a bug the same way, maybe that's the reason!
[2005-11-30 15:14:12] [EMAIL PROTECTED]
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.
Reported a gazillion of times before.
Fixed long time ago.
[2005-11-30 15:02:34] stephan dot skusa at lippe-net dot de
Description:
The call of test() results into an endless loop. The first for() works
well, the for() in the function is the problem.
And the Problem appears even if the first for() is left out.
Reproduce code:
---
?PHP
$arr = array ('a' = 1, 'c' = 2);
for (reset ($arr); $key = key ($arr); next ($arr)) {
echo $key;
}
echo PING;
function test() {
global $arr;
for (reset ($arr); $key = key ($arr); next ($arr)) {
echo $key;
}
}
test();
?
Expected result:
Output of acPINGac
Actual result:
--
Endless Loop
Output of acPINGa ... to be continued
--
Edit this bug report at http://bugs.php.net/?id=35491edit=1
#35428 [Fbk-Opn]: crash when using mysqli with MySQL 5.0.16
ID: 35428 User updated by: marcing at smlw dot pl Reported By: marcing at smlw dot pl -Status: Feedback +Status: Open Bug Type: MySQLi related Operating System: WinXP SP2 PHP Version: 5CVS-2005-11-28 (snap) Assigned To: georg New Comment: The size is unchanged, the bug still exists, so where is the difference? Previous Comments: [2005-11-30 14:49:26] [EMAIL PROTECTED] Why do you think it's unchanged? The url is the same, while file is regenerated every time. [2005-11-30 14:47:43] [EMAIL PROTECTED] No, nothing. Don't bother, it's fixed. And reported by dozen other people too.. [2005-11-30 14:45:16] marcing at smlw dot pl What's the point of checking the same and unchanged file again? [2005-11-30 14:02:48] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip [2005-11-29 01:55:17] [EMAIL PROTECTED] Assigned to the maintainer. 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/35428 -- Edit this bug report at http://bugs.php.net/?id=35428edit=1
#35488 [Bgs-Opn]: serialize() segmentation fault
ID: 35488 User updated by: kenashkov at gmail dot com Reported By: kenashkov at gmail dot com -Status: Bogus +Status: Open Bug Type: *General Issues Operating System: Fedora Core 4 PHP Version: 4.4.1 New Comment: Quote from the docs of the function serialize(): You can even serialize() arrays that contain references to itself. References inside the array/object you are serialize()ing will also be stored. Previous Comments: [2005-11-30 14:03:31] [EMAIL PROTECTED] Don't use references with serialize(). [2005-11-30 13:58:20] kenashkov at gmail dot com Description: Segmentation fault when serializing multidimentional recursive arrays. The code below works fine with 4.3.11 (again on FC4). When the argument is passend by reference (which is deprecated): print_r(unserialize(serialize($arr1))); it is fine. Or passing a reference: print_r(unserialize(serialize($ref=$arr1))); also works. No problem with serializing just $arr1[0]=$arr; Reproduce code: --- ? $arr1[0][0] = $arr1; print_r(unserialize(serialize($arr1))); ? Expected result: Array ( [0] = Array ( [0] = Array ( [0] = Array ( [0] = Array *RECURSION* ) ) ) ) Actual result: -- Segmentation fault -- Edit this bug report at http://bugs.php.net/?id=35488edit=1
#35480 [Com]: Persistent connections + unknown column crashes
ID: 35480
Comment by: andrea at 3site dot it
Reported By: tim at komta dot com
Status: Assigned
Bug Type: PDO related
Operating System: Windows XP
PHP Version: 5CVS-2005-11-30 (snap)
Assigned To: wez
New Comment:
Hi guys, theese are two result files generated by APD for PHP 5.1.1 ...
are theese usefull ?
First crash:
#Pprof [APD] v1.0.1
caller=C:\Programmi\Apache Group\Apache2\htdocs\test.php
END_HEADER
! 2 C:\Programmi\Apache Group\Apache2\htdocs\test.php
3 main 2
+ 3 2 2
4 apd_set_pprof_trace 2
+ 4 2 2
@ 2 2 0 10014 7978
- 3
6 PDO-__construct 1
+ 6 2 9
@ 2 9 0 0 271419
- 6
7 PDO-prepare 1
+ 7 2 14
@ 2 14 0 0 106
- 7
8 PDOStatement-execute 1
+ 8 2 15
@ 2 15 0 0 1164
- 8
@ 2 19 0 0 27
- 2
Second crash, script launched 1 time ... but two crashes:
#Pprof [APD] v1.0.1
caller=C:\Programmi\Apache Group\Apache2\htdocs\test.php
END_HEADER
! 1 C:\Programmi\Apache Group\Apache2\htdocs\test.php
1 main 2
+ 1 1 2
2 apd_set_pprof_trace 2
+ 2 1 2
@ 0 2 0 10014 3020
- 2
4 PDO-__construct 1
+ 4 1 9
@ 1 9 0 0 7835
- 4
5 PDO-prepare 1
+ 5 1 14
@ 1 14 0 0 77
- 5
6 PDOStatement-execute 1
+ 6 1 15
@ 1 15 0 0 435
- 6
@ 1 19 0 0 22
- 1
Code used is the same of gm with apd starded:
?php
apd_set_pprof_trace();
try {
$dbo = new PDO(
'mysql:host=localhost;dbname=test',
'user',
'pass',
array(PDO::ATTR_PERSISTENT = true)
);
} catch(PDOException $e) {
echo 'Errore di connessione: '.$e-getMessage();
}
$pdostatement = $dbo-prepare('SELECT * FROM fake_table');
$pdostatement-execute();
echo 'print something';
?
Regards .
P.S. Windows XP SP2 full updated with Apache 2.0.52 and PHP 5.1.1 as
module
Previous Comments:
[2005-11-30 15:26:19] tim at komta dot com
With the snapshot linked by Sniper, the problem is still there.
Wez, I think I'm misunderstanding what you're asking...The method of
getting a backtrace that I know of (debug_backtrace()) requires PHP to
be running. The script crashes in such a way that no output ever goes
to the user agent, in spite of no output buffering.
Is there something else I should be doing?
- Tim
[2005-11-30 14:07:51] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2005-11-30 03:35:09] [EMAIL PROTECTED]
tim, can you provide a backtrace?
[2005-11-29 23:09:53] [EMAIL PROTECTED]
Georg, this seems to be the same issue caused by protocol binary
incompatibility.
[2005-11-29 23:04:24] tim at komta dot com
Oops, sorry about that, it's MySQL 5.0.15
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/35480
--
Edit this bug report at http://bugs.php.net/?id=35480edit=1
#35491 [Bgs]: Nice missbehaviour using arrays in functions.
ID: 35491
User updated by: stephan dot skusa at lippe-net dot de
Reported By: stephan dot skusa at lippe-net dot de
Status: Bogus
Bug Type: Arrays related
Operating System: Linux
PHP Version: 4.4.1
New Comment:
Not really ... but it doesn't really matter to me what you think.
Previous Comments:
[2005-11-30 15:44:11] [EMAIL PROTECTED]
http://bugs.php.net/bug.php?id=35444
http://bugs.php.net/bug.php?id=35374
http://bugs.php.net/bug.php?id=35095
http://bugs.php.net/bug.php?id=35092
http://bugs.php.net/bug.php?id=35084
http://bugs.php.net/bug.php?id=35067
http://bugs.php.net/bug.php?id=35084
Most likely you didn't even try to find it.
[2005-11-30 15:37:42] stephan dot skusa at lippe-net dot de
I didn't found an equal bug description.
Not everybody describes a bug the same way, maybe that's the reason!
[2005-11-30 15:14:12] [EMAIL PROTECTED]
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.
Reported a gazillion of times before.
Fixed long time ago.
[2005-11-30 15:02:34] stephan dot skusa at lippe-net dot de
Description:
The call of test() results into an endless loop. The first for() works
well, the for() in the function is the problem.
And the Problem appears even if the first for() is left out.
Reproduce code:
---
?PHP
$arr = array ('a' = 1, 'c' = 2);
for (reset ($arr); $key = key ($arr); next ($arr)) {
echo $key;
}
echo PING;
function test() {
global $arr;
for (reset ($arr); $key = key ($arr); next ($arr)) {
echo $key;
}
}
test();
?
Expected result:
Output of acPINGac
Actual result:
--
Endless Loop
Output of acPINGa ... to be continued
--
Edit this bug report at http://bugs.php.net/?id=35491edit=1
#35432 [Fbk-Opn]: make fails with PDO and MySQL5
ID: 35432 User updated by: mail at philipp-wagner dot com Reported By: mail at philipp-wagner dot com -Status: Feedback +Status: Open Bug Type: PDO related Operating System: SuSE Linux 8.0 PHP Version: 5CVS-2005-11-27 (snap) Assigned To: wez New Comment: Well, I thought this might be the problem (mixing of shared and static libraries)... But now the check seems to be too strict. I first tried to build with --enable-pdo=shared --with-pdo-mysql=shared,/usr/local/mysql Now I got the following error message: You've configured extension sqlite to build statically, but it depends on extension pdo, which you've configured to build shared. You either need to build sqlite shared or build pdo statically for the build to be successful. sqlite is enabled by default (I didn't specify exlicitly specify pdo sqlite support as a configure option). ./configure --help doesn't say anything about an option like --with-pdo-sqlite, but I tried to use it anyways (or what else should I do to specify shared pdo sqlite support?). So I ran ./configure with --with-pdo-sqlite=shared This worked out quite well at first, configure gave me an output like checking for sqlite 3 driver for PDO... yes, shared But then, a bit further down, I got the error message again: checking for PDO includes... (cached) /usr/local/src/php5.1-200511301330/ext checking for lemon... no configure: warning: lemon versions supported for regeneration of libsqlite parsers: 1.0 (found: none). configure: error: You've configured extension sqlite to build statically, but it depends on extension pdo, which you've configured to build shared. You either need to build sqlite shared or build pdo statically for the build to be successful. I actually think, if you specify --enable-pdo=shared, all pdo submodules should also be built shared, as it reduces confusion and is the only way to get a working build anyways (it seems it is not possible to mix shared and static pdo libraries, so there's no need to specify it seperately). Also, the documentation doesn't say anything about how to build the specific PDO modules. It just suggests building PDO with --enable-pdo=shared, but doesn't say which configure options to use for MySQL PDO support etc. (I just got it from the ./configure --help output), and also doesn't mention the shared problem. Previous Comments: [2005-11-30 05:48:21] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip Please try the next PHP 5.1 snapshot. It features an improved error message that should catch conflicting configure options. [2005-11-28 17:53:13] mail at philipp-wagner dot com Yes, I see that now too, but it's not a problem for MySQL, as /usr/local/mysql is the prefix (it's a MySQL binary .tar.gz distribution). [2005-11-27 23:43:30] [EMAIL PROTECTED] One note about your usage of the configure options: There aren't any options that expect the path to the libraries. Every single one of them expects the install prefix. In most cases it's either /usr or /usr/local and not /usr/lib or /usr/local/lib.. [2005-11-27 22:40:17] [EMAIL PROTECTED] Wez, one more for you. [2005-11-27 22:31:06] mail at philipp-wagner dot com Description: I get the same error as in bug #34939 with PHP 5.1.0 (official release) and also today's snapshot release. During the final linking process of make, I get the following error: ext/pdo_mysql/.libs/pdo_mysql.o: In function `zm_startup_pdo_mysql': /usr/local/src/php5-200511271530/ext/pdo_mysql/pdo_mysql.c:78: undefined referen ce to `php_pdo_declare_long_constant' /usr/local/src/php5-200511271530/ext/pdo_mysql/pdo_mysql.c:79: undefined referen ce to `php_pdo_declare_long_constant' /usr/local/src/php5-200511271530/ext/pdo_mysql/pdo_mysql.c:80: undefined referen ce to `php_pdo_declare_long_constant' /usr/local/src/php5-200511271530/ext/pdo_mysql/pdo_mysql.c:81: undefined referen ce to `php_pdo_declare_long_constant' /usr/local/src/php5-200511271530/ext/pdo_mysql/pdo_mysql.c:82: undefined referen ce to `php_pdo_declare_long_constant' /usr/local/src/php5-200511271530/ext/pdo_mysql/pdo_mysql.c:84: undefined referen ce to `php_pdo_register_driver' ext/pdo_mysql/.libs/pdo_mysql.o: In function `zm_shutdown_pdo_mysql': /usr/local/src/php5-200511271530/ext/pdo_mysql/pdo_mysql.c:92: undefined referen ce to `php_pdo_unregister_driver' ext/pdo_mysql/.libs/mysql_driver.o: In function `_pdo_mysql_error':
#35480 [Com]: Persistent connections + unknown column crashes
ID: 35480
Comment by: andrea at 3site dot it
Reported By: tim at komta dot com
Status: Assigned
Bug Type: PDO related
Operating System: Windows XP
PHP Version: 5CVS-2005-11-30 (snap)
Assigned To: wez
New Comment:
Hi guys, it's me again :-)
MySQL used version for over debug was MySQL 4.1.9-nt ... but maybe the
problem is for the constant PDO::ATTR_PERSISTENT that creates some
problems on windows and Apache ...
in sqlite, 2 or 3 default version, is the same .. in a different way,
if I try to connect with PDO::ATTR_PERSISTENT = true the database will
be undeletable and I need to stop Apache (with a crash) ... and then I
can delete my files.
It doesn't happen without PDO::ATTR_PERSISTENT during connection ...
but I wonder in a :memory: connection what should happen ... fear !
:oVVoVe:
Now this is the code:
?php
$dbfile1 = 'sqlite2.sql';
$dbfile2 = 'sqlite3.sql';
$sqlite = new PDO('sqlite2:'.$dbfile1, '', '',
array(PDO::ATTR_PERSISTENT = true));
unset($sqlite);
$sqlite = new PDO('sqlite:'.$dbfile2, '', '',
array(PDO::ATTR_PERSISTENT = true));
unset($sqlite);
unlink($dbfile1);
unlink($dbfile2);
?
Regards
Previous Comments:
[2005-11-30 16:07:45] andrea at 3site dot it
Hi guys, theese are two result files generated by APD for PHP 5.1.1 ...
are theese usefull ?
First crash:
#Pprof [APD] v1.0.1
caller=C:\Programmi\Apache Group\Apache2\htdocs\test.php
END_HEADER
! 2 C:\Programmi\Apache Group\Apache2\htdocs\test.php
3 main 2
+ 3 2 2
4 apd_set_pprof_trace 2
+ 4 2 2
@ 2 2 0 10014 7978
- 3
6 PDO-__construct 1
+ 6 2 9
@ 2 9 0 0 271419
- 6
7 PDO-prepare 1
+ 7 2 14
@ 2 14 0 0 106
- 7
8 PDOStatement-execute 1
+ 8 2 15
@ 2 15 0 0 1164
- 8
@ 2 19 0 0 27
- 2
Second crash, script launched 1 time ... but two crashes:
#Pprof [APD] v1.0.1
caller=C:\Programmi\Apache Group\Apache2\htdocs\test.php
END_HEADER
! 1 C:\Programmi\Apache Group\Apache2\htdocs\test.php
1 main 2
+ 1 1 2
2 apd_set_pprof_trace 2
+ 2 1 2
@ 0 2 0 10014 3020
- 2
4 PDO-__construct 1
+ 4 1 9
@ 1 9 0 0 7835
- 4
5 PDO-prepare 1
+ 5 1 14
@ 1 14 0 0 77
- 5
6 PDOStatement-execute 1
+ 6 1 15
@ 1 15 0 0 435
- 6
@ 1 19 0 0 22
- 1
Code used is the same of gm with apd starded:
?php
apd_set_pprof_trace();
try {
$dbo = new PDO(
'mysql:host=localhost;dbname=test',
'user',
'pass',
array(PDO::ATTR_PERSISTENT = true)
);
} catch(PDOException $e) {
echo 'Errore di connessione: '.$e-getMessage();
}
$pdostatement = $dbo-prepare('SELECT * FROM fake_table');
$pdostatement-execute();
echo 'print something';
?
Regards .
P.S. Windows XP SP2 full updated with Apache 2.0.52 and PHP 5.1.1 as
module
[2005-11-30 15:26:19] tim at komta dot com
With the snapshot linked by Sniper, the problem is still there.
Wez, I think I'm misunderstanding what you're asking...The method of
getting a backtrace that I know of (debug_backtrace()) requires PHP to
be running. The script crashes in such a way that no output ever goes
to the user agent, in spite of no output buffering.
Is there something else I should be doing?
- Tim
[2005-11-30 14:07:51] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2005-11-30 03:35:09] [EMAIL PROTECTED]
tim, can you provide a backtrace?
[2005-11-29 23:09:53] [EMAIL PROTECTED]
Georg, this seems to be the same issue caused by protocol binary
incompatibility.
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/35480
--
Edit this bug report at http://bugs.php.net/?id=35480edit=1
#35493 [NEW]: mssql_query return values varies from version to version
From: martin at malditainternet dot com
Operating system: linux
PHP version: 4.4.1
PHP Bug Type: MSSQL related
Bug description: mssql_query return values varies from version to version
Description:
The return value of mssql_query is different from version to version when
there aren't rows to return. For example:
PHP: 4.4.2RC2-dev (from snap)
Query (select * from sysobjects where name='nonexistant') ret: 5
PHP: 5.0.5-3 (Debian)
Query (select * from sysobjects where name='nonexistant') ret: Resource id
#5
PHP: 4.4.1-0.dotdeb.3 (Debian - Dotdeb)
Query (select * from sysobjects where name='nonexistant') ret: 1
PHP: 4.4.0-4 (Debian)
Query (select * from sysobjects where name='nonexistant') ret: Resource id
#5
Reproduce code:
---
?
mssql_connect('HOST','USER','password');
mssql_select_db('TNS_1_3_SPIDER');
$q=select * from sysobjects where name='nonexistant';
print 'PHP: '.phpversion().\n.Query ($q) ret: .mssql_query($q).\n;
?
Expected result:
I would love to get 'Resources' instead of integers
--
Edit bug report at http://bugs.php.net/?id=35493edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=35493r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=35493r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=35493r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=35493r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=35493r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=35493r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=35493r=needscript
Try newer version:http://bugs.php.net/fix.php?id=35493r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=35493r=support
Expected behavior:http://bugs.php.net/fix.php?id=35493r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=35493r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=35493r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=35493r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35493r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=35493r=dst
IIS Stability:http://bugs.php.net/fix.php?id=35493r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=35493r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=35493r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=35493r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=35493r=mysqlcfg
#35410 [Opn-Asn]: Strange behavior of function wddx_deserialize
ID: 35410
Updated by: [EMAIL PROTECTED]
Reported By: thomas dot werner at mac dot com
-Status: Open
+Status: Assigned
Bug Type: WDDX related
-Operating System: Linux / MacOSX
+Operating System: *
-PHP Version: 4.4.1
+PHP Version: 5CVS, 4CVS (2005-11-30) (cvs)
-Assigned To:
+Assigned To: iliaa
New Comment:
Assigned to the one who broke it. :)
Previous Comments:
[2005-11-28 09:03:06] thomas dot werner at mac dot com
what does it mean? a bug or a new feature? feature because
you wrote the behaviour changed ...
[2005-11-26 18:55:20] [EMAIL PROTECTED]
I looked into this a bit deeper and it appears that the behaviour
changed when fixing #34068. The patch can be seen at
http://cvs.php.net/diff.php/php-src/ext/wddx/wddx.c?ws=0r1=1.119r2=1.120ty=u.
[2005-11-26 18:32:57] thomas dot werner at mac dot com
PHP 5.0.4/5.0.5 on mac and 5.0.5 on linux outputs the same
like 4.4.0. I guess, this behavior beguns with the fast
fixes of PHP file-upload/$GLOBALS overwrite vulnerability, but
i'm not shure, or another fix introduced in 4.4.1. maybe the
xml-parser thinks, oh its a number, not a string and convert
it to integer, but its out of range... i know only, my php-app
worked over years :o)
[2005-11-26 18:11:43] [EMAIL PROTECTED]
PHP 5.1.0 on Linux compiled with ./configure --enable-wddx gives me the
following results that are again different from the 4.4.1 and 4.4.0
results:
array(1) {
[content_queries]=
array(1) {
[content_113300831086270200]=
array(1) {
[-2147483648]=
array(3) {
[max]=
int(10)
[cache]=
int(4)
[order]=
array(1) {
[content_113300831086270200]=
array(1) {
[CMS_BUILD]=
string(4) desc
}
}
}
}
}
}
[2005-11-26 17:11:23] thomas dot werner at mac dot com
Description:
I have a wddx file:
***
wddxpacket version=1.0
header
commentContent Configuration File/comment
/header
data
struct
var name=content_queries
struct
var name=content_113300831086270200
struct
var name=113301888545229100
struct
var name=max
number10/number
/var
var name=cache
number4/number
/var
var name=order
struct
var
name=content_113300831086270200
struct
var name=CMS_BUILD
stringdesc/string
/var
/struct
/var
/struct
/var
/struct
/var
/struct
/var
/struct
/var
/struct
/data
/wddxpacket
and load it with the function wddx_deserialize in $config.
var_dump outputs different arrays in php-4.4.0 and
php-4.4.1.
[113301888545229100] (4.4.0) and [2147483647] (4.4.1) are
not the same (string vs. int).
i used exact the same configuration for compiling and
checked it with debian sarge on linux and macosx too.
cheers tom
Reproduce code:
---
[...]
if ( !( $filepointer = @fopen( $filename, 'r' ) ) ) {
return false;
}
while ( !feof( $filepointer) ) {
$data .= fgets( $filepointer, 4096 );
}
fclose( $filepointer );
if ( $data ) {
$config = wddx_deserialize( $data );
[...]
Expected result:
[...]
[content_queries]=
array(1) {
[content_113300831086270200]=
array(1) {
[113301888545229100]=
array(3) {
[max]=
int(10)
[cache]=
int(4)
[order]=
array(1) {
[content_113300831086270200]=
array(1) {
[CMS_BUILD]=
string(4) desc
}
}
}
}
}
[...]
Actual result:
--
[...]
[content_queries]=
array(1) {
[content_113300831086270200]=
array(1) {
[2147483647]=
[...]
2147483647 is not right...
--
Edit this bug report at http://bugs.php.net/?id=35410edit=1
#35494 [NEW]: Array merge problem
From: marek dot rybar at dial dot sk Operating system: Windows, Linux PHP version: 5.1.1 PHP Bug Type: Arrays related Bug description: Array merge problem Description: When I merge two arrays using + operator, result is array only with the first array elements. Reproduce code: --- $arr1 = array(1, 2, 3); $arr2 = array(5, 6, 7); $arr = $arr1 + $arr2; result $arr: array(1, 2, 3) -- Edit bug report at http://bugs.php.net/?id=35494edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=35494r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=35494r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=35494r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=35494r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=35494r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=35494r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=35494r=needscript Try newer version:http://bugs.php.net/fix.php?id=35494r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=35494r=support Expected behavior:http://bugs.php.net/fix.php?id=35494r=notwrong Not enough info: http://bugs.php.net/fix.php?id=35494r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=35494r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=35494r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35494r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=35494r=dst IIS Stability:http://bugs.php.net/fix.php?id=35494r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=35494r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=35494r=float No Zend Extensions: http://bugs.php.net/fix.php?id=35494r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=35494r=mysqlcfg
#35103 [Asn-Csd]: mysqli bind_result incorrectly handles unsigned int
ID: 35103 Updated by: [EMAIL PROTECTED] Reported By: php at pjberkel dot com -Status: Assigned +Status: Closed Bug Type: MySQLi related Operating System: * PHP Version: 5CVS-2005-11-04 (cvs) Assigned To: andrey New Comment: 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. Previous Comments: [2005-11-21 21:52:34] [EMAIL PROTECTED] I have a fix for this problem as well as speedup of the current code that handles unsigned ints on 32bit but I will push it after 5.1.0 is released because it's a bit too late in the release cycle. [2005-11-15 18:37:22] [EMAIL PROTECTED] I am taking care of this problem. Thanks! [2005-11-10 08:54:25] [EMAIL PROTECTED] Andrey, really REALLY big ints don't work yet! :) [2005-11-10 04:36:13] php at pjberkel dot com I compiled the latest CVS snapshot from the 5.1 branch (php5-200511100130) and can confirm that the problem has been fixed for 32bit unsigned INT values. However, I also did some further testing using the unsigned BIGINT data type (which contain 64bit integer values) and discovered the same problem exists for unsigned values larger than the maximum signed 64bit value: (9223372036854775807 int = 18446744073709551615) (BTW I'm using http://dev.mysql.com/doc/refman/5.0/en/numeric-types.html as a reference page for MySQL numerical types.) Changing the following two lines in the original reproduce code fragment: $mysqli-query(CREATE TABLE temp (id BIGINT UNSIGNED NOT NULL)); $mysqli-query(INSERT INTO temp (id) VALUES (9223372036854775807),(9223372036854775808),(18446744073709551614),(18446744073709551615)); Expected result: string(19) 9223372036854775807 string(19) 9223372036854775808 string(20) 18446744073709551614 string(20) 18446744073709551615 Actual result: -- string(19) 9223372036854775807 string(20) -9223372036854775808 int(-2) int(-1) I don't want to push the envelope too much on this as I guess it would be extremely rare for anyone to encounter this bug, but if there is a quick, easy solution then it's probably a good idea to fix the unsigned BIGINT problem too. Any plans to backport this to the 5.0.x branch? Thanks [2005-11-09 14:44:17] [EMAIL PROTECTED] Hi, this has been addressed in the 5.1 branch. So far HEAD (6.0) is not patched, neither 5.0. Fixed is that a value from PS if the platform is 32bit and the type is int(11) unsigned and if the value is MAX_INT a string will be returned. If the value = MAX_INT an int will be returned. I know it's not nice to have different types but these are the limitations of PHP. In year or 2 most servers will run on 64bit :) Regarding the types returned. mysqli_query() always returns strings which is not that quite efficient in terms of memory consumption but the underlying libmysql functions return strings. It's matter of choice whether this can be optimized (by using more CPU cycles to reduce memory consumption). 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/35103 -- Edit this bug report at http://bugs.php.net/?id=35103edit=1
#35494 [Opn-Bgs]: Array merge problem
ID: 35494 Updated by: [EMAIL PROTECTED] Reported By: marek dot rybar at dial dot sk -Status: Open +Status: Bogus Bug Type: Arrays related Operating System: Windows, Linux PHP Version: 5.1.1 New Comment: Expected behaviour. Use array_merge_recursive() to get the result you expect. Previous Comments: [2005-11-30 17:20:41] marek dot rybar at dial dot sk Description: When I merge two arrays using + operator, result is array only with the first array elements. Reproduce code: --- $arr1 = array(1, 2, 3); $arr2 = array(5, 6, 7); $arr = $arr1 + $arr2; result $arr: array(1, 2, 3) -- Edit this bug report at http://bugs.php.net/?id=35494edit=1
#34089 [Fbk-Opn]: Configure fails build test for libxml2
ID: 34089 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: Mac OS X 10.4.2 PHP Version: 6CVS-2005-10-07 New Comment: Tried that CVS snapshot with the following config line: ./configure --with-layout=PHP --prefix=/usr/local/php/6.0.0 --disable-all --with-icu-dir=/usr/local/icu It configures, makes, and make installs just fine. But it still says the library isn't loaded: ramsey:~ ramsey$ /usr/local/php/6.0.0/bin/php -v dyld: Library not loaded: libicui18n.dylib.34 Referenced from: /usr/local/php/6.0.0/bin/php Reason: image not found Trace/BPT trap Previous Comments: [2005-11-30 00:52:49] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php6.0-latest.tar.gz For Windows: http://snaps.php.net/win32/php6.0-win32-latest.zip [2005-10-07 21:38:20] [EMAIL PROTECTED] I've just updated my checkout and tried to rebuild it. I'm still getting the Library not loaded errors, though. I don't have access to another MacOSX machine. Is there someone else who can try to build this on their Mac to verify whether this issue can be reproduced? [2005-09-16 12:31:41] [EMAIL PROTECTED] Can you reproduce this on some other Macosx machine? Can someone else reproduce this? [2005-09-15 23:20:58] [EMAIL PROTECTED] I grabbed the latest HEAD and I'm using the latest ICU (v3.4). With the following config line, everything configures, makes, and make installs just fine: ./configure --with-layout=PHP --prefix=/usr/local/php/6.0.0 --disable-all --with-icu-dir=/usr/local/icu However, I still receive an error: ramsey:~ ramsey$ /usr/local/php/6.0.0/bin/php -i dyld: Library not loaded: libicui18n.dylib.34 Referenced from: /usr/local/php/6.0.0/bin/php Reason: image not found Trace/BPT trap [2005-09-13 09:54:19] [EMAIL PROTECTED] Try with newer icu release and latest CVS HEAD. 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/34089 -- Edit this bug report at http://bugs.php.net/?id=34089edit=1
#35432 [Opn-Asn]: make fails with PDO and MySQL5
ID: 35432 Updated by: [EMAIL PROTECTED] Reported By: mail at philipp-wagner dot com -Status: Open +Status: Assigned Bug Type: PDO related Operating System: SuSE Linux 8.0 PHP Version: 5CVS-2005-11-27 (snap) Assigned To: wez New Comment: Wez, so, enabling by default is good thing? Hint: You should always use --disable-all :) Previous Comments: [2005-11-30 16:25:12] mail at philipp-wagner dot com Well, I thought this might be the problem (mixing of shared and static libraries)... But now the check seems to be too strict. I first tried to build with --enable-pdo=shared --with-pdo-mysql=shared,/usr/local/mysql Now I got the following error message: You've configured extension sqlite to build statically, but it depends on extension pdo, which you've configured to build shared. You either need to build sqlite shared or build pdo statically for the build to be successful. sqlite is enabled by default (I didn't specify exlicitly specify pdo sqlite support as a configure option). ./configure --help doesn't say anything about an option like --with-pdo-sqlite, but I tried to use it anyways (or what else should I do to specify shared pdo sqlite support?). So I ran ./configure with --with-pdo-sqlite=shared This worked out quite well at first, configure gave me an output like checking for sqlite 3 driver for PDO... yes, shared But then, a bit further down, I got the error message again: checking for PDO includes... (cached) /usr/local/src/php5.1-200511301330/ext checking for lemon... no configure: warning: lemon versions supported for regeneration of libsqlite parsers: 1.0 (found: none). configure: error: You've configured extension sqlite to build statically, but it depends on extension pdo, which you've configured to build shared. You either need to build sqlite shared or build pdo statically for the build to be successful. I actually think, if you specify --enable-pdo=shared, all pdo submodules should also be built shared, as it reduces confusion and is the only way to get a working build anyways (it seems it is not possible to mix shared and static pdo libraries, so there's no need to specify it seperately). Also, the documentation doesn't say anything about how to build the specific PDO modules. It just suggests building PDO with --enable-pdo=shared, but doesn't say which configure options to use for MySQL PDO support etc. (I just got it from the ./configure --help output), and also doesn't mention the shared problem. [2005-11-30 05:48:21] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip Please try the next PHP 5.1 snapshot. It features an improved error message that should catch conflicting configure options. [2005-11-28 17:53:13] mail at philipp-wagner dot com Yes, I see that now too, but it's not a problem for MySQL, as /usr/local/mysql is the prefix (it's a MySQL binary .tar.gz distribution). [2005-11-27 23:43:30] [EMAIL PROTECTED] One note about your usage of the configure options: There aren't any options that expect the path to the libraries. Every single one of them expects the install prefix. In most cases it's either /usr or /usr/local and not /usr/lib or /usr/local/lib.. [2005-11-27 22:40:17] [EMAIL PROTECTED] Wez, one more for you. 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/35432 -- Edit this bug report at http://bugs.php.net/?id=35432edit=1
#35029 [Com]: segmentation faults with multiple include virtual requests
ID: 35029 Comment by: minnoce at polito dot it Reported By: markus-php at anthill dot de Status: Feedback Bug Type: Apache2 related Operating System: linux / solaris PHP Version: 4.4.0 New Comment: Apache compile configuration: ./configure \ --prefix=/services/apache_so-2.0.54 \ --enable-modules='rewrite so speling ssl' \ --disable-userdir PHP compile configuration: ./configure \ --prefix=/services/php-4.4-CVS \ --with-apxs2=/services/apache/bin/apxs \ --with-openssl \ --with-config-file-path=/services/httpd/conf \ --with-mysql=/usr \ --with-zlib \ --with-gd \ --with-jpeg-dir \ --with-png-dir \ --with-ldap \ --with-freetype-dir \ --with-mcrypt=/services/libmcrypt \ --with-curl \ --with-freetds=/services/freetds \ --enable-mbstring Example pages: - test.html html body !--#include virtual=test.php -- !--#include virtual=test.php -- /body /html - test.php ? echo 'TEST'; ? With only one include virtual all works fine. With the two include virtual the Apache child process associated exit with segmentation fault after the output of the first include. At this moment I don't be able to provide GDB backtrace... Previous Comments: [2005-11-30 14:07:17] [EMAIL PROTECTED] Provide a short reproduce case and the GDB backtrace if you still able to replicate it. [2005-11-30 13:55:46] minnoce at polito dot it Same problem also with PHP 5.1 LATEST from CVS. [2005-11-30 12:36:07] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip [2005-11-30 11:28:25] minnoce at polito dot it I have the same problem under this platform: - Red Hat Enterprise Linux 4 (i386) fully updated - Apache 2.0.55 compiled from sources - PHP 4.3.11 / 4.4.1 / LATEST 4.4 from CVS compiled from sources The bug is NOT present under Apache 2.0.54. [2005-11-15 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/35029 -- Edit this bug report at http://bugs.php.net/?id=35029edit=1
#35495 [NEW]: feof() does not report EOF on a zero file
From: dsp at tdcspace dot dk
Operating system: linux/win
PHP version: 4.4.1
PHP Bug Type: *General Issues
Bug description: feof() does not report EOF on a zero file
Description:
feof() does not report eof on a zero (0) length file
following code (similar to the ex. in the php manual) does
act like a new record was read - allthouh the file IS at eof.
$handle = @fopen(xxx, r);
while (!feof($handle)) {
$buffer = fgets($handle, 4096);
echo $buffer;
}
fclose($handle);
--
Edit bug report at http://bugs.php.net/?id=35495edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=35495r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=35495r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=35495r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=35495r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=35495r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=35495r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=35495r=needscript
Try newer version:http://bugs.php.net/fix.php?id=35495r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=35495r=support
Expected behavior:http://bugs.php.net/fix.php?id=35495r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=35495r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=35495r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=35495r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35495r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=35495r=dst
IIS Stability:http://bugs.php.net/fix.php?id=35495r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=35495r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=35495r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=35495r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=35495r=mysqlcfg
#35495 [Opn-Fbk]: feof() does not report EOF on a zero file
ID: 35495
Updated by: [EMAIL PROTECTED]
Reported By: dsp at tdcspace dot dk
-Status: Open
+Status: Feedback
-Bug Type: *General Issues
+Bug Type: Filesystem function related
Operating System: linux/win
PHP Version: 4.4.1
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
Previous Comments:
[2005-11-30 18:30:52] dsp at tdcspace dot dk
Description:
feof() does not report eof on a zero (0) length file
following code (similar to the ex. in the php manual) does
act like a new record was read - allthouh the file IS at eof.
$handle = @fopen(xxx, r);
while (!feof($handle)) {
$buffer = fgets($handle, 4096);
echo $buffer;
}
fclose($handle);
--
Edit this bug report at http://bugs.php.net/?id=35495edit=1
#35379 [Fbk-Opn]: PDO shared fails to link sqllite extension
ID: 35379 User updated by: phyre at rogers dot com Reported By: phyre at rogers dot com -Status: Feedback +Status: Open Bug Type: PDO related Operating System: Debian Linux 3.1 PHP Version: 5.1.0 Assigned To: wez New Comment: Just typed a huge comment but bugzilla lost it... so the summary... Adding --without-pdo-sqlite still returns the message. Adding --without-sqlite still returns the message. Adding both makes configure work just right. HOWEVER, this disables the sqlite_* functions. These should be based on sqlite v2 and the PDO on sqlite v3. So in doing so are we discouraging sqlite_* functions? Is there no way to maintain both, while the manual for PDO encourages shared so it can be updated from PECL easily? Especially since they're different versions? Also note sqlitev2 is enabled by default in php5, so it's something that is depended on in some cases. Also, the message really isn't that informative: You've configured extension pdo_sqlite to build statically, but it depends on extension pdo, which you've configured to build shared. You either need to build pdo_sqlite shared or build pdo statically for the build to be successful. We may be better of referencing a specific configure option to provide a bit more detail on the matter. Previous Comments: [2005-11-30 05:48:48] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip Please try the next PHP 5.1 snapshot. It features an improved error message that should catch conflicting configure options. [2005-11-25 15:26:45] jstienstra at welnet dot nl building pdo shared does not work with pdo-sqlite v3 and sqlite v2. disabling these modules with --without-pdo-sqlite and without-sqlite fixes it, or build pdo statically. see my double post (sorry about that): http://bugs.php.net/bug.php?id=35396 [2005-11-25 05:21:31] phyre at rogers dot com ./configure --with-apxs2=/usr/bin/apxs2 --disable-debug --prefix=/usr/local --with-pear --with-config-file-path=/etc/php5/apache2 --enable-discard-path --enable-memory-limit --enable-inline-optimization --enable-ipv6 --disable-posix --with-zlib --with-mhash --with-mcrypt --with-mysql=/usr --with-mysqli --with-pgsql --enable-ftp --with-curl --with-gd --enable-gd-native-ttf --enable-bcmath --with-openssl --disable-rpath --with-mysql-sock=/var/run/mysqld/mysql.sock --with-imap --with-imap-ssl --with-zip --with-jpeg-dir=/usr --with-png-dir=/usr --with-tiff-dir=/usr --with-freetype-dir=/usr --enable-exif --enable-cli --with-kerberos --enable-soap --with-pspell --with-bz2 --with-gettext --enable-pdo=shared I also tried disabling the pdo_sqlite but that didn't seem to help, as it still builds the sqlite2 pdo module. [2005-11-25 05:09:23] [EMAIL PROTECTED] What was your configure line? [2005-11-25 04:16:51] phyre at rogers dot com Description: Using --enable-pdo=shared (as recommended in the documentation for php5.1) in configure and then making gets through the pdo compilation, but on linking has unresolved references Reproduce code: --- configure, compile Expected result: Probably should automatically build pdo_sqlite shared as well. Actual result: -- undefined reference to `php_pdo_register_driver' errors and similar as a result of it being shared when linking php cli and apache module. -- Edit this bug report at http://bugs.php.net/?id=35379edit=1
#35495 [Fbk-Opn]: feof() does not report EOF on a zero file
ID: 35495
User updated by: dsp at tdcspace dot dk
Reported By: dsp at tdcspace dot dk
-Status: Feedback
+Status: Open
Bug Type: Filesystem function related
Operating System: linux/win
PHP Version: 4.4.1
New Comment:
is there a cvs for 4.4.1
Previous Comments:
[2005-11-30 18:33:15] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2005-11-30 18:30:52] dsp at tdcspace dot dk
Description:
feof() does not report eof on a zero (0) length file
following code (similar to the ex. in the php manual) does
act like a new record was read - allthouh the file IS at eof.
$handle = @fopen(xxx, r);
while (!feof($handle)) {
$buffer = fgets($handle, 4096);
echo $buffer;
}
fclose($handle);
--
Edit this bug report at http://bugs.php.net/?id=35495edit=1
#35495 [Opn-Fbk]: feof() does not report EOF on a zero file
ID: 35495
Updated by: [EMAIL PROTECTED]
Reported By: dsp at tdcspace dot dk
-Status: Open
+Status: Feedback
Bug Type: Filesystem function related
Operating System: linux/win
PHP Version: 4.4.1
New Comment:
No, try the 5.1 snapshot.
Previous Comments:
[2005-11-30 18:42:21] dsp at tdcspace dot dk
is there a cvs for 4.4.1
[2005-11-30 18:33:15] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2005-11-30 18:30:52] dsp at tdcspace dot dk
Description:
feof() does not report eof on a zero (0) length file
following code (similar to the ex. in the php manual) does
act like a new record was read - allthouh the file IS at eof.
$handle = @fopen(xxx, r);
while (!feof($handle)) {
$buffer = fgets($handle, 4096);
echo $buffer;
}
fclose($handle);
--
Edit this bug report at http://bugs.php.net/?id=35495edit=1
#35432 [Asn-Csd]: make fails with PDO and MySQL5
ID: 35432 Updated by: [EMAIL PROTECTED] Reported By: mail at philipp-wagner dot com -Status: Assigned +Status: Closed Bug Type: PDO related Operating System: SuSE Linux 8.0 PHP Version: 5CVS-2005-11-27 (snap) Assigned To: wez New Comment: You simply need to tell configure to build what you want it to build, how you want it built. --enable-pdo=shared --with-pdo-mysql=shared,/usr/local/mysql --with-sqlite=shared I know it sucks that we can't automatically make it work that way you want it; configure scripts have their limitations. Previous Comments: [2005-11-30 17:31:25] [EMAIL PROTECTED] Wez, so, enabling by default is good thing? Hint: You should always use --disable-all :) [2005-11-30 16:25:12] mail at philipp-wagner dot com Well, I thought this might be the problem (mixing of shared and static libraries)... But now the check seems to be too strict. I first tried to build with --enable-pdo=shared --with-pdo-mysql=shared,/usr/local/mysql Now I got the following error message: You've configured extension sqlite to build statically, but it depends on extension pdo, which you've configured to build shared. You either need to build sqlite shared or build pdo statically for the build to be successful. sqlite is enabled by default (I didn't specify exlicitly specify pdo sqlite support as a configure option). ./configure --help doesn't say anything about an option like --with-pdo-sqlite, but I tried to use it anyways (or what else should I do to specify shared pdo sqlite support?). So I ran ./configure with --with-pdo-sqlite=shared This worked out quite well at first, configure gave me an output like checking for sqlite 3 driver for PDO... yes, shared But then, a bit further down, I got the error message again: checking for PDO includes... (cached) /usr/local/src/php5.1-200511301330/ext checking for lemon... no configure: warning: lemon versions supported for regeneration of libsqlite parsers: 1.0 (found: none). configure: error: You've configured extension sqlite to build statically, but it depends on extension pdo, which you've configured to build shared. You either need to build sqlite shared or build pdo statically for the build to be successful. I actually think, if you specify --enable-pdo=shared, all pdo submodules should also be built shared, as it reduces confusion and is the only way to get a working build anyways (it seems it is not possible to mix shared and static pdo libraries, so there's no need to specify it seperately). Also, the documentation doesn't say anything about how to build the specific PDO modules. It just suggests building PDO with --enable-pdo=shared, but doesn't say which configure options to use for MySQL PDO support etc. (I just got it from the ./configure --help output), and also doesn't mention the shared problem. [2005-11-30 05:48:21] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip Please try the next PHP 5.1 snapshot. It features an improved error message that should catch conflicting configure options. [2005-11-28 17:53:13] mail at philipp-wagner dot com Yes, I see that now too, but it's not a problem for MySQL, as /usr/local/mysql is the prefix (it's a MySQL binary .tar.gz distribution). [2005-11-27 23:43:30] [EMAIL PROTECTED] One note about your usage of the configure options: There aren't any options that expect the path to the libraries. Every single one of them expects the install prefix. In most cases it's either /usr or /usr/local and not /usr/lib or /usr/local/lib.. 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/35432 -- Edit this bug report at http://bugs.php.net/?id=35432edit=1
#35379 [Opn-Csd]: PDO shared fails to link sqllite extension
ID: 35379 Updated by: [EMAIL PROTECTED] Reported By: phyre at rogers dot com -Status: Open +Status: Closed Bug Type: PDO related Operating System: Debian Linux 3.1 PHP Version: 5.1.0 Assigned To: wez New Comment: You simply need to tell configure to build what you want it to build, how you want it built. --enable-pdo=shared --with-pdo-sqlite=shared --with-sqlite=shared I know it sucks that we can't automatically make it work that way you want it; configure scripts have their limitations. Previous Comments: [2005-11-30 18:37:06] phyre at rogers dot com Just typed a huge comment but bugzilla lost it... so the summary... Adding --without-pdo-sqlite still returns the message. Adding --without-sqlite still returns the message. Adding both makes configure work just right. HOWEVER, this disables the sqlite_* functions. These should be based on sqlite v2 and the PDO on sqlite v3. So in doing so are we discouraging sqlite_* functions? Is there no way to maintain both, while the manual for PDO encourages shared so it can be updated from PECL easily? Especially since they're different versions? Also note sqlitev2 is enabled by default in php5, so it's something that is depended on in some cases. Also, the message really isn't that informative: You've configured extension pdo_sqlite to build statically, but it depends on extension pdo, which you've configured to build shared. You either need to build pdo_sqlite shared or build pdo statically for the build to be successful. We may be better of referencing a specific configure option to provide a bit more detail on the matter. [2005-11-30 05:48:48] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip Please try the next PHP 5.1 snapshot. It features an improved error message that should catch conflicting configure options. [2005-11-25 15:26:45] jstienstra at welnet dot nl building pdo shared does not work with pdo-sqlite v3 and sqlite v2. disabling these modules with --without-pdo-sqlite and without-sqlite fixes it, or build pdo statically. see my double post (sorry about that): http://bugs.php.net/bug.php?id=35396 [2005-11-25 05:21:31] phyre at rogers dot com ./configure --with-apxs2=/usr/bin/apxs2 --disable-debug --prefix=/usr/local --with-pear --with-config-file-path=/etc/php5/apache2 --enable-discard-path --enable-memory-limit --enable-inline-optimization --enable-ipv6 --disable-posix --with-zlib --with-mhash --with-mcrypt --with-mysql=/usr --with-mysqli --with-pgsql --enable-ftp --with-curl --with-gd --enable-gd-native-ttf --enable-bcmath --with-openssl --disable-rpath --with-mysql-sock=/var/run/mysqld/mysql.sock --with-imap --with-imap-ssl --with-zip --with-jpeg-dir=/usr --with-png-dir=/usr --with-tiff-dir=/usr --with-freetype-dir=/usr --enable-exif --enable-cli --with-kerberos --enable-soap --with-pspell --with-bz2 --with-gettext --enable-pdo=shared I also tried disabling the pdo_sqlite but that didn't seem to help, as it still builds the sqlite2 pdo module. [2005-11-25 05:09:23] [EMAIL PROTECTED] What was your configure line? 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/35379 -- Edit this bug report at http://bugs.php.net/?id=35379edit=1
#35480 [Asn-Fbk]: Persistent connections + unknown column crashes
ID: 35480
Updated by: [EMAIL PROTECTED]
Reported By: tim at komta dot com
-Status: Assigned
+Status: Feedback
Bug Type: PDO related
Operating System: Windows XP
PHP Version: 5CVS-2005-11-30 (snap)
Assigned To: wez
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
I meant a gdb backtrace for the crash.
However, I think this problem has now been resolved; please try the
next 5.1 snapshot dated after this report.
Previous Comments:
[2005-11-30 16:37:56] andrea at 3site dot it
Hi guys, it's me again :-)
MySQL used version for over debug was MySQL 4.1.9-nt ... but maybe the
problem is for the constant PDO::ATTR_PERSISTENT that creates some
problems on windows and Apache ...
in sqlite, 2 or 3 default version, is the same .. in a different way,
if I try to connect with PDO::ATTR_PERSISTENT = true the database will
be undeletable and I need to stop Apache (with a crash) ... and then I
can delete my files.
It doesn't happen without PDO::ATTR_PERSISTENT during connection ...
but I wonder in a :memory: connection what should happen ... fear !
:oVVoVe:
Now this is the code:
?php
$dbfile1 = 'sqlite2.sql';
$dbfile2 = 'sqlite3.sql';
$sqlite = new PDO('sqlite2:'.$dbfile1, '', '',
array(PDO::ATTR_PERSISTENT = true));
unset($sqlite);
$sqlite = new PDO('sqlite:'.$dbfile2, '', '',
array(PDO::ATTR_PERSISTENT = true));
unset($sqlite);
unlink($dbfile1);
unlink($dbfile2);
?
Regards
[2005-11-30 16:07:45] andrea at 3site dot it
Hi guys, theese are two result files generated by APD for PHP 5.1.1 ...
are theese usefull ?
First crash:
#Pprof [APD] v1.0.1
caller=C:\Programmi\Apache Group\Apache2\htdocs\test.php
END_HEADER
! 2 C:\Programmi\Apache Group\Apache2\htdocs\test.php
3 main 2
+ 3 2 2
4 apd_set_pprof_trace 2
+ 4 2 2
@ 2 2 0 10014 7978
- 3
6 PDO-__construct 1
+ 6 2 9
@ 2 9 0 0 271419
- 6
7 PDO-prepare 1
+ 7 2 14
@ 2 14 0 0 106
- 7
8 PDOStatement-execute 1
+ 8 2 15
@ 2 15 0 0 1164
- 8
@ 2 19 0 0 27
- 2
Second crash, script launched 1 time ... but two crashes:
#Pprof [APD] v1.0.1
caller=C:\Programmi\Apache Group\Apache2\htdocs\test.php
END_HEADER
! 1 C:\Programmi\Apache Group\Apache2\htdocs\test.php
1 main 2
+ 1 1 2
2 apd_set_pprof_trace 2
+ 2 1 2
@ 0 2 0 10014 3020
- 2
4 PDO-__construct 1
+ 4 1 9
@ 1 9 0 0 7835
- 4
5 PDO-prepare 1
+ 5 1 14
@ 1 14 0 0 77
- 5
6 PDOStatement-execute 1
+ 6 1 15
@ 1 15 0 0 435
- 6
@ 1 19 0 0 22
- 1
Code used is the same of gm with apd starded:
?php
apd_set_pprof_trace();
try {
$dbo = new PDO(
'mysql:host=localhost;dbname=test',
'user',
'pass',
array(PDO::ATTR_PERSISTENT = true)
);
} catch(PDOException $e) {
echo 'Errore di connessione: '.$e-getMessage();
}
$pdostatement = $dbo-prepare('SELECT * FROM fake_table');
$pdostatement-execute();
echo 'print something';
?
Regards .
P.S. Windows XP SP2 full updated with Apache 2.0.52 and PHP 5.1.1 as
module
[2005-11-30 15:26:19] tim at komta dot com
With the snapshot linked by Sniper, the problem is still there.
Wez, I think I'm misunderstanding what you're asking...The method of
getting a backtrace that I know of (debug_backtrace()) requires PHP to
be running. The script crashes in such a way that no output ever goes
to the user agent, in spite of no output buffering.
Is there something else I should be doing?
- Tim
[2005-11-30 14:07:51] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2005-11-30 03:35:09] [EMAIL PROTECTED]
tim, can you provide a backtrace?
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/35480
--
Edit this bug report at http://bugs.php.net/?id=35480edit=1
#35465 [Bgs-Opn]: link error Text relocation remains
ID: 35465
User updated by: rusty at socrates dot berkeley dot edu
Reported By: rusty at socrates dot berkeley dot edu
-Status: Bogus
+Status: Open
Bug Type: Compile Failure
Operating System: solaris 9
PHP Version: 5.1.1
Assigned To: sniper
New Comment:
Would you guys please pull your heads out of your and go read bug
#35475? It appears to be a bug in the libtool that you're now using.
It may not be a bug in the PHP code but it certainly is a bug in the
PHP *distribution*.
I've wiped and re-extracted the tar files and copied over the
libtool.m4 from 5.0.5 to 5.1.1 and am recompiling right now. I'll add
a comment when it finishes.
Previous Comments:
[2005-11-30 10:34:48] [EMAIL PROTECTED]
Joe, I agree, this is most likely not PHP issue, but I'm still able to
reproduce it on Solaris 8 and -fPIC doesn't help.
[2005-11-30 09:46:26] [EMAIL PROTECTED]
This is the expected failure from trying to link non-PIC code into a
shared library on most platforms. If you really insist on using a
static MySQL library you must rebuild it with -fPIC in CFLAGS.
If it worked previously I'd guess it was only because the static
libmysql.a wasn't being found.
[2005-11-29 23:35:03] rusty at socrates dot berkeley dot edu
Yes, almost all of my add-on libraries are .a files because long ago I
used to have problem with .so ones. Plus, I like to find out about any
missing symbols at compile time, not run time, which was part of the
problem I used to have.
[2005-11-29 22:58:14] [EMAIL PROTECTED]
See also bug #35475
[2005-11-29 17:19:13] rusty at socrates dot berkeley dot edu
Yes, it compiles with
./configure --disable-all --with-apxs2=/${WWWROOT}/bin/apxs
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/35465
--
Edit this bug report at http://bugs.php.net/?id=35465edit=1
#35480 [Opn-Csd]: Persistent connections + unknown column crashes
ID: 35480
Updated by: [EMAIL PROTECTED]
Reported By: tim at komta dot com
-Status: Open
+Status: Closed
Bug Type: PDO related
Operating System: Windows XP
PHP Version: 5CVS-2005-11-30 (snap)
Assigned To: wez
New Comment:
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.
Previous Comments:
[2005-11-30 19:01:11] tim at komta dot com
Yup, that seems to have fixed it, at least for MySQL.
Thanks!
Tim
[2005-11-30 18:52:00] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
I meant a gdb backtrace for the crash.
However, I think this problem has now been resolved; please try the
next 5.1 snapshot dated after this report.
[2005-11-30 16:37:56] andrea at 3site dot it
Hi guys, it's me again :-)
MySQL used version for over debug was MySQL 4.1.9-nt ... but maybe the
problem is for the constant PDO::ATTR_PERSISTENT that creates some
problems on windows and Apache ...
in sqlite, 2 or 3 default version, is the same .. in a different way,
if I try to connect with PDO::ATTR_PERSISTENT = true the database will
be undeletable and I need to stop Apache (with a crash) ... and then I
can delete my files.
It doesn't happen without PDO::ATTR_PERSISTENT during connection ...
but I wonder in a :memory: connection what should happen ... fear !
:oVVoVe:
Now this is the code:
?php
$dbfile1 = 'sqlite2.sql';
$dbfile2 = 'sqlite3.sql';
$sqlite = new PDO('sqlite2:'.$dbfile1, '', '',
array(PDO::ATTR_PERSISTENT = true));
unset($sqlite);
$sqlite = new PDO('sqlite:'.$dbfile2, '', '',
array(PDO::ATTR_PERSISTENT = true));
unset($sqlite);
unlink($dbfile1);
unlink($dbfile2);
?
Regards
[2005-11-30 16:07:45] andrea at 3site dot it
Hi guys, theese are two result files generated by APD for PHP 5.1.1 ...
are theese usefull ?
First crash:
#Pprof [APD] v1.0.1
caller=C:\Programmi\Apache Group\Apache2\htdocs\test.php
END_HEADER
! 2 C:\Programmi\Apache Group\Apache2\htdocs\test.php
3 main 2
+ 3 2 2
4 apd_set_pprof_trace 2
+ 4 2 2
@ 2 2 0 10014 7978
- 3
6 PDO-__construct 1
+ 6 2 9
@ 2 9 0 0 271419
- 6
7 PDO-prepare 1
+ 7 2 14
@ 2 14 0 0 106
- 7
8 PDOStatement-execute 1
+ 8 2 15
@ 2 15 0 0 1164
- 8
@ 2 19 0 0 27
- 2
Second crash, script launched 1 time ... but two crashes:
#Pprof [APD] v1.0.1
caller=C:\Programmi\Apache Group\Apache2\htdocs\test.php
END_HEADER
! 1 C:\Programmi\Apache Group\Apache2\htdocs\test.php
1 main 2
+ 1 1 2
2 apd_set_pprof_trace 2
+ 2 1 2
@ 0 2 0 10014 3020
- 2
4 PDO-__construct 1
+ 4 1 9
@ 1 9 0 0 7835
- 4
5 PDO-prepare 1
+ 5 1 14
@ 1 14 0 0 77
- 5
6 PDOStatement-execute 1
+ 6 1 15
@ 1 15 0 0 435
- 6
@ 1 19 0 0 22
- 1
Code used is the same of gm with apd starded:
?php
apd_set_pprof_trace();
try {
$dbo = new PDO(
'mysql:host=localhost;dbname=test',
'user',
'pass',
array(PDO::ATTR_PERSISTENT = true)
);
} catch(PDOException $e) {
echo 'Errore di connessione: '.$e-getMessage();
}
$pdostatement = $dbo-prepare('SELECT * FROM fake_table');
$pdostatement-execute();
echo 'print something';
?
Regards .
P.S. Windows XP SP2 full updated with Apache 2.0.52 and PHP 5.1.1 as
module
[2005-11-30 15:26:19] tim at komta dot com
With the snapshot linked by Sniper, the problem is still there.
Wez, I think I'm misunderstanding what you're asking...The method of
getting a backtrace that I know of (debug_backtrace()) requires PHP to
be running. The script crashes in such a way that no output ever goes
to the user agent, in spite of no output buffering.
Is there something else I should be doing?
- Tim
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/35480
--
Edit this bug report at http://bugs.php.net/?id=35480edit=1
#35465 [Com]: link error Text relocation remains
ID: 35465 Comment by: php at fiddaman dot net Reported By: rusty at socrates dot berkeley dot edu Status: Open Bug Type: Compile Failure Operating System: solaris 9 PHP Version: 5.1.1 Assigned To: sniper New Comment: I'm seeing the problem with the IMAP extension which uses the UW IMAP toolkit. Now this toolkit never compiles as a shared object (see http://www.washington.edu/imap/IMAP-FAQs/#6.3) If Rusty's unusual use of static mysql libraries is a problem, look at the IMAP extension. Previous Comments: [2005-11-30 18:54:09] rusty at socrates dot berkeley dot edu Would you guys please pull your heads out of your and go read bug #35475? It appears to be a bug in the libtool that you're now using. It may not be a bug in the PHP code but it certainly is a bug in the PHP *distribution*. I've wiped and re-extracted the tar files and copied over the libtool.m4 from 5.0.5 to 5.1.1 and am recompiling right now. I'll add a comment when it finishes. [2005-11-30 10:34:48] [EMAIL PROTECTED] Joe, I agree, this is most likely not PHP issue, but I'm still able to reproduce it on Solaris 8 and -fPIC doesn't help. [2005-11-30 09:46:26] [EMAIL PROTECTED] This is the expected failure from trying to link non-PIC code into a shared library on most platforms. If you really insist on using a static MySQL library you must rebuild it with -fPIC in CFLAGS. If it worked previously I'd guess it was only because the static libmysql.a wasn't being found. [2005-11-29 23:35:03] rusty at socrates dot berkeley dot edu Yes, almost all of my add-on libraries are .a files because long ago I used to have problem with .so ones. Plus, I like to find out about any missing symbols at compile time, not run time, which was part of the problem I used to have. [2005-11-29 22:58:14] [EMAIL PROTECTED] See also bug #35475 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/35465 -- Edit this bug report at http://bugs.php.net/?id=35465edit=1
#35483 [Fbk-Opn]: safe_mode_exec_dir
ID: 35483 User updated by: marcl at vo dot lu Reported By: marcl at vo dot lu -Status: Feedback +Status: Open Bug Type: Program Execution Operating System: Windows 2003 PHP Version: 4.4.1 New Comment: I can't execute binaries which are in safe_mode_exec_dir (safe_mode=on) I tried all variants! OK Os: Windows Server 2003 Webserver: Apache 1.3.34 ImageMagick: 6.2.5-5-Q16-windows-dll.exe php.ini: safe_mode = On safe_mode_gid = Off safe_mode_include_dir = safe_mode_exec_dir = I want to execute ImageMagick with safe_mode = On Example 1: safe_mode_exec_dir = d:/ImageMagick/ Example 2: safe_mode_exec_dir = d:/ImageMagick Example 3: safe_mode_exec_dir = d:\ImageMagick\ Example 4: safe_mode_exec_dir = d:\ImageMagick ImageMagick does not work with this examples in safe_mode =On In php error log are no entries. thanks Previous Comments: [2005-11-30 12:10:40] [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-11-30 11:58:48] marcl at vo dot lu Description: I can't execute binaries which are in safe_mode_exec_dir (safe_mode=on) I tried all variants! -- Edit this bug report at http://bugs.php.net/?id=35483edit=1
#35029 [Com]: segmentation faults with multiple include virtual requests
ID: 35029 Comment by: news at cb-world dot de Reported By: markus-php at anthill dot de Status: Feedback Bug Type: Apache2 related Operating System: linux / solaris PHP Version: 4.4.0 New Comment: same problem found in suse 9.3 mod_php4 4.3.10 and gentoo mod_php-4.4.0-r9 but seems to be fixed in latest php4 and php5-cvs (tried 10 minutes ago) Previous Comments: [2005-11-30 17:47:36] minnoce at polito dot it Apache compile configuration: ./configure \ --prefix=/services/apache_so-2.0.54 \ --enable-modules='rewrite so speling ssl' \ --disable-userdir PHP compile configuration: ./configure \ --prefix=/services/php-4.4-CVS \ --with-apxs2=/services/apache/bin/apxs \ --with-openssl \ --with-config-file-path=/services/httpd/conf \ --with-mysql=/usr \ --with-zlib \ --with-gd \ --with-jpeg-dir \ --with-png-dir \ --with-ldap \ --with-freetype-dir \ --with-mcrypt=/services/libmcrypt \ --with-curl \ --with-freetds=/services/freetds \ --enable-mbstring Example pages: - test.html html body !--#include virtual=test.php -- !--#include virtual=test.php -- /body /html - test.php ? echo 'TEST'; ? With only one include virtual all works fine. With the two include virtual the Apache child process associated exit with segmentation fault after the output of the first include. At this moment I don't be able to provide GDB backtrace... [2005-11-30 14:07:17] [EMAIL PROTECTED] Provide a short reproduce case and the GDB backtrace if you still able to replicate it. [2005-11-30 13:55:46] minnoce at polito dot it Same problem also with PHP 5.1 LATEST from CVS. [2005-11-30 12:36:07] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip [2005-11-30 11:28:25] minnoce at polito dot it I have the same problem under this platform: - Red Hat Enterprise Linux 4 (i386) fully updated - Apache 2.0.55 compiled from sources - PHP 4.3.11 / 4.4.1 / LATEST 4.4 from CVS compiled from sources The bug is NOT present under Apache 2.0.54. 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/35029 -- Edit this bug report at http://bugs.php.net/?id=35029edit=1
#35379 [Csd]: PDO shared fails to link sqllite extension
ID: 35379 User updated by: phyre at rogers dot com Reported By: phyre at rogers dot com Status: Closed Bug Type: PDO related Operating System: Debian Linux 3.1 PHP Version: 5.1.0 Assigned To: wez New Comment: I think I was misunderstood. Adding all three does work, but what I am suggesting is that we ensure that we don't create even more confusion by doing so. The logical step I went through was to grep for sqlite options. pdo_sqlite is logical, but you _ALSO_ need --with-sqlite=shared. One or the other doesn't work. So it is important to add that to the message, stating that not only does this affect pdo_sqlite, but also php's sqlite functions, so that users right away know both need to be compiled as shared. I wasn't asking for much more than that. Previous Comments: [2005-11-30 18:49:23] [EMAIL PROTECTED] You simply need to tell configure to build what you want it to build, how you want it built. --enable-pdo=shared --with-pdo-sqlite=shared --with-sqlite=shared I know it sucks that we can't automatically make it work that way you want it; configure scripts have their limitations. [2005-11-30 18:37:06] phyre at rogers dot com Just typed a huge comment but bugzilla lost it... so the summary... Adding --without-pdo-sqlite still returns the message. Adding --without-sqlite still returns the message. Adding both makes configure work just right. HOWEVER, this disables the sqlite_* functions. These should be based on sqlite v2 and the PDO on sqlite v3. So in doing so are we discouraging sqlite_* functions? Is there no way to maintain both, while the manual for PDO encourages shared so it can be updated from PECL easily? Especially since they're different versions? Also note sqlitev2 is enabled by default in php5, so it's something that is depended on in some cases. Also, the message really isn't that informative: You've configured extension pdo_sqlite to build statically, but it depends on extension pdo, which you've configured to build shared. You either need to build pdo_sqlite shared or build pdo statically for the build to be successful. We may be better of referencing a specific configure option to provide a bit more detail on the matter. [2005-11-30 05:48:48] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip Please try the next PHP 5.1 snapshot. It features an improved error message that should catch conflicting configure options. [2005-11-25 15:26:45] jstienstra at welnet dot nl building pdo shared does not work with pdo-sqlite v3 and sqlite v2. disabling these modules with --without-pdo-sqlite and without-sqlite fixes it, or build pdo statically. see my double post (sorry about that): http://bugs.php.net/bug.php?id=35396 [2005-11-25 05:21:31] phyre at rogers dot com ./configure --with-apxs2=/usr/bin/apxs2 --disable-debug --prefix=/usr/local --with-pear --with-config-file-path=/etc/php5/apache2 --enable-discard-path --enable-memory-limit --enable-inline-optimization --enable-ipv6 --disable-posix --with-zlib --with-mhash --with-mcrypt --with-mysql=/usr --with-mysqli --with-pgsql --enable-ftp --with-curl --with-gd --enable-gd-native-ttf --enable-bcmath --with-openssl --disable-rpath --with-mysql-sock=/var/run/mysqld/mysql.sock --with-imap --with-imap-ssl --with-zip --with-jpeg-dir=/usr --with-png-dir=/usr --with-tiff-dir=/usr --with-freetype-dir=/usr --enable-exif --enable-cli --with-kerberos --enable-soap --with-pspell --with-bz2 --with-gettext --enable-pdo=shared I also tried disabling the pdo_sqlite but that didn't seem to help, as it still builds the sqlite2 pdo module. 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/35379 -- Edit this bug report at http://bugs.php.net/?id=35379edit=1
#35029 [Fbk-Csd]: segmentation faults with multiple include virtual requests
ID: 35029 Updated by: [EMAIL PROTECTED] Reported By: markus-php at anthill dot de -Status: Feedback +Status: Closed Bug Type: Apache2 related Operating System: linux / solaris PHP Version: 4.4.0 New Comment: Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php Previous Comments: [2005-11-30 19:19:41] news at cb-world dot de same problem found in suse 9.3 mod_php4 4.3.10 and gentoo mod_php-4.4.0-r9 but seems to be fixed in latest php4 and php5-cvs (tried 10 minutes ago) [2005-11-30 17:47:36] minnoce at polito dot it Apache compile configuration: ./configure \ --prefix=/services/apache_so-2.0.54 \ --enable-modules='rewrite so speling ssl' \ --disable-userdir PHP compile configuration: ./configure \ --prefix=/services/php-4.4-CVS \ --with-apxs2=/services/apache/bin/apxs \ --with-openssl \ --with-config-file-path=/services/httpd/conf \ --with-mysql=/usr \ --with-zlib \ --with-gd \ --with-jpeg-dir \ --with-png-dir \ --with-ldap \ --with-freetype-dir \ --with-mcrypt=/services/libmcrypt \ --with-curl \ --with-freetds=/services/freetds \ --enable-mbstring Example pages: - test.html html body !--#include virtual=test.php -- !--#include virtual=test.php -- /body /html - test.php ? echo 'TEST'; ? With only one include virtual all works fine. With the two include virtual the Apache child process associated exit with segmentation fault after the output of the first include. At this moment I don't be able to provide GDB backtrace... [2005-11-30 14:07:17] [EMAIL PROTECTED] Provide a short reproduce case and the GDB backtrace if you still able to replicate it. [2005-11-30 13:55:46] minnoce at polito dot it Same problem also with PHP 5.1 LATEST from CVS. [2005-11-30 12:36:07] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-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/35029 -- Edit this bug report at http://bugs.php.net/?id=35029edit=1
#35465 [Opn]: link error Text relocation remains
ID: 35465 User updated by: rusty at socrates dot berkeley dot edu Reported By: rusty at socrates dot berkeley dot edu Status: Open Bug Type: Compile Failure Operating System: solaris 9 PHP Version: 5.1.1 Assigned To: sniper New Comment: 5.1.1 compiles if you use the libtool from 5.0.5. You have to copy over libtool after running configure in the 5.0.5 and 5.1.1 directories. Do not copy over libtool.m4 from the build directory and then run configure. Previous Comments: [2005-11-30 19:08:18] php at fiddaman dot net I'm seeing the problem with the IMAP extension which uses the UW IMAP toolkit. Now this toolkit never compiles as a shared object (see http://www.washington.edu/imap/IMAP-FAQs/#6.3) If Rusty's unusual use of static mysql libraries is a problem, look at the IMAP extension. [2005-11-30 18:54:09] rusty at socrates dot berkeley dot edu Would you guys please pull your heads out of your and go read bug #35475? It appears to be a bug in the libtool that you're now using. It may not be a bug in the PHP code but it certainly is a bug in the PHP *distribution*. I've wiped and re-extracted the tar files and copied over the libtool.m4 from 5.0.5 to 5.1.1 and am recompiling right now. I'll add a comment when it finishes. [2005-11-30 10:34:48] [EMAIL PROTECTED] Joe, I agree, this is most likely not PHP issue, but I'm still able to reproduce it on Solaris 8 and -fPIC doesn't help. [2005-11-30 09:46:26] [EMAIL PROTECTED] This is the expected failure from trying to link non-PIC code into a shared library on most platforms. If you really insist on using a static MySQL library you must rebuild it with -fPIC in CFLAGS. If it worked previously I'd guess it was only because the static libmysql.a wasn't being found. [2005-11-29 23:35:03] rusty at socrates dot berkeley dot edu Yes, almost all of my add-on libraries are .a files because long ago I used to have problem with .so ones. Plus, I like to find out about any missing symbols at compile time, not run time, which was part of the problem I used to have. 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/35465 -- Edit this bug report at http://bugs.php.net/?id=35465edit=1
#35483 [Opn-Bgs]: safe_mode_exec_dir
ID: 35483 Updated by: [EMAIL PROTECTED] Reported By: marcl at vo dot lu -Status: Open +Status: Bogus Bug Type: Program Execution Operating System: Windows 2003 PHP Version: 4.4.1 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Previous Comments: [2005-11-30 19:11:43] marcl at vo dot lu I can't execute binaries which are in safe_mode_exec_dir (safe_mode=on) I tried all variants! OK Os: Windows Server 2003 Webserver: Apache 1.3.34 ImageMagick: 6.2.5-5-Q16-windows-dll.exe php.ini: safe_mode = On safe_mode_gid = Off safe_mode_include_dir = safe_mode_exec_dir = I want to execute ImageMagick with safe_mode = On Example 1: safe_mode_exec_dir = d:/ImageMagick/ Example 2: safe_mode_exec_dir = d:/ImageMagick Example 3: safe_mode_exec_dir = d:\ImageMagick\ Example 4: safe_mode_exec_dir = d:\ImageMagick ImageMagick does not work with this examples in safe_mode =On In php error log are no entries. thanks [2005-11-30 12:10:40] [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-11-30 11:58:48] marcl at vo dot lu Description: I can't execute binaries which are in safe_mode_exec_dir (safe_mode=on) I tried all variants! -- Edit this bug report at http://bugs.php.net/?id=35483edit=1
#35465 [Opn-Asn]: link error Text relocation remains
ID: 35465 Updated by: [EMAIL PROTECTED] Reported By: rusty at socrates dot berkeley dot edu -Status: Open +Status: Assigned Bug Type: Compile Failure Operating System: solaris 9 PHP Version: 5.1.1 Assigned To: sniper New Comment: I would like it if people didn't bogus the reports I've assigned myself.. Previous Comments: [2005-11-30 20:04:45] rusty at socrates dot berkeley dot edu 5.1.1 compiles if you use the libtool from 5.0.5. You have to copy over libtool after running configure in the 5.0.5 and 5.1.1 directories. Do not copy over libtool.m4 from the build directory and then run configure. [2005-11-30 19:08:18] php at fiddaman dot net I'm seeing the problem with the IMAP extension which uses the UW IMAP toolkit. Now this toolkit never compiles as a shared object (see http://www.washington.edu/imap/IMAP-FAQs/#6.3) If Rusty's unusual use of static mysql libraries is a problem, look at the IMAP extension. [2005-11-30 18:54:09] rusty at socrates dot berkeley dot edu Would you guys please pull your heads out of your and go read bug #35475? It appears to be a bug in the libtool that you're now using. It may not be a bug in the PHP code but it certainly is a bug in the PHP *distribution*. I've wiped and re-extracted the tar files and copied over the libtool.m4 from 5.0.5 to 5.1.1 and am recompiling right now. I'll add a comment when it finishes. [2005-11-30 10:34:48] [EMAIL PROTECTED] Joe, I agree, this is most likely not PHP issue, but I'm still able to reproduce it on Solaris 8 and -fPIC doesn't help. [2005-11-30 09:46:26] [EMAIL PROTECTED] This is the expected failure from trying to link non-PIC code into a shared library on most platforms. If you really insist on using a static MySQL library you must rebuild it with -fPIC in CFLAGS. If it worked previously I'd guess it was only because the static libmysql.a wasn't being found. 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/35465 -- Edit this bug report at http://bugs.php.net/?id=35465edit=1
#35432 [Csd-Opn]: make fails with PDO and MySQL5
ID: 35432 User updated by: mail at philipp-wagner dot com Reported By: mail at philipp-wagner dot com -Status: Closed +Status: Open Bug Type: PDO related Operating System: SuSE Linux 8.0 PHP Version: 5CVS-2005-11-27 (snap) Assigned To: wez New Comment: It's really a documentation problem then. It's NOT enough to just specify (as you wrote above) --enable-pdo=shared --with-pdo-mysql=shared,/usr/local/mysql --with-sqlite=shared I had to use --enable-pdo=shared --with-pdo-mysql=shared,/usr/local/mysql --with-sqlite=shared --with-pdo-sqlite=shared to get it to work. This really should be be mentioned in the documentation. The documentation only suggests to compile with --enable-pdo=shared, but that won't work, if you don't use at least the corresponding sqlite configure options also. Previous Comments: [2005-11-30 18:47:41] [EMAIL PROTECTED] You simply need to tell configure to build what you want it to build, how you want it built. --enable-pdo=shared --with-pdo-mysql=shared,/usr/local/mysql --with-sqlite=shared I know it sucks that we can't automatically make it work that way you want it; configure scripts have their limitations. [2005-11-30 17:31:25] [EMAIL PROTECTED] Wez, so, enabling by default is good thing? Hint: You should always use --disable-all :) [2005-11-30 16:25:12] mail at philipp-wagner dot com Well, I thought this might be the problem (mixing of shared and static libraries)... But now the check seems to be too strict. I first tried to build with --enable-pdo=shared --with-pdo-mysql=shared,/usr/local/mysql Now I got the following error message: You've configured extension sqlite to build statically, but it depends on extension pdo, which you've configured to build shared. You either need to build sqlite shared or build pdo statically for the build to be successful. sqlite is enabled by default (I didn't specify exlicitly specify pdo sqlite support as a configure option). ./configure --help doesn't say anything about an option like --with-pdo-sqlite, but I tried to use it anyways (or what else should I do to specify shared pdo sqlite support?). So I ran ./configure with --with-pdo-sqlite=shared This worked out quite well at first, configure gave me an output like checking for sqlite 3 driver for PDO... yes, shared But then, a bit further down, I got the error message again: checking for PDO includes... (cached) /usr/local/src/php5.1-200511301330/ext checking for lemon... no configure: warning: lemon versions supported for regeneration of libsqlite parsers: 1.0 (found: none). configure: error: You've configured extension sqlite to build statically, but it depends on extension pdo, which you've configured to build shared. You either need to build sqlite shared or build pdo statically for the build to be successful. I actually think, if you specify --enable-pdo=shared, all pdo submodules should also be built shared, as it reduces confusion and is the only way to get a working build anyways (it seems it is not possible to mix shared and static pdo libraries, so there's no need to specify it seperately). Also, the documentation doesn't say anything about how to build the specific PDO modules. It just suggests building PDO with --enable-pdo=shared, but doesn't say which configure options to use for MySQL PDO support etc. (I just got it from the ./configure --help output), and also doesn't mention the shared problem. [2005-11-30 05:48:21] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip Please try the next PHP 5.1 snapshot. It features an improved error message that should catch conflicting configure options. [2005-11-28 17:53:13] mail at philipp-wagner dot com Yes, I see that now too, but it's not a problem for MySQL, as /usr/local/mysql is the prefix (it's a MySQL binary .tar.gz distribution). 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/35432 -- Edit this bug report at http://bugs.php.net/?id=35432edit=1
#35493 [Opn-Fbk]: mssql_query return values varies from version to version (works with PHP 5.1)
ID: 35493
Updated by: [EMAIL PROTECTED]
Reported By: martin at malditainternet dot com
-Status: Open
+Status: Feedback
Bug Type: MSSQL related
Operating System: linux
PHP Version: 4.4.1
New Comment:
Please check that you are using the same version (and protocol) of
FreeTDS on all the different systems.
This is the output with the latest CVS version of both FreeTDS and
PHP:
PHP: 5.1.0RC5-dev
Query (select * from sysobjects where name='nonexistant') ret: Resource
id #5
Previous Comments:
[2005-11-30 16:53:09] martin at malditainternet dot com
Description:
The return value of mssql_query is different from version to version
when there aren't rows to return. For example:
PHP: 4.4.2RC2-dev (from snap)
Query (select * from sysobjects where name='nonexistant') ret: 5
PHP: 5.0.5-3 (Debian)
Query (select * from sysobjects where name='nonexistant') ret: Resource
id #5
PHP: 4.4.1-0.dotdeb.3 (Debian - Dotdeb)
Query (select * from sysobjects where name='nonexistant') ret: 1
PHP: 4.4.0-4 (Debian)
Query (select * from sysobjects where name='nonexistant') ret: Resource
id #5
Reproduce code:
---
?
mssql_connect('HOST','USER','password');
mssql_select_db('TNS_1_3_SPIDER');
$q=select * from sysobjects where name='nonexistant';
print 'PHP: '.phpversion().\n.Query ($q) ret:
.mssql_query($q).\n;
?
Expected result:
I would love to get 'Resources' instead of integers
--
Edit this bug report at http://bugs.php.net/?id=35493edit=1
#34852 [Opn]: [PATCH] Failure in odbc_exec() using oracle-supplied odbc driver
ID: 34852
Updated by: [EMAIL PROTECTED]
Reported By: tim dot tassonis at trivadis dot com
Status: Open
Bug Type: ODBC related
Operating System: Linux
PHP Version: 5CVS-2005-11-03 (cvs)
New Comment:
Unfortunately Dan can not be involved in this. (some license thing)
Previous Comments:
[2005-11-04 01:49:46] [EMAIL PROTECTED]
Tony: Check with Dan Scott before applying this patch; he's probably
most current on this aspect of the odbc extension.
[2005-10-13 13:34:40] tim dot tassonis at trivadis dot com
Well, here is a patch. I dont know whether the formatting is preserved
her properly, it should apply cleanly with patch -p1 patchfile from
whithing the php-5.0.5 directory.
The patch just stops odbc_exec and odbc_prepare from failing if the
SQLSetStmtOption fails. The warning is still displayed in the
error_log. It would be great if this could be applied.
So below follows the patch (created with diff -ruN):
diff -ruN php-5.0.5/ext/odbc/php_odbc.c
php-5.0.5-ora/ext/odbc/php_odbc.c
--- php-5.0.5/ext/odbc/php_odbc.c 2005-07-03 00:50:01.0 +0200
+++ php-5.0.5-ora/ext/odbc/php_odbc.c 2005-10-13 12:20:55.0
+0200
@@ -875,9 +875,11 @@
if (SQLSetStmtOption(result-stmt, SQL_CURSOR_TYPE,
SQL_CURSOR_DYNAMIC)
== SQL_ERROR) {
odbc_sql_error(conn, result-stmt,
SQLSetStmtOption);
+ /* Dont fail, but go on. This can happen
SQLFreeStmt(result-stmt, SQL_DROP);
efree(result);
RETURN_FALSE;
+ */
}
}
} else {
@@ -1296,9 +1298,11 @@
if (SQLSetStmtOption(result-stmt, SQL_CURSOR_TYPE,
SQL_CURSOR_DYNAMIC)
== SQL_ERROR) {
odbc_sql_error(conn, result-stmt,
SQLSetStmtOption);
+ /* Dont fail, but go on. This can happen
SQLFreeStmt(result-stmt, SQL_DROP);
efree(result);
RETURN_FALSE;
+ */
}
}
} else {
[2005-10-13 12:14:49] tim dot tassonis at trivadis dot com
Description:
When using the oracle-supplied ODBC Driver under Linux, any odbc_exec()
call fails with:
[unixODBC][Driver Manager]Driver does not support this function
The log files is a bit more verbose:
[unixODBC][Driver Manager]Driver does not support this function, SQL
state IM001 in SQLSetStmtOption
The offending code is in odbc_prepare(line 875) and odbc_exec (line
1276), when the module tries to set SQL_CURSOR_DYNAMIC via
SQLSetStmtOption, which returns an error using the oracle driver.
The error goes away if I undefine HAVE_SQL_EXTENDED_FETCH, so the
statements will not be reached.
Would it be possible to only issue a notice when this command fails and
proceed with processing.
I can provide a patch to fix it, if that's appreciated.
Reproduce code:
---
$dsn=ANY_ORACLE_DSN;
$uid=ANY_VALID_USERID;
$pwd=ANY_VALID_PASSWORD;
$conn = odbc_connect ( $dsn, $uid, $pwd );
/* The connect succeeds */
if (!$conn) {
printf(Error connecting to $database.br\n);
return;
}
/* The exec will fail with the decribed error */
$cursor= odbc_exec($conn,SELECT tname from tab);
if (!$cursor) {
printf(Failure in odbc_exe:br\n);
printf(%sbr\n,htmlentities(odbc_errormsg($conn)));
return;
}
Actual result:
--
[unixODBC][Driver Manager]Driver does not support this function, SQL
state IM001 in SQLSetStmtOption
--
Edit this bug report at http://bugs.php.net/?id=34852edit=1
#35465 [Asn]: link error Text relocation remains
ID: 35465 Updated by: [EMAIL PROTECTED] Reported By: rusty at socrates dot berkeley dot edu Status: Assigned Bug Type: Compile Failure Operating System: solaris 9 PHP Version: 5.1.1 Assigned To: sniper New Comment: Can you please send me both the one you get with the snapshot I asked you to try and the one you get with 5.0.5. Send them here: [EMAIL PROTECTED] Previous Comments: [2005-11-30 20:09:34] [EMAIL PROTECTED] I would like it if people didn't bogus the reports I've assigned myself.. [2005-11-30 20:04:45] rusty at socrates dot berkeley dot edu 5.1.1 compiles if you use the libtool from 5.0.5. You have to copy over libtool after running configure in the 5.0.5 and 5.1.1 directories. Do not copy over libtool.m4 from the build directory and then run configure. [2005-11-30 19:08:18] php at fiddaman dot net I'm seeing the problem with the IMAP extension which uses the UW IMAP toolkit. Now this toolkit never compiles as a shared object (see http://www.washington.edu/imap/IMAP-FAQs/#6.3) If Rusty's unusual use of static mysql libraries is a problem, look at the IMAP extension. [2005-11-30 18:54:09] rusty at socrates dot berkeley dot edu Would you guys please pull your heads out of your and go read bug #35475? It appears to be a bug in the libtool that you're now using. It may not be a bug in the PHP code but it certainly is a bug in the PHP *distribution*. I've wiped and re-extracted the tar files and copied over the libtool.m4 from 5.0.5 to 5.1.1 and am recompiling right now. I'll add a comment when it finishes. [2005-11-30 10:34:48] [EMAIL PROTECTED] Joe, I agree, this is most likely not PHP issue, but I'm still able to reproduce it on Solaris 8 and -fPIC doesn't help. 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/35465 -- Edit this bug report at http://bugs.php.net/?id=35465edit=1
#35496 [Opn-Bgs]: Segfault in mcrypt_generic()
ID: 35496
Updated by: [EMAIL PROTECTED]
Reported By: iblue at gmx dot net
-Status: Open
+Status: Bogus
Bug Type: Reproducible crash
Operating System: Linux 2.6.14-iblue0
PHP Version: 5.1.1
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
The problem is due to you attempting to encrypt a string without
calling mcrypt_generic_init() function first.
Previous Comments:
[2005-11-30 19:15:31] iblue at gmx dot net
Description:
php segfaults when executing the reproduce code.
Reproduce code:
---
?php
$x = foobar;
$td = mcrypt_module_open('rijndael-256', '', 'ofb', '');
$iv = mcrypt_create_iv(mcrypt_enc_get_iv_size($td),
MCRYPT_DEV_RANDOM);
$ks = mcrypt_enc_get_key_size($td);
$key = md5(foobar);
$encrypted = mcrypt_generic($td, $x);
?
Expected result:
No output and a clean exit.
Actual result:
--
(gdb) run -q bug.php
Starting program: /home/iblue/src/php-5.1.1/sapi/cli/php -q bug.php
[Thread debugging using libthread_db enabled]
[New Thread -1214781760 (LWP 17768)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1214781760 (LWP 17768)]
0xb7f22b70 in mcrypt_mutex_register () from /usr/lib/libmcrypt.so.4
(gdb) bt
#0 0xb7f22b70 in mcrypt_mutex_register () from
/usr/lib/libmcrypt.so.4
#1 0xb7f20203 in mcrypt_enc_get_algorithms_name () from
/usr/lib/libmcrypt.so.4
#2 0xb7f1f197 in mcrypt_generic () from /usr/lib/libmcrypt.so.4
#3 0x080ec88b in zif_mcrypt_generic (ht=2, return_value=0x84f17bc,
return_value_ptr=0x0, this_ptr=0x0,
return_value_used=1, tsrm_ls=0x83ed018) at
/home/iblue/src/php-5.1.1/ext/mcrypt/mcrypt.c:489
#4 0x0825d2cd in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfacdc48, tsrm_ls=0x83ed018)
at /home/iblue/src/php-5.1.1/Zend/zend_vm_execute.h:188
#5 0x082630bf in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0xbfacdc48, tsrm_ls=0x83ed018)
at /home/iblue/src/php-5.1.1/Zend/zend_vm_execute.h:1578
#6 0x0825cbfc in execute (op_array=0x84fc0ac, tsrm_ls=0x83ed018) at
/home/iblue/src/php-5.1.1/Zend/zend_vm_execute.h:88#7 0x08238816 in
zend_execute_scripts (type=8, tsrm_ls=0x83ed018, retval=0x0,
file_count=3)
at /home/iblue/src/php-5.1.1/Zend/zend.c:1090
#8 0x081fc32b in php_execute_script (primary_file=0xbfacffe4,
tsrm_ls=0x83ed018)
at /home/iblue/src/php-5.1.1/main/main.c:1704
#9 0x082e26ca in main (argc=3, argv=0xbfad0084) at
/home/iblue/src/php-5.1.1/sapi/cli/php_cli.c:1039
--
Edit this bug report at http://bugs.php.net/?id=35496edit=1
#35496 [Bgs]: Segfault in mcrypt_generic()
ID: 35496
User updated by: iblue at gmx dot net
Reported By: iblue at gmx dot net
Status: Bogus
Bug Type: Reproducible crash
Operating System: Linux 2.6.14-iblue0
PHP Version: 5.1.1
New Comment:
You are right, I have not read the manual and thought this
would be a real bug.
But, in my opinion, when php crashes it is a bug, regardless
of what I did.
It would be nice to have a warning or an error instead of a
segfault.
Previous Comments:
[2005-11-30 21:31:47] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
The problem is due to you attempting to encrypt a string without
calling mcrypt_generic_init() function first.
[2005-11-30 19:15:31] iblue at gmx dot net
Description:
php segfaults when executing the reproduce code.
Reproduce code:
---
?php
$x = foobar;
$td = mcrypt_module_open('rijndael-256', '', 'ofb', '');
$iv = mcrypt_create_iv(mcrypt_enc_get_iv_size($td),
MCRYPT_DEV_RANDOM);
$ks = mcrypt_enc_get_key_size($td);
$key = md5(foobar);
$encrypted = mcrypt_generic($td, $x);
?
Expected result:
No output and a clean exit.
Actual result:
--
(gdb) run -q bug.php
Starting program: /home/iblue/src/php-5.1.1/sapi/cli/php -q bug.php
[Thread debugging using libthread_db enabled]
[New Thread -1214781760 (LWP 17768)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1214781760 (LWP 17768)]
0xb7f22b70 in mcrypt_mutex_register () from /usr/lib/libmcrypt.so.4
(gdb) bt
#0 0xb7f22b70 in mcrypt_mutex_register () from
/usr/lib/libmcrypt.so.4
#1 0xb7f20203 in mcrypt_enc_get_algorithms_name () from
/usr/lib/libmcrypt.so.4
#2 0xb7f1f197 in mcrypt_generic () from /usr/lib/libmcrypt.so.4
#3 0x080ec88b in zif_mcrypt_generic (ht=2, return_value=0x84f17bc,
return_value_ptr=0x0, this_ptr=0x0,
return_value_used=1, tsrm_ls=0x83ed018) at
/home/iblue/src/php-5.1.1/ext/mcrypt/mcrypt.c:489
#4 0x0825d2cd in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfacdc48, tsrm_ls=0x83ed018)
at /home/iblue/src/php-5.1.1/Zend/zend_vm_execute.h:188
#5 0x082630bf in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0xbfacdc48, tsrm_ls=0x83ed018)
at /home/iblue/src/php-5.1.1/Zend/zend_vm_execute.h:1578
#6 0x0825cbfc in execute (op_array=0x84fc0ac, tsrm_ls=0x83ed018) at
/home/iblue/src/php-5.1.1/Zend/zend_vm_execute.h:88#7 0x08238816 in
zend_execute_scripts (type=8, tsrm_ls=0x83ed018, retval=0x0,
file_count=3)
at /home/iblue/src/php-5.1.1/Zend/zend.c:1090
#8 0x081fc32b in php_execute_script (primary_file=0xbfacffe4,
tsrm_ls=0x83ed018)
at /home/iblue/src/php-5.1.1/main/main.c:1704
#9 0x082e26ca in main (argc=3, argv=0xbfad0084) at
/home/iblue/src/php-5.1.1/sapi/cli/php_cli.c:1039
--
Edit this bug report at http://bugs.php.net/?id=35496edit=1
#35496 [Bgs-Asn]: Segfault in mcrypt_generic()
ID: 35496
Updated by: [EMAIL PROTECTED]
Reported By: iblue at gmx dot net
-Status: Bogus
+Status: Assigned
Bug Type: Reproducible crash
Operating System: Linux 2.6.14-iblue0
PHP Version: 5.1.1
-Assigned To:
+Assigned To: ilia
New Comment:
After a short discussion we decided to work around this segfault.
Assigned to Ilia, he's working on the patch.
Previous Comments:
[2005-11-30 21:50:08] iblue at gmx dot net
You are right, I have not read the manual and thought this
would be a real bug.
But, in my opinion, when php crashes it is a bug, regardless
of what I did.
It would be nice to have a warning or an error instead of a
segfault.
[2005-11-30 21:31:47] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
The problem is due to you attempting to encrypt a string without
calling mcrypt_generic_init() function first.
[2005-11-30 19:15:31] iblue at gmx dot net
Description:
php segfaults when executing the reproduce code.
Reproduce code:
---
?php
$x = foobar;
$td = mcrypt_module_open('rijndael-256', '', 'ofb', '');
$iv = mcrypt_create_iv(mcrypt_enc_get_iv_size($td),
MCRYPT_DEV_RANDOM);
$ks = mcrypt_enc_get_key_size($td);
$key = md5(foobar);
$encrypted = mcrypt_generic($td, $x);
?
Expected result:
No output and a clean exit.
Actual result:
--
(gdb) run -q bug.php
Starting program: /home/iblue/src/php-5.1.1/sapi/cli/php -q bug.php
[Thread debugging using libthread_db enabled]
[New Thread -1214781760 (LWP 17768)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1214781760 (LWP 17768)]
0xb7f22b70 in mcrypt_mutex_register () from /usr/lib/libmcrypt.so.4
(gdb) bt
#0 0xb7f22b70 in mcrypt_mutex_register () from
/usr/lib/libmcrypt.so.4
#1 0xb7f20203 in mcrypt_enc_get_algorithms_name () from
/usr/lib/libmcrypt.so.4
#2 0xb7f1f197 in mcrypt_generic () from /usr/lib/libmcrypt.so.4
#3 0x080ec88b in zif_mcrypt_generic (ht=2, return_value=0x84f17bc,
return_value_ptr=0x0, this_ptr=0x0,
return_value_used=1, tsrm_ls=0x83ed018) at
/home/iblue/src/php-5.1.1/ext/mcrypt/mcrypt.c:489
#4 0x0825d2cd in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfacdc48, tsrm_ls=0x83ed018)
at /home/iblue/src/php-5.1.1/Zend/zend_vm_execute.h:188
#5 0x082630bf in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0xbfacdc48, tsrm_ls=0x83ed018)
at /home/iblue/src/php-5.1.1/Zend/zend_vm_execute.h:1578
#6 0x0825cbfc in execute (op_array=0x84fc0ac, tsrm_ls=0x83ed018) at
/home/iblue/src/php-5.1.1/Zend/zend_vm_execute.h:88#7 0x08238816 in
zend_execute_scripts (type=8, tsrm_ls=0x83ed018, retval=0x0,
file_count=3)
at /home/iblue/src/php-5.1.1/Zend/zend.c:1090
#8 0x081fc32b in php_execute_script (primary_file=0xbfacffe4,
tsrm_ls=0x83ed018)
at /home/iblue/src/php-5.1.1/main/main.c:1704
#9 0x082e26ca in main (argc=3, argv=0xbfad0084) at
/home/iblue/src/php-5.1.1/sapi/cli/php_cli.c:1039
--
Edit this bug report at http://bugs.php.net/?id=35496edit=1
#35495 [Fbk-Opn]: feof() does not report EOF on a zero file
ID: 35495
User updated by: dsp at tdcspace dot dk
Reported By: dsp at tdcspace dot dk
-Status: Feedback
+Status: Open
Bug Type: Filesystem function related
Operating System: linux/win
PHP Version: 4.4.1
New Comment:
nope - 5.1.2.2 cvs - same story - feof() still ignores a zero file
Previous Comments:
[2005-11-30 18:42:43] [EMAIL PROTECTED]
No, try the 5.1 snapshot.
[2005-11-30 18:42:21] dsp at tdcspace dot dk
is there a cvs for 4.4.1
[2005-11-30 18:33:15] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2005-11-30 18:30:52] dsp at tdcspace dot dk
Description:
feof() does not report eof on a zero (0) length file
following code (similar to the ex. in the php manual) does
act like a new record was read - allthouh the file IS at eof.
$handle = @fopen(xxx, r);
while (!feof($handle)) {
$buffer = fgets($handle, 4096);
echo $buffer;
}
fclose($handle);
--
Edit this bug report at http://bugs.php.net/?id=35495edit=1
#35495 [Opn]: feof() does not report EOF on a zero file
ID: 35495
User updated by: dsp at tdcspace dot dk
Reported By: dsp at tdcspace dot dk
Status: Open
Bug Type: Filesystem function related
Operating System: linux/win
PHP Version: 4.4.1
New Comment:
what i don't understand is that the win/linux lower filesystem layer
maintains a filepointer of which it should be easy to detect/report a
EOF condition. The PHP handle as a file descriptor resource should
among things maintain this.
But i don't maintain php and thus don't know the reasons.
Previous Comments:
[2005-11-30 22:40:21] dsp at tdcspace dot dk
nope - 5.1.2.2 cvs - same story - feof() still ignores a zero file
[2005-11-30 18:42:43] [EMAIL PROTECTED]
No, try the 5.1 snapshot.
[2005-11-30 18:42:21] dsp at tdcspace dot dk
is there a cvs for 4.4.1
[2005-11-30 18:33:15] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2005-11-30 18:30:52] dsp at tdcspace dot dk
Description:
feof() does not report eof on a zero (0) length file
following code (similar to the ex. in the php manual) does
act like a new record was read - allthouh the file IS at eof.
$handle = @fopen(xxx, r);
while (!feof($handle)) {
$buffer = fgets($handle, 4096);
echo $buffer;
}
fclose($handle);
--
Edit this bug report at http://bugs.php.net/?id=35495edit=1
#35497 [NEW]: Difference between echo and printf
From: viperjason at gmail dot com Operating system: Windows XP SP2 PHP version: 5CVS-2005-11-30 (CVS) PHP Bug Type: Scripting Engine problem Bug description: Difference between echo and printf Description: If you look at the code I initialize a 32bit hex value and print it with both printf and echo. I do a AND and a OR to get the value back to the original value and print it again with printf and echo. Printf and echo disaggree on the first print Printf and echo agree on the second print Printf and echo agree on the third print. What happened with the first print? I realize you use signed integers.but where is my sign? Reproduce code: --- ? $a = 0x800F; printf(hex=%x, dec=%d by printf\n,$a,$a); echo $a.by echo\n; $a = $a 0x0FFF; printf(hex=%x, dec=%d by printf\n,$a,$a); echo $a.\n; $a = $a | 0x8000; printf(hex=%x, dec=%d by printf\n,$a,$a); echo $a.\n; ? Expected result: I expect both printf and echo to consistantly print out the same decimal result. Actual result: -- The first time they didnt and second time they did. -- Edit bug report at http://bugs.php.net/?id=35497edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=35497r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=35497r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=35497r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=35497r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=35497r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=35497r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=35497r=needscript Try newer version:http://bugs.php.net/fix.php?id=35497r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=35497r=support Expected behavior:http://bugs.php.net/fix.php?id=35497r=notwrong Not enough info: http://bugs.php.net/fix.php?id=35497r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=35497r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=35497r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35497r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=35497r=dst IIS Stability:http://bugs.php.net/fix.php?id=35497r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=35497r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=35497r=float No Zend Extensions: http://bugs.php.net/fix.php?id=35497r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=35497r=mysqlcfg
#35497 [Opn-Bgs]: Difference between echo and printf
ID: 35497 Updated by: [EMAIL PROTECTED] Reported By: viperjason at gmail dot com -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: Windows XP SP2 PHP Version: 5CVS-2005-11-30 (CVS) New Comment: $a = 0x800F; In this case $a is bigger than int, so the engine converts it to float automatically. printf(%d) casts it back to int and you get negative value as the result. echo (int)$a; will give you the same. In all the other cases echo printf() give the very same results. No bug here. Previous Comments: [2005-11-30 22:51:59] viperjason at gmail dot com Description: If you look at the code I initialize a 32bit hex value and print it with both printf and echo. I do a AND and a OR to get the value back to the original value and print it again with printf and echo. Printf and echo disaggree on the first print Printf and echo agree on the second print Printf and echo agree on the third print. What happened with the first print? I realize you use signed integers.but where is my sign? Reproduce code: --- ? $a = 0x800F; printf(hex=%x, dec=%d by printf\n,$a,$a); echo $a.by echo\n; $a = $a 0x0FFF; printf(hex=%x, dec=%d by printf\n,$a,$a); echo $a.\n; $a = $a | 0x8000; printf(hex=%x, dec=%d by printf\n,$a,$a); echo $a.\n; ? Expected result: I expect both printf and echo to consistantly print out the same decimal result. Actual result: -- The first time they didnt and second time they did. -- Edit this bug report at http://bugs.php.net/?id=35497edit=1
#35495 [Opn-Asn]: feof() does not report EOF on a zero file
ID: 35495 Updated by: [EMAIL PROTECTED] Reported By: dsp at tdcspace dot dk -Status: Open +Status: Assigned Bug Type: Filesystem function related Operating System: linux/win -PHP Version: 4.4.1 +PHP Version: 5CVS, 4CVS (2005-11-30) (snap) -Assigned To: +Assigned To: wez New Comment: Wez, sounds like something isn't working quite well in the streams world? Previous Comments: [2005-11-30 22:46:26] dsp at tdcspace dot dk what i don't understand is that the win/linux lower filesystem layer maintains a filepointer of which it should be easy to detect/report a EOF condition. The PHP handle as a file descriptor resource should among things maintain this. But i don't maintain php and thus don't know the reasons. [2005-11-30 22:40:21] dsp at tdcspace dot dk nope - 5.1.2.2 cvs - same story - feof() still ignores a zero file [2005-11-30 18:42:43] [EMAIL PROTECTED] No, try the 5.1 snapshot. [2005-11-30 18:42:21] dsp at tdcspace dot dk is there a cvs for 4.4.1 [2005-11-30 18:33:15] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-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/35495 -- Edit this bug report at http://bugs.php.net/?id=35495edit=1
#35482 [Fbk-Opn]: Bad performance of filesystem functions on Windows XP Professional
ID: 35482
User updated by: tobias-bender at web dot de
-Summary: Bad performance of filesystem functions
Reported By: tobias-bender at web dot de
-Status: Feedback
+Status: Open
Bug Type: Filesystem function related
Operating System: Windows XP Professional
PHP Version: 5.1.1
New Comment:
I think this has to be analysed on a Windows platform
Previous Comments:
[2005-11-30 10:30:11] [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.
Can't reproduce on Linux.
[2005-11-30 01:25:57] tobias-bender at web dot de
Description:
All filesystem functions got much slower with PHP 5.x.
With short relative paths PHP 4 is about twice as fast as PHP 5. PHP 5
is nearly 10 times slower when using absolute paths compared to PHP 4.
Reproduce code:
---
function getMicrotime(){
list($usec, $sec) = explode(' ', microtime());
return ((float)$usec + (float)$sec);
}
$iTime = getMicrotime();
$rHandle = opendir('C:/Apache2/htdocs/phpXplorer/test/vollvoll');
while (false !== ($sName = readdir($rHandle))) {
if (is_dir('C:/Apache2/htdocs/phpXplorer/test/vollvoll/' . $sName)){
echo 'C:/Apache2/htdocs/phpXplorer/test/vollvoll/' . $sName .
'br/';
}
}
echo getMicrotime() - $iTime;
--
Edit this bug report at http://bugs.php.net/?id=35482edit=1
#35497 [Bgs]: Difference between echo and printf
ID: 35497 User updated by: viperjason at gmail dot com Reported By: viperjason at gmail dot com Status: Bogus Bug Type: Scripting Engine problem Operating System: Windows XP SP2 PHP Version: 5CVS-2005-11-30 (CVS) New Comment: I thought ints were 32bits? 0x800F is a 32 bit value. Previous Comments: [2005-11-30 23:11:00] [EMAIL PROTECTED] $a = 0x800F; In this case $a is bigger than int, so the engine converts it to float automatically. printf(%d) casts it back to int and you get negative value as the result. echo (int)$a; will give you the same. In all the other cases echo printf() give the very same results. No bug here. [2005-11-30 22:51:59] viperjason at gmail dot com Description: If you look at the code I initialize a 32bit hex value and print it with both printf and echo. I do a AND and a OR to get the value back to the original value and print it again with printf and echo. Printf and echo disaggree on the first print Printf and echo agree on the second print Printf and echo agree on the third print. What happened with the first print? I realize you use signed integers.but where is my sign? Reproduce code: --- ? $a = 0x800F; printf(hex=%x, dec=%d by printf\n,$a,$a); echo $a.by echo\n; $a = $a 0x0FFF; printf(hex=%x, dec=%d by printf\n,$a,$a); echo $a.\n; $a = $a | 0x8000; printf(hex=%x, dec=%d by printf\n,$a,$a); echo $a.\n; ? Expected result: I expect both printf and echo to consistantly print out the same decimal result. Actual result: -- The first time they didnt and second time they did. -- Edit this bug report at http://bugs.php.net/?id=35497edit=1
#31774 [Com]: Data missing using DirectoryIterator with ftp:// wrapper
ID: 31774 Comment by: homechoice2005 at yahoo dot com Reported By: php at lachoseinteractive dot net Status: Assigned Bug Type: FTP related Operating System: Linux Mac OS X PHP Version: 5CVS-2005-03-20 Assigned To: pollita New Comment: You are welcome to home choice your online choice to day... here at home choice , our goal is to make your shoppoing experience better, faster, easier and safer than ever before? that is why we have compiled a range of products that offers something for everyone... from top quality bed line designs and cookwave to top brand clectronics and appliance. CUSTOMER CARE PLAN everythinmg you order from us is covered by our compreliensive home choice customewre care plan. what does that mean to me? i hear you ask. peace of mind is what you get? MAIN PRODUCTS: RADIO CD ...ONE YEAR GURANTEE: Nu-tec 3cd hi-fi Lg 3cd hi-fi sansui 3cd battery/mains hi fi sansui 5cd battery/mains hi fi nu tec 5cd hi fi homechoice 3cd hi fi telefunken 3cd hi fi VIDEO RECORDER: LG 2-head video recorder sansui diamond 3 head sansui 2-head video recorder MICROWAVE COOKING: hot plate combo home choice tow-tone combo frying pan combo estia delux grill ideal multi griller zass combo griller home choice mini oven deluxe table top stove twister blender sunbeam kitchen helper magicline magi mixa magicline food processor and blender microwave with grill stainless steel microwave stock pot CURTAIN: Spring flower curtain christina curtain doruble drops curtain luxury set colorado curtain BED BLANKET: electronics blanket bed blanket PHONES DETAILS Nokia 6630 185 USD Nokia 6650 20 USD Nokia 6670 180 USD Nokia 6680 200 USD Nokia 6681 230 USD Nokia 6810 250 USD Nokia 6820 20 USD Nokia 7200 120 USD Nokia 7250 55 USD Nokia 7250i 70 USD Nokia 7260 85 USD Nokia 7270 170 USD Nokia 7280 190 USD Nokia 7600 200 USD Nokia 7610 185 USD Nokia 7650 95 USD Nokia 7710 260 USD Nokia 7700 255 USD Nokia 8800 260 USD Nokia 8910i 110 USD Nokia 9500 300 USD Nokia 9300 190 USD Nokia N70 285 USD Nokia N90 300 USD Nokia N91 325 USD Sonyericsson P910i 295 USD Sonyericsson p910a 320 USD Sonyericsson P900 230 USD Sonyericsson k750i 180 USD Sonyericsson K700i 150 USD Sonyericsson T610i 170 USD Sonyericsson T630 130 USD Sonyericsson K500i 200 USD Sonyericsson W800 180 USD whether its lastest vcr or a beautiful bed linen set that you are intrested in, rest assured that your order we be delivered to your door. thats right... place your order from the comfort of your favourite chair and then just sit back and relax? well take care of everything? SPEEDY DELIVERY... PLASE PROVIDE ALL THE DETAILS WE ASK FOR ON YOUR ORDER FROM, AS THIS WILL ENABLE US TO APPROVE YOUR ORDER QUICKLY AND SAEND TO YOU YOUR GOODS STRAIGHT AWAY. THE FOLLOWNNG INFORMATION IS ESPECIALLY IMPORTANT INPORTANT INFORMATION: . WHAT YOU WANT TO ORDER. . YOUR STREET ADDRESS: IF YOU WANT TO USE OUR CONVENIENT HOME CHOICE DELIVER SERVICE. . YOUR TELEPHONE NUMBER IMPORTANT: IF YOU HAVE ANY QUERIES ABOUT OUR PRODUCTS AND SERVICE S, PLEASE E-MAIL US ON homechoice2005 @yahoo.comOUR FRIENDLY CUSTOMER SERVICE REPRESENTATIVES ARE ALWAYS READY TO HELP YOU. MONDAY TO SATURDAY FROM 8.30 AM TO 7PM. FRIDAY 8.30AM TO 1.PM . EASYPAYMENTTHROUGH. .WESTERN UNIOR MONEY TRANSFER . POSTING THROUGH OUR COMPANY ADDRESS . T/T BANK Previous Comments: [2005-04-29 03:48:20] [EMAIL PROTECTED] Assigned to the FTP maintainer.. :) [2005-03-22 20:33:11] php at lachoseinteractive dot net Same bug in php5-200503201530 [2005-02-28 20:53:47] [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-01-31 12:41:10] php at lachoseinteractive dot net After more investigation, it turns out that the iterator reconnects to the server several times for each file of list in order to get SIZE information, etc instead of parsing a raw list from an FTP LIST command.
#35499 [NEW]: strtotime with newline fails
From: stabthecat at hotmail dot com Operating system: Windows / Linux PHP version: 5.1.1 PHP Bug Type: Date/time related Bug description: strtotime with newline fails Description: Since version 5.1 strtotime(11/20/2005 8:00 AM\r\n); fails, and returns null strtotime(trim(11/20/2005 8:00 AM\r\n)); fixes it Reproduce code: --- print(strtotime(11/20/2005 8:00 AM\r\n)); Expected result: 1132488000 -- Edit bug report at http://bugs.php.net/?id=35499edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=35499r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=35499r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=35499r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=35499r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=35499r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=35499r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=35499r=needscript Try newer version:http://bugs.php.net/fix.php?id=35499r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=35499r=support Expected behavior:http://bugs.php.net/fix.php?id=35499r=notwrong Not enough info: http://bugs.php.net/fix.php?id=35499r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=35499r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=35499r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35499r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=35499r=dst IIS Stability:http://bugs.php.net/fix.php?id=35499r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=35499r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=35499r=float No Zend Extensions: http://bugs.php.net/fix.php?id=35499r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=35499r=mysqlcfg
#35498 [NEW]: GD cannot open majority of jpeg images
From: paniemin at cc dot hut dot fi Operating system: Redhat Linux 7.3 PHP version: 5.1.1 PHP Bug Type: GD related Bug description: GD cannot open majority of jpeg images Description: I tryed to upgrade from 5.0.4 to 5.1. I use blunded GD version with freetype2, jpeg and png libraries. First I tried with old libraries that I used to build 5.0.4. Next I downloaded new version from freetype2. Next I downloaded GD 2.0.33 and tryed with it. I tried to find the problematic part but I failed to locate it outside php :( I found that imagecreatefromjpeg() fails to open jpeg files that older php version opened without problems. The failure to open seems to be random but about 60-70% images are 'corruped' for gd library. here is one of corrupted images: http://antin.net/imageshu/7363_1.jpg I will continue searching the real reason for this bug. I hope someone else can confirm same problem with 5.1 and GD. Reproduce code: --- $file = getFileForPerson($id, $imageNumber); $img = imagecreatefromjpeg($file); Expected result: I excepted imagecreatefromjpeg to load the image so next steps in code can manipulate it. Actual result: -- Warning: imagecreatefromjpeg() [function.imagecreatefromjpeg]: gd-jpeg: JPEG library reports unrecoverable error: in /home/customers/antin/public_html/huippu/ranki_dev.cgi on line 110 Warning: imagecreatefromjpeg() [function.imagecreatefromjpeg]: '../imageshu/7363_1.jpg' is not a valid JPEG file in /home/customers/antin/public_html/huippu/ranki_dev.cgi on line 110 With GD 2.0.33 the first warning is skipped which seems natural for me. -- Edit bug report at http://bugs.php.net/?id=35498edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=35498r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=35498r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=35498r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=35498r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=35498r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=35498r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=35498r=needscript Try newer version:http://bugs.php.net/fix.php?id=35498r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=35498r=support Expected behavior:http://bugs.php.net/fix.php?id=35498r=notwrong Not enough info: http://bugs.php.net/fix.php?id=35498r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=35498r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=35498r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35498r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=35498r=dst IIS Stability:http://bugs.php.net/fix.php?id=35498r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=35498r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=35498r=float No Zend Extensions: http://bugs.php.net/fix.php?id=35498r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=35498r=mysqlcfg
#32503 [Com]: fopen() in cwd: filename must start with ./ under safe mode
ID: 32503
Comment by: homechoice2005 at yahoo dot com
Reported By: Bjorn dot Wiberg at its dot uu dot se
Status: Open
Bug Type: Filesystem function related
Operating System: IBM AIX 5.2.0.0 ML5
PHP Version: 5CVS-2005-07-05
New Comment:
You are welcome to home
choice your online choice to day...
here at home choice , our goal is to make your shoppoing
experience better, faster, easier and safer than ever
before? that is why we have compiled a range of products
that offers something for everyone... from top quality bed
line designs and cookwave to top brand clectronics and
appliance.
CUSTOMER
CARE PLAN
everythinmg you order from us is covered by our
compreliensive home choice customewre care plan. what
does that mean to me? i hear you ask. peace of mind is
what you get?
MAIN
PRODUCTS:
RADIO CD ...ONE YEAR GURANTEE:
Nu-tec 3cd hi-fi
Lg 3cd hi-fi
sansui 3cd battery/mains hi fi
sansui 5cd battery/mains hi fi
nu tec 5cd hi fi
homechoice 3cd hi fi
telefunken 3cd hi fi
VIDEO RECORDER:
LG 2-head video recorder
sansui diamond 3 head
sansui 2-head video recorder
MICROWAVE COOKING:
hot plate combo
home choice tow-tone combo
frying pan combo
estia delux grill
ideal multi griller
zass combo griller
home choice mini oven
deluxe table top stove
twister blender
sunbeam kitchen helper
magicline magi mixa
magicline food processor and blender
microwave with grill
stainless steel microwave
stock pot
CURTAIN:
Spring flower curtain
christina curtain
doruble drops curtain
luxury set colorado curtain
BED BLANKET:
electronics blanket
bed blanket
PHONES DETAILS
Nokia 6630 185 USD
Nokia 6650 20 USD
Nokia 6670 180 USD
Nokia 6680 200 USD
Nokia 6681 230 USD
Nokia 6810 250 USD
Nokia 6820 20 USD
Nokia 7200 120 USD
Nokia 7250 55 USD
Nokia 7250i 70 USD
Nokia 7260 85 USD
Nokia 7270 170 USD
Nokia 7280 190 USD
Nokia 7600 200 USD
Nokia 7610 185 USD
Nokia 7650 95 USD
Nokia 7710 260 USD
Nokia 7700 255 USD
Nokia 8800 260 USD
Nokia 8910i 110 USD
Nokia 9500 300 USD
Nokia 9300 190 USD
Nokia N70 285 USD
Nokia N90 300 USD
Nokia N91 325 USD
Sonyericsson P910i 295 USD
Sonyericsson p910a 320 USD
Sonyericsson P900 230 USD
Sonyericsson k750i 180 USD
Sonyericsson K700i 150 USD
Sonyericsson T610i 170 USD
Sonyericsson T630 130 USD
Sonyericsson K500i 200 USD
Sonyericsson W800 180 USD
whether its lastest vcr or a beautiful bed linen set that you
are intrested in, rest assured that your order we be
delivered to your door. thats right... place your order from
the comfort of your favourite chair and then just sit back
and relax? well take care of everything?
SPEEDY DELIVERY...
PLASE PROVIDE ALL THE DETAILS WE ASK FOR ON YOUR
ORDER FROM, AS THIS WILL ENABLE US TO APPROVE
YOUR ORDER QUICKLY AND SAEND TO YOU YOUR GOODS
STRAIGHT AWAY. THE FOLLOWNNG INFORMATION IS
ESPECIALLY IMPORTANT
INPORTANT INFORMATION:
. WHAT YOU WANT TO ORDER.
. YOUR STREET ADDRESS: IF YOU WANT TO USE OUR
CONVENIENT HOME CHOICE DELIVER SERVICE.
. YOUR TELEPHONE NUMBER
IMPORTANT:
IF YOU HAVE ANY QUERIES ABOUT OUR PRODUCTS AND
SERVICE S, PLEASE E-MAIL US ON homechoice2005
@yahoo.comOUR FRIENDLY CUSTOMER SERVICE
REPRESENTATIVES ARE ALWAYS READY TO HELP YOU.
MONDAY TO SATURDAY FROM 8.30 AM TO 7PM. FRIDAY
8.30AM TO 1.PM .
EASYPAYMENTTHROUGH.
.WESTERN UNIOR MONEY TRANSFER
. POSTING THROUGH OUR COMPANY ADDRESS
. T/T BANK
Previous Comments:
[2005-07-05 11:15:34] Bjorn dot Wiberg at its dot uu dot se
Hi again!
(Thanks for fixing the mpm_common crash, that problem is gone now.)
I'm pasting some test results (also used in bug #53201) here.
All the following with #define HAVE_BROKEN_GETCWD 1 in
main/php_config.h, and the following code (tests 1-4):
?php
print getcwd() . BR;
$handle = fopen(a.txt, w, false);
if ( $handle != FALSE ) {
fputs($handle, testtext);
fclose($handle);
}
?
..and, respectively (tests 5-8):
?php
print getcwd() . BR;
$handle = fopen(./a.txt, w, false);
if ( $handle != FALSE ) {
fputs($handle, testtext);
fclose($handle);
}
?
1. No existing a.txt file in the destination directory. With the
read flag missing to the test directory along the path, and write
permissions to the destination directory:
Warning: fopen():
#32503 [Com]: fopen() in cwd: filename must start with ./ under safe mode
ID: 32503 Comment by: homechoice2005 at yahoo dot com Reported By: Bjorn dot Wiberg at its dot uu dot se Status: Open Bug Type: Filesystem function related Operating System: IBM AIX 5.2.0.0 ML5 PHP Version: 5CVS-2005-07-05 New Comment: You are welcome to home choice your online choice to day... here at home choice , our goal is to make your shoppoing experience better, faster, easier and safer than ever before? that is why we have compiled a range of products that offers something for everyone... from top quality bed line designs and cookwave to top brand clectronics and appliance. CUSTOMER CARE PLAN everythinmg you order from us is covered by our compreliensive home choice customewre care plan. what does that mean to me? i hear you ask. peace of mind is what you get? MAIN PRODUCTS: RADIO CD ...ONE YEAR GURANTEE: Nu-tec 3cd hi-fi Lg 3cd hi-fi sansui 3cd battery/mains hi fi sansui 5cd battery/mains hi fi nu tec 5cd hi fi homechoice 3cd hi fi telefunken 3cd hi fi VIDEO RECORDER: LG 2-head video recorder sansui diamond 3 head sansui 2-head video recorder MICROWAVE COOKING: hot plate combo home choice tow-tone combo frying pan combo estia delux grill ideal multi griller zass combo griller home choice mini oven deluxe table top stove twister blender sunbeam kitchen helper magicline magi mixa magicline food processor and blender microwave with grill stainless steel microwave stock pot CURTAIN: Spring flower curtain christina curtain doruble drops curtain luxury set colorado curtain BED BLANKET: electronics blanket bed blanket PHONES DETAILS Nokia 6630 185 USD Nokia 6650 20 USD Nokia 6670 180 USD Nokia 6680 200 USD Nokia 6681 230 USD Nokia 6810 250 USD Nokia 6820 20 USD Nokia 7200 120 USD Nokia 7250 55 USD Nokia 7250i 70 USD Nokia 7260 85 USD Nokia 7270 170 USD Nokia 7280 190 USD Nokia 7600 200 USD Nokia 7610 185 USD Nokia 7650 95 USD Nokia 7710 260 USD Nokia 7700 255 USD Nokia 8800 260 USD Nokia 8910i 110 USD Nokia 9500 300 USD Nokia 9300 190 USD Nokia N70 285 USD Nokia N90 300 USD Nokia N91 325 USD Sonyericsson P910i 295 USD Sonyericsson p910a 320 USD Sonyericsson P900 230 USD Sonyericsson k750i 180 USD Sonyericsson K700i 150 USD Sonyericsson T610i 170 USD Sonyericsson T630 130 USD Sonyericsson K500i 200 USD Sonyericsson W800 180 USD whether its lastest vcr or a beautiful bed linen set that you are intrested in, rest assured that your order we be delivered to your door. thats right... place your order from the comfort of your favourite chair and then just sit back and relax? well take care of everything? SPEEDY DELIVERY... PLASE PROVIDE ALL THE DETAILS WE ASK FOR ON YOUR ORDER FROM, AS THIS WILL ENABLE US TO APPROVE YOUR ORDER QUICKLY AND SAEND TO YOU YOUR GOODS STRAIGHT AWAY. THE FOLLOWNNG INFORMATION IS ESPECIALLY IMPORTANT INPORTANT INFORMATION: . WHAT YOU WANT TO ORDER. . YOUR STREET ADDRESS: IF YOU WANT TO USE OUR CONVENIENT HOME CHOICE DELIVER SERVICE. . YOUR TELEPHONE NUMBER IMPORTANT: IF YOU HAVE ANY QUERIES ABOUT OUR PRODUCTS AND SERVICE S, PLEASE E-MAIL US ON homechoice2005 @yahoo.comOUR FRIENDLY CUSTOMER SERVICE REPRESENTATIVES ARE ALWAYS READY TO HELP YOU. MONDAY TO SATURDAY FROM 8.30 AM TO 7PM. FRIDAY 8.30AM TO 1.PM . EASYPAYMENTTHROUGH. .WESTERN UNIOR MONEY TRANSFER . POSTING THROUGH OUR COMPANY ADDRESS . T/T BANK Previous Comments: [2005-12-01 01:18:14] homechoice2005 at yahoo dot com You are welcome to home choice your online choice to day... here at home choice , our goal is to make your shoppoing experience better, faster, easier and safer than ever before? that is why we have compiled a range of products that offers something for everyone... from top quality bed line designs and cookwave to top brand clectronics and appliance. CUSTOMER CARE PLAN everythinmg you order from us is covered by our compreliensive home choice customewre care plan. what does that mean to me? i hear you ask. peace of mind is what you get? MAIN PRODUCTS: RADIO CD ...ONE YEAR GURANTEE: Nu-tec
#35497 [Bgs]: Difference between echo and printf
ID: 35497 Updated by: [EMAIL PROTECTED] Reported By: viperjason at gmail dot com Status: Bogus Bug Type: Scripting Engine problem Operating System: Windows XP SP2 PHP Version: 5CVS-2005-11-30 (CVS) New Comment: /usr/include/limits.h: #define LONG_MAX 2147483647L # php -r 'var_dump(0x.dechex(2147483647));' string(10) 0x7fff # php -r 'var_dump(0x800F);' float(2147483663) Previous Comments: [2005-12-01 00:54:13] viperjason at gmail dot com I thought ints were 32bits? 0x800F is a 32 bit value. [2005-11-30 23:11:00] [EMAIL PROTECTED] $a = 0x800F; In this case $a is bigger than int, so the engine converts it to float automatically. printf(%d) casts it back to int and you get negative value as the result. echo (int)$a; will give you the same. In all the other cases echo printf() give the very same results. No bug here. [2005-11-30 22:51:59] viperjason at gmail dot com Description: If you look at the code I initialize a 32bit hex value and print it with both printf and echo. I do a AND and a OR to get the value back to the original value and print it again with printf and echo. Printf and echo disaggree on the first print Printf and echo agree on the second print Printf and echo agree on the third print. What happened with the first print? I realize you use signed integers.but where is my sign? Reproduce code: --- ? $a = 0x800F; printf(hex=%x, dec=%d by printf\n,$a,$a); echo $a.by echo\n; $a = $a 0x0FFF; printf(hex=%x, dec=%d by printf\n,$a,$a); echo $a.\n; $a = $a | 0x8000; printf(hex=%x, dec=%d by printf\n,$a,$a); echo $a.\n; ? Expected result: I expect both printf and echo to consistantly print out the same decimal result. Actual result: -- The first time they didnt and second time they did. -- Edit this bug report at http://bugs.php.net/?id=35497edit=1
