#37674 [Asn]: exception not thrown in multi_query's
ID: 37674
User updated by: camka at email dot ee
Reported By: camka at email dot ee
Status: Assigned
Bug Type: MySQLi related
Operating System: Windows XP
PHP Version: 5.1.4
Assigned To: georg
New Comment:
Same problem with latest cvs snapshot.
Previous Comments:
[2006-06-02 09:56:46] camka at email dot ee
Sorry. Expected and actual results are mixed.
[2006-06-02 09:55:03] camka at email dot ee
Description:
When trying to execute multiple queryes with multi_query method, when
first query is ok, and second one is broken, the exception is not
thrown when iterating second function's resultset of the multiquery.
Only ::error is set.
Reproduce code:
---
multi_query('select 1; bug;');
do {
/* store first result set */
if ($result = $m->store_result())
{
while ($row = $result->fetch_row())
{
printf("%s\n", $row[0]);
}
$result->close();
}
/* print divider */
if ($m->more_results()) {
printf("-\n");
}
}
while ($m->next_result());
echo $m->error;
}
catch (mysqli_sql_exception $e)
{
var_dump($e);
}
Expected result:
1 - You have an error in your SQL syntax; check the
manual that corresponds to your MySQL server version for the right
syntax to use near 'bug' at line 1
Actual result:
--
1 -
object(mysqli_sql_exception)[2]
protected 'message' => 'You have an error in your SQL syntax; check
the manual that corresponds to your MySQL server version for the right
syntax to use near 'bug; bug' at line 1' (length=154)
private 'string' => '' (length=0)
protected 'code' => 1064
protected 'file' => '**' (length=35)
protected 'line' => 7
private 'trace' =>
array
0 =>
array
'file' => '**' (length=35)
'line' => 7
'function' => 'multi_query' (length=11)
'class' => 'mysqli' (length=6)
'type' => '->' (length=2)
'args' =>
array
0 => 'bug; bug;' (length=9)
protected 'sqlstate' => '42000' (length=5)
--
Edit this bug report at http://bugs.php.net/?id=37674&edit=1
#34005 [Asn->Csd]: ocipasswordchange() fails
ID: 34005 Updated by: [EMAIL PROTECTED] Reported By: uherj at avx dot cz -Status: Assigned +Status: Closed Bug Type: OCI8 related Operating System: * PHP Version: 5CVS, 4CVS (2005-12-25) (snap) Assigned To: tony2001 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: [2006-03-21 10:06:51] [EMAIL PROTECTED] >it really is a straight-forward function - it simply passes >the data from and to OCI's OCIPasswordChange call Yes, and this makes me wonder too. >cant' there be something set for you that disallows you to >change the password during the Grace Period? I'm not sure about the grace period, but I can't change my own password also, which is equal to "system". [2006-03-21 03:53:09] [EMAIL PROTECTED] Hi, I heard about this very problem from my collegue just the other day. The weird fact is that I actually have added OCIPasswordChange() function myself yet in PHP v4.3.2 ad it really is a straight-forward function - it simply passes the data from and to OCI's OCIPasswordChange call. So there is no interacion with the data submitted. I still have no clear solution but I am guessing that this may relay to OCI itself, not really PHP's OCI8 extension. Anyone has any ideas? ORA-28002 is simply a warning that that your old password is about to expire, cant' there be something set for you that disallows you to change the password during the Grace Period? Did you try changing the password in PL/SQL to see if it's doable for your case? Are there any funny characters in your old password that can be interpreted wrongly? If so, try replicating the problem with a password made of [a-z0-9] and see if problem persists.. Nothing else comes to my mind Let me know. maxim [2006-01-05 23:55:07] [EMAIL PROTECTED] No. Feel free to provide one. [2006-01-05 23:40:48] gcombe at co dot weber dot ut dot us so is there a fix for this or not? [2005-12-26 17:26:27] [EMAIL PROTECTED] Assuming this happens also with new oci code. 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/34005 -- Edit this bug report at http://bugs.php.net/?id=34005&edit=1
#37689 [Opn->Fbk]: Read buffer out of sync with issued commands
ID: 37689
Updated by: [EMAIL PROTECTED]
Reported By: jasper dot e at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: FTP related
Operating System: Fedora Core 2
PHP Version: 5.1.4
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
Previous Comments:
[2006-06-03 22:45:36] jasper dot e at gmail dot com
Description:
I have a piece of code crawling an ftp site, ftp_chdir()'ing and
ftp_get()'ing a lot of files troughout the ftp dirtree.
I have noticed, that after a failed ftp_get() the read buffer often
goes out of sync with the issued commands.
In other words; an ftp_chdir() command shows a warning with the result
message from a previous command.
Here's an example PHP warning:
Warning: ftp_chdir() [function.ftp-chdir]: ABOR command
successful. in /home/frozen/frozftp.class.php on line
93
Reproduce code:
---
The code this error originates from has the following snippet in it,
which is called for each dir it's supposed to crawl:
if ($SFTP->cwd($dirname) === false) { $SFTP->abor(); return false; }
The cwd and abor functions from the SFTP class:
function cwd($path)
{
return (ftp_chdir($this->fd,$path)) ? true : false;
}
function abor()
{
ftp_raw($this->fd,"ABOR");
}
Expected result:
I would expect the ftp_chdir() function to return a true value
Actual result:
--
A warning message from the ftp_chdir() with the result from a previous
command in it.
--
Edit this bug report at http://bugs.php.net/?id=37689&edit=1
#37691 [Opn->Fbk]: unexpected default umask
ID: 37691 Updated by: [EMAIL PROTECTED] Reported By: calin at action dot ro -Status: Open +Status: Feedback Bug Type: *Directory/Filesystem functions Operating System: Redhat Linux AS4 U3 PHP Version: 5.1.4 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: [2006-06-03 23:33:53] calin at action dot ro Description: Hello! I am using PHP compiled as DSO. Echoing the umask() I get 79 (117 octal). My system sets the 0022 mask for the apache environment. How can this default mask be set globaly for the server environment (php.ini?) ? Maybe related to #36630??? (even though bug is marked as closed) Reproduce code: --- echo umask(); Expected result: 18 which will be 22 octal because the environment in which apache runs has 0022 mask AND clear explanations in documentation on how php gets it's default mask settings Actual result: -- the output of echo command: 79 -- Edit this bug report at http://bugs.php.net/?id=37691&edit=1
#37695 [Opn->Bgs]: httpd: child pid 11864 exit signal Segmentation fault (11)
ID: 37695 Updated by: [EMAIL PROTECTED] Reported By: gplerma at yahoo dot com -Status: Open +Status: Bogus Bug Type: Reproducible crash Operating System: Red Hat Enterprise Linux ES rele PHP Version: 5.1.4 New Comment: You apache was compiled with -D_FILE_OFFSET_BITS=64, while your PHP was not or vice versa. This means that structures like off_t became off64_t and changed their size. Not PHP problem. Previous Comments: [2006-06-04 17:13:49] gplerma at yahoo dot com Description: Good day (or night), I am needing asssistance with a particularly nasty problem with Apache/PHP (I'm not quite sure which is the culprit yet). I checked bug log, however didnt seem to find any issue relating to this one. I Compiled apache/php 5.1.4/oracle10g/ on RH Ent 4 (ES) w latest OS updates. Following startup of httpd, i am seeing constant seg faults within the httpd error_logs during ANY page GET request: [Sun Jun 04 11:41:12 2006] [notice] child pid 29592 exit signal Segmentation fault (11) [Sun Jun 04 11:41:12 2006] [notice] child pid 29593 exit signal Segmentation fault (11) [Sun Jun 04 11:41:13 2006] [notice] child pid 29597 exit signal Segmentation fault (11) [Sun Jun 04 11:41:13 2006] [notice] child pid 29598 exit signal Segmentation fault (11) [Sun Jun 04 11:41:13 2006] [notice] child pid 29599 exit signal Segmentation fault (11) [Sun Jun 04 11:41:13 2006] [notice] child pid 29600 exit signal Segmentation fault (11) httpd configure options: ./configure --enable-so --prefix=/usr/software/apache --with-apr=/usr/software/apr-httpd/ \ --with-apr-util=/usr/software/apr-util-httpd --with-mpm=prefork --enable-mods-shared=most \ --enable-ssl=shared --with-ssl=/usr/software/openssl --enable-deflate php configure options: ./configure --prefix=/usr/software/php --with-config-file-path=/usr/software/php/etc \ --enable-so=shared --with-apxs2=/usr/software/apache/bin/apxs --enable-dbase \ --with-pfpro=/usr/software/verisign/payflowpro/linux --with-oci8=/usr/software/oracle/product/10.2.0/db_1 \ --with-gd --with-png-dir=/usr/software/libpng/ --with-zlib-dir=/usr/software/zlib/ \ --with-freetype-dir=/usr/software/freetype Compile Order was 1. Source Apr (Compiled the packaged apr) 2. Source Apr Utils (Compiled the packaged apr-util) 3. Apache HTTPD 4. PHP GCC Info: gcc -v Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.5/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux Thread model: posix gcc version 3.4.5 20051201 (Red Hat 3.4.5-2) I have also tried latest snapshot: php5.2-200606041430 to no avail. This crash only occurs if loading the php5 module (i.e. LoadModule php5_modulemodules/libphp5.so) If i comment this line, then restart apache, no crashing. I appreciate your valuable time and assistance with this. Regards, George Actual result: -- I ran a backtrace on httpd. This is the results after trying to load a simple HTML page: [EMAIL PROTECTED] apache]# gdb httpd GNU gdb Red Hat Linux (6.3.0.0-1.96rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) run -X -d /usr/software/apache Starting program: /usr/software/apache/bin/httpd -X -d /usr/software/apache [Thread debugging using libthread_db enabled] [New Thread -1208046752 (LWP 29614)] httpd: Could not reliably determine the server's fully qualified domain name, using mfc-prod01.multifamilycentral.priv for ServerName Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208046752 (LWP 29614)] 0x0128f332 in php_handler (r=0x9656f08) at /usr/compileFactory/php-5.1.4/sapi/apache2handler/sapi_apache2.c:472 472 conf = ap_get_module_config(r->per_dir_config, &php5_module); -- Edit this bug report at http://bugs.php.net/?id=37695&edit=1
#37698 [NEW]: select on a synonym through a database link
From: james at redeye dot com Operating system: Linux Advanced Server 3.4 PHP version: 5.1.4 PHP Bug Type: PDO related Bug description: select on a synonym through a database link Description: I have a synonym in my Oracle 10g database that points to a table on a 9i database. A database link is used to do this. If I do a select * on this table a segmentation fault is produced in php. If I do the select with a where clause or by specifying the fields I want then PHP works ok Reproduce code: --- select * from segment // Causes segmentation fault select * from segment where name like '%MR%' // works ok select name from segment // works ok Expected result: returns the matches from the sql. Actual result: -- PHP segmentation fault. -- Edit bug report at http://bugs.php.net/?id=37698&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37698&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=37698&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37698&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37698&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37698&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37698&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37698&r=needscript Try newer version:http://bugs.php.net/fix.php?id=37698&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37698&r=support Expected behavior:http://bugs.php.net/fix.php?id=37698&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37698&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37698&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37698&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37698&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37698&r=dst IIS Stability:http://bugs.php.net/fix.php?id=37698&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37698&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37698&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37698&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37698&r=mysqlcfg
#37698 [Opn->Fbk]: select on a synonym through a database link
ID: 37698 Updated by: [EMAIL PROTECTED] Reported By: james at redeye dot com -Status: Open +Status: Feedback Bug Type: PDO related Operating System: Linux Advanced Server 3.4 PHP Version: 5.1.4 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. Previous Comments: [2006-06-05 08:17:12] james at redeye dot com Description: I have a synonym in my Oracle 10g database that points to a table on a 9i database. A database link is used to do this. If I do a select * on this table a segmentation fault is produced in php. If I do the select with a where clause or by specifying the fields I want then PHP works ok Reproduce code: --- select * from segment // Causes segmentation fault select * from segment where name like '%MR%' // works ok select name from segment // works ok Expected result: returns the matches from the sql. Actual result: -- PHP segmentation fault. -- Edit this bug report at http://bugs.php.net/?id=37698&edit=1
#37698 [Fbk->Opn]: select on a synonym through a database link
ID: 37698 User updated by: james at redeye dot com Reported By: james at redeye dot com -Status: Feedback +Status: Open Bug Type: PDO related Operating System: Linux Advanced Server 3.4 PHP Version: 5.1.4 New Comment: #0 0x011e0009 in ttcfopr () from /u01/app/oracle/product/920/lib/libclntsh.so.9.0 #1 0x011d6341 in ttcdrv () from /u01/app/oracle/product/920/lib/libclntsh.so.9.0 #2 0x0104636d in nioqwa () from /u01/app/oracle/product/920/lib/libclntsh.so.9.0 #3 0x00ef9ec0 in upirtrc () from /u01/app/oracle/product/920/lib/libclntsh.so.9.0 #4 0x00ea294d in kpurcsc () from /u01/app/oracle/product/920/lib/libclntsh.so.9.0 #5 0x00e62ff9 in kpuexecv8 () from /u01/app/oracle/product/920/lib/libclntsh.so.9.0 #6 0x00e64abe in kpuexec () from /u01/app/oracle/product/920/lib/libclntsh.so.9.0 #7 0x00ec3c2c in OCIStmtExecute () from /u01/app/oracle/product/920/lib/libclntsh.so.9.0 #8 0x080ff70b in oci_stmt_execute (stmt=0x9174a74) at /usr/local/src/php-5.1.4/ext/pdo_oci/oci_statement.c:142 #9 0x080f8bc9 in zif_PDOStatement_execute (ht=0, return_value=0x916f6ec, return_value_ptr=0x0, this_ptr=0x916f7d4, return_value_used=0) at /usr/local/src/php-5.1.4/ext/pdo/pdo_stmt.c:451 #10 0x081fc669 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfff8bb0) at zend_vm_execute.h:200 #11 0x081fbf8d in execute (op_array=0x916b394) at zend_vm_execute.h:92 #12 0x00592920 in zend_oe () from /usr/local/Zend/lib/Optimizer-2.6.1/php-5.1.x/ZendOptimizer.so #13 0x0916b394 in ?? () #14 0x0090d180 in run_fp () from /lib/tls/libc.so.6 #15 0x0df0 in ?? () #16 0xbfff8c28 in ?? () #17 0x00848e9d in malloc () from /lib/tls/libc.so.6 Previous Comments: [2006-06-05 08:44:29] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2006-06-05 08:17:12] james at redeye dot com Description: I have a synonym in my Oracle 10g database that points to a table on a 9i database. A database link is used to do this. If I do a select * on this table a segmentation fault is produced in php. If I do the select with a where clause or by specifying the fields I want then PHP works ok Reproduce code: --- select * from segment // Causes segmentation fault select * from segment where name like '%MR%' // works ok select name from segment // works ok Expected result: returns the matches from the sql. Actual result: -- PHP segmentation fault. -- Edit this bug report at http://bugs.php.net/?id=37698&edit=1
#37698 [Opn->Fbk]: select on a synonym through a database link
ID: 37698 Updated by: [EMAIL PROTECTED] Reported By: james at redeye dot com -Status: Open +Status: Feedback Bug Type: PDO related Operating System: Linux Advanced Server 3.4 PHP Version: 5.1.4 New Comment: Doesn't seem to be related to PHP.. Please try to rebuild PHP with the latest Oracle Instant Client and see if it helps. See also bug #36607. Previous Comments: [2006-06-05 09:42:34] james at redeye dot com #0 0x011e0009 in ttcfopr () from /u01/app/oracle/product/920/lib/libclntsh.so.9.0 #1 0x011d6341 in ttcdrv () from /u01/app/oracle/product/920/lib/libclntsh.so.9.0 #2 0x0104636d in nioqwa () from /u01/app/oracle/product/920/lib/libclntsh.so.9.0 #3 0x00ef9ec0 in upirtrc () from /u01/app/oracle/product/920/lib/libclntsh.so.9.0 #4 0x00ea294d in kpurcsc () from /u01/app/oracle/product/920/lib/libclntsh.so.9.0 #5 0x00e62ff9 in kpuexecv8 () from /u01/app/oracle/product/920/lib/libclntsh.so.9.0 #6 0x00e64abe in kpuexec () from /u01/app/oracle/product/920/lib/libclntsh.so.9.0 #7 0x00ec3c2c in OCIStmtExecute () from /u01/app/oracle/product/920/lib/libclntsh.so.9.0 #8 0x080ff70b in oci_stmt_execute (stmt=0x9174a74) at /usr/local/src/php-5.1.4/ext/pdo_oci/oci_statement.c:142 #9 0x080f8bc9 in zif_PDOStatement_execute (ht=0, return_value=0x916f6ec, return_value_ptr=0x0, this_ptr=0x916f7d4, return_value_used=0) at /usr/local/src/php-5.1.4/ext/pdo/pdo_stmt.c:451 #10 0x081fc669 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfff8bb0) at zend_vm_execute.h:200 #11 0x081fbf8d in execute (op_array=0x916b394) at zend_vm_execute.h:92 #12 0x00592920 in zend_oe () from /usr/local/Zend/lib/Optimizer-2.6.1/php-5.1.x/ZendOptimizer.so #13 0x0916b394 in ?? () #14 0x0090d180 in run_fp () from /lib/tls/libc.so.6 #15 0x0df0 in ?? () #16 0xbfff8c28 in ?? () #17 0x00848e9d in malloc () from /lib/tls/libc.so.6 [2006-06-05 08:44:29] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2006-06-05 08:17:12] james at redeye dot com Description: I have a synonym in my Oracle 10g database that points to a table on a 9i database. A database link is used to do this. If I do a select * on this table a segmentation fault is produced in php. If I do the select with a where clause or by specifying the fields I want then PHP works ok Reproduce code: --- select * from segment // Causes segmentation fault select * from segment where name like '%MR%' // works ok select name from segment // works ok Expected result: returns the matches from the sql. Actual result: -- PHP segmentation fault. -- Edit this bug report at http://bugs.php.net/?id=37698&edit=1
#37665 [Fbk->Csd]: Exception messages from stream wrappers should be displayed
ID: 37665
User updated by: flconseil at yahoo dot fr
Reported By: flconseil at yahoo dot fr
-Status: Feedback
+Status: Closed
Bug Type: Feature/Change Request
Operating System: All
PHP Version: 5.1.4
New Comment:
Sorry, I had a 'catch' part in my code and the exception was trapped
before being sent to the calling code.
I still would have ideas for ways to catch exceptions in the stream
wrapper code but I need to think more about it before submitting a new
enhancement suggestion (for PHP 6). So I prefer to close this case.
Previous Comments:
[2006-06-01 11:58:33] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
[2006-06-01 11:57:16] flconseil at yahoo dot fr
Description:
When I send an exception from a stream wrapper method, the call fails
with a generic warning message from PHP, but the message I sent with my
exception is not displayed.
It would be a useful enhancement to add it to the error string.
(Tested in 5.1.2, should be the same in 5.1.4)
Reproduce code:
---
Example of an invalid URL :
include('phk://mnt1/toto');
Expected result:
If the exception->message was also displayed, it would give something
like :
PHP Warning: include(phk://mnt1/toto): failed to open stream: Error
opening PHK subfile - phk://mnt1/toto: Invalid URL - mnt1: Unknown PHK
mount point - "PHK_Stream::stream_open" call failed in ... on line 6
Actual result:
--
PHP Warning: include(phk://mnt1/toto): failed to open stream:
"PHK_Stream::stream_open" call failed in ... on line 6
I have no way to tell the user why his URL failed. And, as
STREAM_REPORT_ERRORS is unset, I am not allowed to raise any error from
my code.
--
Edit this bug report at http://bugs.php.net/?id=37665&edit=1
#37665 [Csd->Bgs]: Exception messages from stream wrappers should be displayed
ID: 37665
Updated by: [EMAIL PROTECTED]
Reported By: flconseil at yahoo dot fr
-Status: Closed
+Status: Bogus
Bug Type: Feature/Change Request
Operating System: All
PHP Version: 5.1.4
Previous Comments:
[2006-06-05 09:49:58] flconseil at yahoo dot fr
Sorry, I had a 'catch' part in my code and the exception was trapped
before being sent to the calling code.
I still would have ideas for ways to catch exceptions in the stream
wrapper code but I need to think more about it before submitting a new
enhancement suggestion (for PHP 6). So I prefer to close this case.
[2006-06-01 11:58:33] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
[2006-06-01 11:57:16] flconseil at yahoo dot fr
Description:
When I send an exception from a stream wrapper method, the call fails
with a generic warning message from PHP, but the message I sent with my
exception is not displayed.
It would be a useful enhancement to add it to the error string.
(Tested in 5.1.2, should be the same in 5.1.4)
Reproduce code:
---
Example of an invalid URL :
include('phk://mnt1/toto');
Expected result:
If the exception->message was also displayed, it would give something
like :
PHP Warning: include(phk://mnt1/toto): failed to open stream: Error
opening PHK subfile - phk://mnt1/toto: Invalid URL - mnt1: Unknown PHK
mount point - "PHK_Stream::stream_open" call failed in ... on line 6
Actual result:
--
PHP Warning: include(phk://mnt1/toto): failed to open stream:
"PHK_Stream::stream_open" call failed in ... on line 6
I have no way to tell the user why his URL failed. And, as
STREAM_REPORT_ERRORS is unset, I am not allowed to raise any error from
my code.
--
Edit this bug report at http://bugs.php.net/?id=37665&edit=1
#37698 [Fbk->Opn]: select on a synonym through a database link
ID: 37698 User updated by: james at redeye dot com Reported By: james at redeye dot com -Status: Feedback +Status: Open Bug Type: PDO related Operating System: Linux Advanced Server 3.4 PHP Version: 5.1.4 New Comment: Can't use the latest Oracle Instant Client as I use the ssh library and using the Oracle 10g client causes this not to work. It only works with the 9i client. Using Toad and the Oracle 9i client the query works fine. Using Toad and the Oracle 10g client the query works fine also. Previous Comments: [2006-06-05 09:49:17] [EMAIL PROTECTED] Doesn't seem to be related to PHP.. Please try to rebuild PHP with the latest Oracle Instant Client and see if it helps. See also bug #36607. [2006-06-05 09:42:34] james at redeye dot com #0 0x011e0009 in ttcfopr () from /u01/app/oracle/product/920/lib/libclntsh.so.9.0 #1 0x011d6341 in ttcdrv () from /u01/app/oracle/product/920/lib/libclntsh.so.9.0 #2 0x0104636d in nioqwa () from /u01/app/oracle/product/920/lib/libclntsh.so.9.0 #3 0x00ef9ec0 in upirtrc () from /u01/app/oracle/product/920/lib/libclntsh.so.9.0 #4 0x00ea294d in kpurcsc () from /u01/app/oracle/product/920/lib/libclntsh.so.9.0 #5 0x00e62ff9 in kpuexecv8 () from /u01/app/oracle/product/920/lib/libclntsh.so.9.0 #6 0x00e64abe in kpuexec () from /u01/app/oracle/product/920/lib/libclntsh.so.9.0 #7 0x00ec3c2c in OCIStmtExecute () from /u01/app/oracle/product/920/lib/libclntsh.so.9.0 #8 0x080ff70b in oci_stmt_execute (stmt=0x9174a74) at /usr/local/src/php-5.1.4/ext/pdo_oci/oci_statement.c:142 #9 0x080f8bc9 in zif_PDOStatement_execute (ht=0, return_value=0x916f6ec, return_value_ptr=0x0, this_ptr=0x916f7d4, return_value_used=0) at /usr/local/src/php-5.1.4/ext/pdo/pdo_stmt.c:451 #10 0x081fc669 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfff8bb0) at zend_vm_execute.h:200 #11 0x081fbf8d in execute (op_array=0x916b394) at zend_vm_execute.h:92 #12 0x00592920 in zend_oe () from /usr/local/Zend/lib/Optimizer-2.6.1/php-5.1.x/ZendOptimizer.so #13 0x0916b394 in ?? () #14 0x0090d180 in run_fp () from /lib/tls/libc.so.6 #15 0x0df0 in ?? () #16 0xbfff8c28 in ?? () #17 0x00848e9d in malloc () from /lib/tls/libc.so.6 [2006-06-05 08:44:29] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2006-06-05 08:17:12] james at redeye dot com Description: I have a synonym in my Oracle 10g database that points to a table on a 9i database. A database link is used to do this. If I do a select * on this table a segmentation fault is produced in php. If I do the select with a where clause or by specifying the fields I want then PHP works ok Reproduce code: --- select * from segment // Causes segmentation fault select * from segment where name like '%MR%' // works ok select name from segment // works ok Expected result: returns the matches from the sql. Actual result: -- PHP segmentation fault. -- Edit this bug report at http://bugs.php.net/?id=37698&edit=1
#37699 [NEW]: Apache crashes with fopen()
From: kim at steinhaug dot com
Operating system: Windows 2000
PHP version: 4CVS-2006-06-05 (snap)
PHP Bug Type: *URL Functions
Bug description: Apache crashes with fopen()
Description:
When accessing the fopen() function with an URL starting with http://
apache crashes.
Previous bugs states that this has been fixed in CVS, but the latest snap
still crashes.
First I upgraded to v4.4.2, I read alot of bugs and then I upgraded to the
latest snap but the bug is still here.
Reproduce code:
---
http://www.php.net/";;
$xhtml = '';
if($filehandle = @fopen($url, 'rb')) {
$xhtml = fread($filehandle, 4096);
fclose($filehandle);
echo "$xhtml";
}
?>
Expected result:
the HTML of the URL
Actual result:
--
Apache crashes and restarts.
--
Edit bug report at http://bugs.php.net/?id=37699&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=37699&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=37699&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=37699&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=37699&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=37699&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=37699&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=37699&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=37699&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=37699&r=support
Expected behavior:http://bugs.php.net/fix.php?id=37699&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=37699&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=37699&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=37699&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37699&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=37699&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=37699&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=37699&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=37699&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=37699&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=37699&r=mysqlcfg
#37699 [Opn->Bgs]: Apache crashes with fopen()
ID: 37699
User updated by: kim at steinhaug dot com
Reported By: kim at steinhaug dot com
-Status: Open
+Status: Bogus
Bug Type: *URL Functions
Operating System: Windows 2000
PHP Version: 4CVS-2006-06-05 (snap)
New Comment:
Forgot to copy the new .dll into system32 folder...
My bad, latest snap works like a charm!
Previous Comments:
[2006-06-05 10:42:52] kim at steinhaug dot com
Description:
When accessing the fopen() function with an URL starting with http://
apache crashes.
Previous bugs states that this has been fixed in CVS, but the latest
snap still crashes.
First I upgraded to v4.4.2, I read alot of bugs and then I upgraded to
the latest snap but the bug is still here.
Reproduce code:
---
http://www.php.net/";;
$xhtml = '';
if($filehandle = @fopen($url, 'rb')) {
$xhtml = fread($filehandle, 4096);
fclose($filehandle);
echo "$xhtml";
}
?>
Expected result:
the HTML of the URL
Actual result:
--
Apache crashes and restarts.
--
Edit this bug report at http://bugs.php.net/?id=37699&edit=1
#37698 [Opn->Fbk]: select on a synonym through a database link
ID: 37698 Updated by: [EMAIL PROTECTED] Reported By: james at redeye dot com -Status: Open +Status: Feedback Bug Type: PDO related Operating System: Linux Advanced Server 3.4 PHP Version: 5.1.4 New Comment: Did you try the patch from the last comment of bug #36607? Previous Comments: [2006-06-05 10:02:29] james at redeye dot com Can't use the latest Oracle Instant Client as I use the ssh library and using the Oracle 10g client causes this not to work. It only works with the 9i client. Using Toad and the Oracle 9i client the query works fine. Using Toad and the Oracle 10g client the query works fine also. [2006-06-05 09:49:17] [EMAIL PROTECTED] Doesn't seem to be related to PHP.. Please try to rebuild PHP with the latest Oracle Instant Client and see if it helps. See also bug #36607. [2006-06-05 09:42:34] james at redeye dot com #0 0x011e0009 in ttcfopr () from /u01/app/oracle/product/920/lib/libclntsh.so.9.0 #1 0x011d6341 in ttcdrv () from /u01/app/oracle/product/920/lib/libclntsh.so.9.0 #2 0x0104636d in nioqwa () from /u01/app/oracle/product/920/lib/libclntsh.so.9.0 #3 0x00ef9ec0 in upirtrc () from /u01/app/oracle/product/920/lib/libclntsh.so.9.0 #4 0x00ea294d in kpurcsc () from /u01/app/oracle/product/920/lib/libclntsh.so.9.0 #5 0x00e62ff9 in kpuexecv8 () from /u01/app/oracle/product/920/lib/libclntsh.so.9.0 #6 0x00e64abe in kpuexec () from /u01/app/oracle/product/920/lib/libclntsh.so.9.0 #7 0x00ec3c2c in OCIStmtExecute () from /u01/app/oracle/product/920/lib/libclntsh.so.9.0 #8 0x080ff70b in oci_stmt_execute (stmt=0x9174a74) at /usr/local/src/php-5.1.4/ext/pdo_oci/oci_statement.c:142 #9 0x080f8bc9 in zif_PDOStatement_execute (ht=0, return_value=0x916f6ec, return_value_ptr=0x0, this_ptr=0x916f7d4, return_value_used=0) at /usr/local/src/php-5.1.4/ext/pdo/pdo_stmt.c:451 #10 0x081fc669 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfff8bb0) at zend_vm_execute.h:200 #11 0x081fbf8d in execute (op_array=0x916b394) at zend_vm_execute.h:92 #12 0x00592920 in zend_oe () from /usr/local/Zend/lib/Optimizer-2.6.1/php-5.1.x/ZendOptimizer.so #13 0x0916b394 in ?? () #14 0x0090d180 in run_fp () from /lib/tls/libc.so.6 #15 0x0df0 in ?? () #16 0xbfff8c28 in ?? () #17 0x00848e9d in malloc () from /lib/tls/libc.so.6 [2006-06-05 08:44:29] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2006-06-05 08:17:12] james at redeye dot com Description: I have a synonym in my Oracle 10g database that points to a table on a 9i database. A database link is used to do this. If I do a select * on this table a segmentation fault is produced in php. If I do the select with a where clause or by specifying the fields I want then PHP works ok Reproduce code: --- select * from segment // Causes segmentation fault select * from segment where name like '%MR%' // works ok select name from segment // works ok Expected result: returns the matches from the sql. Actual result: -- PHP segmentation fault. -- Edit this bug report at http://bugs.php.net/?id=37698&edit=1
#37697 [Opn->Fbk]: get_queue() always fails
ID: 37697 Updated by: [EMAIL PROTECTED] Reported By: aeolianmeson at blitzeclipse dot com -Status: Open +Status: Feedback Bug Type: Semaphore related Operating System: Fed4 PHP Version: 5.1.4 New Comment: Works perfectly fine here: # php -r 'var_dump(msg_get_queue(1360265987));' resource(4) of type (sysvmsg queue) Previous Comments: [2006-06-05 04:17:39] aeolianmeson at blitzeclipse dot com Description: get_queue will always say that it is out of space, but space is abundant. Full SysV library is built. No idea even on how to debug this. Reproduce code: --- Expected result: No error. Actual result: -- PHP Warning: msg_get_queue(): failed for key 0x51140303: No space left on device in /clustershare/cluster/simplemsg.php on line 3 -- Edit this bug report at http://bugs.php.net/?id=37697&edit=1
#35886 [Asn]: file_get_contents() fails with some combinations of offset & maxlen
ID: 35886 Updated by: [EMAIL PROTECTED] Reported By: chris at lodesys dot com Status: Assigned Bug Type: Streams related Operating System: win32 only PHP Version: 5CVS-2006-01-03 (snap) Assigned To: wez New Comment: here is the patch: http://mega.ist.utl.pt/~ncpl/php_win_mmap_segfault.txt Previous Comments: [2006-03-02 22:50:13] piecia2000 at tlen dot pl Temporary solution (slighty slower): $fd = fopen($filename, "rb"); fseek($fd, $offset); $file = fread($fd, $size); fclose($fd); please fix file_get_contents(), [2006-02-23 07:21:30] ninive at gmx dot at Please fix this critical bug. [2006-02-08 02:23:46] chris at lodesys dot com The example test file is C:/php/news.txt (part of the PHP Windows distribution). It is 74 KB (75,800 bytes). Was having problems with files larger than that (say up to 170 KB). Didn't test with extra large files. [2006-02-08 00:50:26] [EMAIL PROTECTED] How big is the file? [2006-01-05 02:21:26] [EMAIL PROTECTED] OK, the problem is in the MapViewOfFile() call in php_stdiop_set_option(), because it is mapping less data than we've asked. It seems a windows problem to me, but I'm leaving open because this can be a serious bug (although I'm not able to fix 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/35886 -- Edit this bug report at http://bugs.php.net/?id=35886&edit=1
#37700 [NEW]: We does not have any method to find out number of loged in user at time in PHP
From: frnd4gan at yahoo dot com Operating system: windows PHP version: 4.4.3RC1 PHP Bug Type: Session related Bug description: We does not have any method to find out number of loged in user at time in PHP Description: We does not have any method to find out number of loged in user at time in PHP.While In .NET we can define application level variable to track the number of logged in user's but what about PHP? -- Edit bug report at http://bugs.php.net/?id=37700&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37700&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=37700&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37700&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37700&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37700&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37700&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37700&r=needscript Try newer version:http://bugs.php.net/fix.php?id=37700&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37700&r=support Expected behavior:http://bugs.php.net/fix.php?id=37700&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37700&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37700&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37700&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37700&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37700&r=dst IIS Stability:http://bugs.php.net/fix.php?id=37700&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37700&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37700&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37700&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37700&r=mysqlcfg
#37700 [Opn->Bgs]: We does not have any method to find out number of loged in user at time in PHP
ID: 37700 Updated by: [EMAIL PROTECTED] Reported By: frnd4gan at yahoo dot com -Status: Open +Status: Bogus Bug Type: Session related Operating System: windows PHP Version: 4.4.3RC1 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: [2006-06-05 13:28:52] frnd4gan at yahoo dot com Description: We does not have any method to find out number of loged in user at time in PHP.While In .NET we can define application level variable to track the number of logged in user's but what about PHP? -- Edit this bug report at http://bugs.php.net/?id=37700&edit=1
#37700 [Bgs]: We does not have any method to find out number of loged in user at time in PHP
ID: 37700 Updated by: [EMAIL PROTECTED] Reported By: frnd4gan at yahoo dot com Status: Bogus Bug Type: Session related -Operating System: windows +Operating System: * -PHP Version: 4.4.3RC1 +PHP Version: * 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. Your .NET forces you to use itself as user handling. PHP is not doing this in anyway. Instead you're supposed to use any technology you want to do that. For instance you might store logged in users in a database. If you you simply count the number of logged in users using an appropriate SQL statement. In case you use sessions you may count the generated session files or whatever you use for session storage. Previous Comments: [2006-06-05 13:34:32] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. . [2006-06-05 13:28:52] frnd4gan at yahoo dot com Description: We does not have any method to find out number of loged in user at time in PHP.While In .NET we can define application level variable to track the number of logged in user's but what about PHP? -- Edit this bug report at http://bugs.php.net/?id=37700&edit=1
#37701 [NEW]: fopen/file_get_contents failes on openning files over FTP
From: ionut dot aivanesei at amdocs dot com Operating system: Solaris PHP version: 5.1.4 PHP Bug Type: FTP related Bug description: fopen/file_get_contents failes on openning files over FTP Description: I cannot use fopen/file_get_contents on Solaris over FTP (the same is working fine in HP-UX, AIX). Reproduce code: --- ftp://[EMAIL PROTECTED]/filename'); ?> Expected result: contents of 'filename' should be printed Actual result: -- files is not opened and a warnign is shown: Warning: file_get_contents(ftp://[EMAIL PROTECTED]/filename) [function.file-get-contents]: failed to open stream: FTP server reports 500 'SIZE /filename': command not understood. in script.php on line 3 -- Edit bug report at http://bugs.php.net/?id=37701&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37701&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=37701&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37701&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37701&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37701&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37701&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37701&r=needscript Try newer version:http://bugs.php.net/fix.php?id=37701&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37701&r=support Expected behavior:http://bugs.php.net/fix.php?id=37701&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37701&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37701&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37701&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37701&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37701&r=dst IIS Stability:http://bugs.php.net/fix.php?id=37701&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37701&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37701&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37701&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37701&r=mysqlcfg
#37701 [Opn->Fbk]: fopen/file_get_contents failes on openning files over FTP
ID: 37701 Updated by: [EMAIL PROTECTED] Reported By: ionut dot aivanesei at amdocs dot com -Status: Open +Status: Feedback Bug Type: FTP related Operating System: Solaris PHP Version: 5.1.4 New Comment: What kind of FTP server is that? Previous Comments: [2006-06-05 13:41:59] ionut dot aivanesei at amdocs dot com Description: I cannot use fopen/file_get_contents on Solaris over FTP (the same is working fine in HP-UX, AIX). Reproduce code: --- ftp://[EMAIL PROTECTED]/filename'); ?> Expected result: contents of 'filename' should be printed Actual result: -- files is not opened and a warnign is shown: Warning: file_get_contents(ftp://[EMAIL PROTECTED]/filename) [function.file-get-contents]: failed to open stream: FTP server reports 500 'SIZE /filename': command not understood. in script.php on line 3 -- Edit this bug report at http://bugs.php.net/?id=37701&edit=1
#37701 [Fbk->Opn]: fopen/file_get_contents failes on openning files over FTP
ID: 37701 User updated by: ionut dot aivanesei at amdocs dot com Reported By: ionut dot aivanesei at amdocs dot com -Status: Feedback +Status: Open Bug Type: FTP related Operating System: Solaris PHP Version: 5.1.4 New Comment: it is the default FTP server which comes with SunOS 5.x Previous Comments: [2006-06-05 13:53:37] [EMAIL PROTECTED] What kind of FTP server is that? [2006-06-05 13:41:59] ionut dot aivanesei at amdocs dot com Description: I cannot use fopen/file_get_contents on Solaris over FTP (the same is working fine in HP-UX, AIX). Reproduce code: --- ftp://[EMAIL PROTECTED]/filename'); ?> Expected result: contents of 'filename' should be printed Actual result: -- files is not opened and a warnign is shown: Warning: file_get_contents(ftp://[EMAIL PROTECTED]/filename) [function.file-get-contents]: failed to open stream: FTP server reports 500 'SIZE /filename': command not understood. in script.php on line 3 -- Edit this bug report at http://bugs.php.net/?id=37701&edit=1
#37701 [Opn->Bgs]: fopen/file_get_contents failes on openning files over FTP
ID: 37701 Updated by: [EMAIL PROTECTED] Reported By: ionut dot aivanesei at amdocs dot com -Status: Open +Status: Bogus Bug Type: FTP related Operating System: Solaris PHP Version: 5.1.4 New Comment: Duplicate of bug #35765. Previous Comments: [2006-06-05 14:12:26] ionut dot aivanesei at amdocs dot com it is the default FTP server which comes with SunOS 5.x [2006-06-05 13:53:37] [EMAIL PROTECTED] What kind of FTP server is that? [2006-06-05 13:41:59] ionut dot aivanesei at amdocs dot com Description: I cannot use fopen/file_get_contents on Solaris over FTP (the same is working fine in HP-UX, AIX). Reproduce code: --- ftp://[EMAIL PROTECTED]/filename'); ?> Expected result: contents of 'filename' should be printed Actual result: -- files is not opened and a warnign is shown: Warning: file_get_contents(ftp://[EMAIL PROTECTED]/filename) [function.file-get-contents]: failed to open stream: FTP server reports 500 'SIZE /filename': command not understood. in script.php on line 3 -- Edit this bug report at http://bugs.php.net/?id=37701&edit=1
#37701 [Bgs]: fopen/file_get_contents fails on opening files over FTP
ID: 37701 User updated by: ionut dot aivanesei at amdocs dot com -Summary: fopen/file_get_contents failes on openning files over FTP Reported By: ionut dot aivanesei at amdocs dot com Status: Bogus Bug Type: FTP related Operating System: Solaris PHP Version: 5.1.4 New Comment: I know that, but do you have a solution or a workaround? I really cannot continue with this error and I don't know how to avoid it. Any help will be much appreciated. Thanks, Ionutz Previous Comments: [2006-06-05 14:37:22] [EMAIL PROTECTED] Duplicate of bug #35765. [2006-06-05 14:12:26] ionut dot aivanesei at amdocs dot com it is the default FTP server which comes with SunOS 5.x [2006-06-05 13:53:37] [EMAIL PROTECTED] What kind of FTP server is that? [2006-06-05 13:41:59] ionut dot aivanesei at amdocs dot com Description: I cannot use fopen/file_get_contents on Solaris over FTP (the same is working fine in HP-UX, AIX). Reproduce code: --- ftp://[EMAIL PROTECTED]/filename'); ?> Expected result: contents of 'filename' should be printed Actual result: -- files is not opened and a warnign is shown: Warning: file_get_contents(ftp://[EMAIL PROTECTED]/filename) [function.file-get-contents]: failed to open stream: FTP server reports 500 'SIZE /filename': command not understood. in script.php on line 3 -- Edit this bug report at http://bugs.php.net/?id=37701&edit=1
#37702 [NEW]: Make toString working with strval
From: php at bouchery dot com Operating system: All PHP version: 5.1.4 PHP Bug Type: Feature/Change Request Bug description: Make toString working with strval Description: Currently, __toString work ONLY with echo/print, and it's very restrictive. It could be very interresting to allow toString working with strval() to avoid this : __toString(); else $text = 'var = ' . $var; ?> Expected result: Or better : -- Edit bug report at http://bugs.php.net/?id=37702&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37702&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=37702&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37702&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37702&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37702&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37702&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37702&r=needscript Try newer version:http://bugs.php.net/fix.php?id=37702&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37702&r=support Expected behavior:http://bugs.php.net/fix.php?id=37702&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37702&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37702&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37702&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37702&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37702&r=dst IIS Stability:http://bugs.php.net/fix.php?id=37702&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37702&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37702&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37702&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37702&r=mysqlcfg
#37702 [Opn->Csd]: Make toString working with strval
ID: 37702 Updated by: [EMAIL PROTECTED] Reported By: php at bouchery dot com -Status: Open +Status: Closed Bug Type: Feature/Change Request -Operating System: All +Operating System: * -PHP Version: 5.1.4 +PHP Version: 5.1.* -Assigned To: +Assigned To: helly 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. Cannot be fixed in 5.1 and is already fixed in HEAD and 5.2 Previous Comments: [2006-06-05 15:29:08] php at bouchery dot com Description: Currently, __toString work ONLY with echo/print, and it's very restrictive. It could be very interresting to allow toString working with strval() to avoid this : __toString(); else $text = 'var = ' . $var; ?> Expected result: Or better : -- Edit this bug report at http://bugs.php.net/?id=37702&edit=1
#37680 [Opn->Fbk]: PHP 4.3.11 to PHP 5.1.4
ID: 37680 Updated by: [EMAIL PROTECTED] Reported By: gnanavelan dot muthukrishnan at kumaran dot com -Status: Open +Status: Feedback Bug Type: Sybase-ct (ctlib) related Operating System: Linux PHP Version: 5.1.4 New Comment: if you use sybase_connect() does the code work as expected? Previous Comments: [2006-06-02 14:52:12] gnanavelan dot muthukrishnan at kumaran dot com Description: We are migrating from php 4.3.11 to php 5.1.4. The connection has established using mssql_pconnect(). But sybase_query() using that link id is not working in php 5.1.4 whereas it works in php 4.3.11. Same way the link id returned by sybase_pconnect() does not work for mssql_query(). but this works in php 4.3.11. Below source code used the link id of mssql_pconnect() Reproduce code: --- $sSQL = "SELECT * FROM DISTRIBUTOR where distributor_number = ".$_REQUEST['dist_id']; echo " ssql " .$sSQL; echo " Link id " .$Link_ID; $rc = sybase_query($sSQL , $Link_ID); echo " rc ".$rc; Expected result: ssql SELECT * FROM DISTRIBUTOR where distributor_number = 1 Link id Resource id #6 rc Resource id #10 Actual result: -- ssql SELECT * FROM DISTRIBUTOR where distributor_number = 1 Link id Resource id #6 rc -- Edit this bug report at http://bugs.php.net/?id=37680&edit=1
#37224 [Opn->Bgs]: ErrorException::getTrace() includes the function name of the error_handler
ID: 37224
Updated by: [EMAIL PROTECTED]
Reported By: Jared dot Williams1 at ntlworld dot com
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Win2000
PHP Version: 5.1.3
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 trace only "skips" the error handler function, nothing
else is "skipped".
Previous Comments:
[2006-05-04 17:31:05] Jared dot Williams1 at ntlworld dot com
This definately seems to be a bug...
0 && $a < 10');
}
try
{
test(11);
}
catch (Exception $e)
{
echo '';
var_dump($e->getTrace());
echo '';
}
?>
Outputs
array(3) {
[0]=>
array(2) {
["function"]=>
string(24) "assertToExceptionHandler"
["args"]=>
array(1) {
[0]=>
string(17) "$a > 0 && $a < 10"
}
}
[1]=>
array(4) {
["file"]=>
string(30) "C:\Inetpub\Framework\www\s.php"
["line"]=>
int(24)
["function"]=>
string(6) "assert"
["args"]=>
array(1) {
[0]=>
int(11)
}
}
[2]=>
array(3) {
["file"]=>
string(30) "C:\Inetpub\Framework\www\s.php"
["line"]=>
int(29)
["function"]=>
string(4) "test"
}
}
Which seems off by one each line of the trace has the previous stack
calls arguments.
[2006-05-01 15:31:20] Jared dot Williams1 at ntlworld dot com
How can the trace containing the function name of one function, and the
arguments to another be expected?
[2006-05-01 15:04:30] [EMAIL PROTECTED]
Expected behaviour.
No bug here.
[2006-04-27 18:24:03] Jared dot Williams1 at ntlworld dot com
But more investigation, and it appears that something alters the trace.
As args for the [0] element of the trace a what would be expected. Eg:
= 1)
return divr($a, $b >> 1);
return $a / $b;
}
try
{
divr(1024, 2);
}
catch (ErrorException $e)
{
var_dump($e->getTrace());
}
Generates..
array
0 =>
array
'file' => 'C:\Inetpub\Framework\www\bug.php' (length=32)
'line' => 17
'function' => 'errorToExceptionHandler' (length=23)
'args' =>
array
0 => 1024
1 => 0
1 =>
[2006-04-27 15:18:17] Jared dot Williams1 at ntlworld dot com
Description:
The call stack trace includes the name of the function used to map PHP
errors to exceptions. And as getTrace() is marked as final, cannot
override to exclude this.
Reproduce code:
---
getTrace());
}
catch (ErrorException $e)
{
var_dump($e->getTrace());
}
Expected result:
array
0 =>
array
'file' => 'C:\Inetpub\Framework\www\bug.php' (length=32)
'line' => 14
Actual result:
--
array
0 =>
array
'file' => 'C:\Inetpub\Framework\www\bug.php' (length=32)
'line' => 14
'function' => 'errorToExceptionHandler' (length=23)
--
Edit this bug report at http://bugs.php.net/?id=37224&edit=1
#37488 [Opn->Bgs]: import_request_variables doesnt work with pre-changed _REQUEST vars.
ID: 37488
Updated by: [EMAIL PROTECTED]
Reported By: serkan at kibritoglu dot net
-Status: Open
+Status: Bogus
Bug Type: Variables related
Operating System: winXP
PHP Version: 5.1.4
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
Only the actual values supplied via GPC can be imported.
Previous Comments:
[2006-05-18 07:01:11] serkan at kibritoglu dot net
Description:
Very simple logic. Here you go;
Reproduce code:
---
if($_GET['param']=='') $_GET['param'] = "I am changed forever.";
echo "Should print: " . $_GET['param'] . "\n";
import_request_variables("g", "g_");
echo "And... !: " . $g_param . "\n";
Expected result:
Should print: I am changed forever.
And... !: I am changed forever.
Actual result:
--
Should print: I am changed forever.
And... !:
--
Edit this bug report at http://bugs.php.net/?id=37488&edit=1
#37703 [NEW]: RFC822 date not fixed in 6.0
From: spam01 at pornel dot net Operating system: win32 PHP version: 6CVS-2006-06-05 (snap) PHP Bug Type: Date/time related Bug description: RFC822 date not fixed in 6.0 Description: bug #37616 (closed) hasn't been fixed in 6.0. Reproduce code: --- see bug #37616 -- Edit bug report at http://bugs.php.net/?id=37703&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37703&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=37703&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37703&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37703&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37703&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37703&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37703&r=needscript Try newer version:http://bugs.php.net/fix.php?id=37703&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37703&r=support Expected behavior:http://bugs.php.net/fix.php?id=37703&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37703&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37703&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37703&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37703&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37703&r=dst IIS Stability:http://bugs.php.net/fix.php?id=37703&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37703&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37703&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37703&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37703&r=mysqlcfg
#37703 [Opn->Bgs]: RFC822 date not fixed in 6.0
ID: 37703 Updated by: [EMAIL PROTECTED] Reported By: spam01 at pornel dot net -Status: Open +Status: Bogus Bug Type: Date/time related Operating System: win32 PHP Version: 6CVS-2006-06-05 (snap) New Comment: sure it has. [EMAIL PROTECTED] php6$ sapi/cli/php -r 'var_dump(DATE_RFC822);' string(16) "D, d M y H:i:s O" Previous Comments: [2006-06-05 16:51:07] spam01 at pornel dot net Description: bug #37616 (closed) hasn't been fixed in 6.0. Reproduce code: --- see bug #37616 -- Edit this bug report at http://bugs.php.net/?id=37703&edit=1
#37704 [NEW]: carriage return suppression after closing tag
From: php at bouchery dot com Operating system: Windows XP PHP version: 5.1.4 PHP Bug Type: Output Control Bug description: carriage return suppression after closing tag Description: After php closing tag, carriage returns are deleted. If I add some text after the closing tag, it's OK. It happen only if the carriage return is place just after the closing tag. Reproduce code: --- Expected result: Line 1 Line 2 Actual result: -- Line 1Line 2 -- Edit bug report at http://bugs.php.net/?id=37704&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37704&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=37704&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37704&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37704&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37704&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37704&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37704&r=needscript Try newer version:http://bugs.php.net/fix.php?id=37704&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37704&r=support Expected behavior:http://bugs.php.net/fix.php?id=37704&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37704&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37704&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37704&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37704&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37704&r=dst IIS Stability:http://bugs.php.net/fix.php?id=37704&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37704&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37704&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37704&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37704&r=mysqlcfg
#37702 [Csd]: Make toString working with strval
ID: 37702 User updated by: php at bouchery dot com Reported By: php at bouchery dot com Status: Closed Bug Type: Feature/Change Request Operating System: * PHP Version: 5.1.* Assigned To: helly New Comment: It's a bug ? Seen in the documentation : "It is worth noting that the __toString method will only be called when it is directly combined with echo() or print()." And Example 19-28 confirm this "feature". here : http://www.php.net/manual/en/language.oop5.magic.php Previous Comments: [2006-06-05 15:34:28] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Cannot be fixed in 5.1 and is already fixed in HEAD and 5.2 [2006-06-05 15:29:08] php at bouchery dot com Description: Currently, __toString work ONLY with echo/print, and it's very restrictive. It could be very interresting to allow toString working with strval() to avoid this : __toString(); else $text = 'var = ' . $var; ?> Expected result: Or better : -- Edit this bug report at http://bugs.php.net/?id=37702&edit=1
#37704 [Opn->WFx]: carriage return suppression after closing tag
ID: 37704 Updated by: [EMAIL PROTECTED] Reported By: php at bouchery dot com -Status: Open +Status: Wont fix Bug Type: Output Control Operating System: Windows XP PHP Version: 5.1.4 New Comment: This is a feature and changing this would break tons of existing applications. Previous Comments: [2006-06-05 18:40:12] php at bouchery dot com Description: After php closing tag, carriage returns are deleted. If I add some text after the closing tag, it's OK. It happen only if the carriage return is place just after the closing tag. Reproduce code: --- Expected result: Line 1 Line 2 Actual result: -- Line 1Line 2 -- Edit this bug report at http://bugs.php.net/?id=37704&edit=1
#37704 [WFx]: carriage return suppression after closing tag
ID: 37704 User updated by: php at bouchery dot com Reported By: php at bouchery dot com Status: Wont fix Bug Type: Output Control Operating System: Windows XP PHP Version: 5.1.4 New Comment: Ok. Is it writen in the documentation ? Previous Comments: [2006-06-05 19:09:27] [EMAIL PROTECTED] This is a feature and changing this would break tons of existing applications. [2006-06-05 18:40:12] php at bouchery dot com Description: After php closing tag, carriage returns are deleted. If I add some text after the closing tag, it's OK. It happen only if the carriage return is place just after the closing tag. Reproduce code: --- Expected result: Line 1 Line 2 Actual result: -- Line 1Line 2 -- Edit this bug report at http://bugs.php.net/?id=37704&edit=1
#37697 [Fbk->Csd]: get_queue() always fails
ID: 37697 User updated by: aeolianmeson at blitzeclipse dot com Reported By: aeolianmeson at blitzeclipse dot com -Status: Feedback +Status: Closed Bug Type: Semaphore related Operating System: Fed4 PHP Version: 5.1.4 New Comment: Okay. Thanks. Dustin Previous Comments: [2006-06-05 11:50:57] [EMAIL PROTECTED] Works perfectly fine here: # php -r 'var_dump(msg_get_queue(1360265987));' resource(4) of type (sysvmsg queue) [2006-06-05 04:17:39] aeolianmeson at blitzeclipse dot com Description: get_queue will always say that it is out of space, but space is abundant. Full SysV library is built. No idea even on how to debug this. Reproduce code: --- Expected result: No error. Actual result: -- PHP Warning: msg_get_queue(): failed for key 0x51140303: No space left on device in /clustershare/cluster/simplemsg.php on line 3 -- Edit this bug report at http://bugs.php.net/?id=37697&edit=1
#37611 [Fbk->Opn]: WDDX serializer encodes all non-ascii characters with
ID: 37611
User updated by: jdolecek at NetBSD dot org
Reported By: jdolecek at NetBSD dot org
-Status: Feedback
+Status: Open
Bug Type: WDDX related
Operating System: Any
PHP Version: 5.1.5CVS
New Comment:
127 serializes/deserialized just fine on my system even without your
change, test script:
$str = wddx_deserialize(wddx_serialize_value(chr(127)));
echo ord($str[0])."\n";
wddx_deserialize() expects UTF-8 input and gives iso-8859-1 output.
There are ways around this, but this is the default way.
wddx_serialize_value() doesn't particularily care, it takes both UTF-8
and iso-8869-1.
So the right way to use the API is to UTF-8-encode text before
serializing, so that we'd get proper output after deserializing.
I'd also point out that both 1) and 2) points still hold, and both are
very painfull for non-english speakers. _Please_ back the change off.
Previous Comments:
[2006-05-31 22:22:04] [EMAIL PROTECTED]
Without the 127 bit on chr(128) for example becomes translated
to 0 causing irreversible data loss.
As far as chr(200) you don't need to utf8 encode it.
[2006-05-30 15:59:24] jdolecek at NetBSD dot org
Yes it is a bug.
1) it breaks current code using UTF-8 and expecting to get iso-8859-1
result from wddx_deserialize(), i.e.
$str = chr(200);
$str_u8 = utf8_encode($str);
$result = wddx_deserialize(wddx_Serialize_value($str_u8));
When run with PHP 5.1.4 or when the data has been serialized with
the older version, $result == $str.
New version has $result == $str_u8.
So, _all_ old serialized UTF-8 data (i.e. stored
in database) serializes to different encoding
then newly serialized data. This is major
backward incompatibility, and is problem for any
current applications using serializing of
UTF-8 input.
(Arguably serializing UTF-8 strings wasn't really
very usable before due to Bug #37571, but you get
the idea)
2) it explodes the size of packet, and it's not clear
what was the reason for the change. This is serious
problem when storing the result serialized data,
and totally unnecessary. XML is designed 8-bit
clean, so encoding high-bit characters this
way doesn't make sense.
Please explain why encoding characters >= 127 is right. Please revert
this part of the patch.
If you want to fix wddx so that the encoding on input is same as
encoding on output it's fine, but it must be done in
backward-compatible way, such as adding some extra parameters to either
wddx_serialize_value() or wddx_deserialize().
[2006-05-28 15:13:29] [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
This is definitely not left over debug code, it is needed on
some system to ensure proper encoding of non-ascii characters.
[2006-05-27 09:58:51] jdolecek at NetBSD dot org
Seems the bug submit system turns non-ascii character to some entities,
the Č should be character with ordinal value 200 (i.e. result of
chr(200)).
[2006-05-27 09:57:18] jdolecek at NetBSD dot org
Description:
The condition which determines if a character in string should be
encoded using the construct was changed in
php-src/ext/wddx/wddx.c was changed in rev. 1.135 to:
if (iscntrl((int)*(unsigned char *)p) || (int)*(unsigned char *)p >=
127) {
...encode using ...
}
This means that _all_ non-ascii characters are encoded with the
construct, which explodes the result packet size if non-ascii
characters are used.
The "|| (int)*(unsigned char *)p >= 127" parts seems as left-over debug
code and should be removed.
Reproduce code:
---
// this was not actually tried, this is just code review
wddx_serialize_value(char(200));
Expected result:
Č
Actual result:
--
--
Edit this bug report at http://bugs.php.net/?id=37611&edit=1
#37705 [NEW]: Semaphore constants not available.
From: aeolianmeson at blitzeclipse dot com Operating system: Fed4 PHP version: 5.1.4 PHP Bug Type: Semaphore related Bug description: Semaphore constants not available. Description: The constants, as mentioned in the documentation (for msg_send() and msg_receive()), are not available. Specifically, the EAGAIN constant (which tells you to try resending a message because there was no space left), and the ENOMSG constant (which tells you that there was no message available and blocking was turned off). The IPC_CREAT constant should be there as well. This isn't mentioned officially in the documentation, but in one of the comments, as well as in bug #25961. Reproduce code: --- php -r 'print(EAGAIN);' Expected result: An integer. Actual result: -- PHP Notice: Use of undefined constant EAGAIN - assumed 'EAGAIN' in Command line code on line 1 -- Edit bug report at http://bugs.php.net/?id=37705&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37705&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=37705&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37705&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37705&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37705&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37705&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37705&r=needscript Try newer version:http://bugs.php.net/fix.php?id=37705&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37705&r=support Expected behavior:http://bugs.php.net/fix.php?id=37705&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37705&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37705&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37705&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37705&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37705&r=dst IIS Stability:http://bugs.php.net/fix.php?id=37705&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37705&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37705&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37705&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37705&r=mysqlcfg
#37697 [Csd->Bgs]: get_queue() always fails
ID: 37697 Updated by: [EMAIL PROTECTED] Reported By: aeolianmeson at blitzeclipse dot com -Status: Closed +Status: Bogus Bug Type: Semaphore related Operating System: Fed4 PHP Version: 5.1.4 Previous Comments: [2006-06-05 19:39:36] aeolianmeson at blitzeclipse dot com Okay. Thanks. Dustin [2006-06-05 11:50:57] [EMAIL PROTECTED] Works perfectly fine here: # php -r 'var_dump(msg_get_queue(1360265987));' resource(4) of type (sysvmsg queue) [2006-06-05 04:17:39] aeolianmeson at blitzeclipse dot com Description: get_queue will always say that it is out of space, but space is abundant. Full SysV library is built. No idea even on how to debug this. Reproduce code: --- Expected result: No error. Actual result: -- PHP Warning: msg_get_queue(): failed for key 0x51140303: No space left on device in /clustershare/cluster/simplemsg.php on line 3 -- Edit this bug report at http://bugs.php.net/?id=37697&edit=1
#37605 [Fbk->Opn]: PDO stored procedure prepare call hangs
ID: 37605
User updated by: randall dot carlson at navy dot mil
Reported By: randall dot carlson at navy dot mil
-Status: Feedback
+Status: Open
Bug Type: PDO related
Operating System: REL 4
PHP Version: 5.1.4
New Comment:
Well, my problem involves database access with PDO, so I don't know how
to convey the problem without a database. As far as the script itself:
prepare("call pdo_test()"/*"select dummy from
dummy;"*/);
$stmt->execute();
echo "outputting...";
while ($rs = $stmt->fetch(PDO::FETCH_OBJ)) {
echo "output: ".$rs->dummy."";
}
echo "".date("r")."";
?>
That is all of it, except for the MySQL stored procedure script:
create procedure pdo_test() begin select dummy from dummy; end;
Previous Comments:
[2006-05-30 11:42:18] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
[2006-05-30 11:36:42] randall dot carlson at navy dot mil
My code is within a portal application so, your test is slightly
different than mine. Again, as of PHP 5.1.2, the portal application
and my code works just fine. It was only when PHP 5.1.4 was built that
this issue appeared. Now as I monitor the mysql logs, I have discovered
that when it hangs, the stored procedure calls appear to be executing
twice (while one call was issued).
[2006-05-29 11:10:03] [EMAIL PROTECTED]
Works perfectly fine here.
But doesn't output any results, of course, since there is no "dummy"
table with "dummy" field.
[2006-05-26 17:09:43] randall dot carlson at navy dot mil
Description:
It appears the PDO execute is hanging when a MySQL stored procedure is
called. The same code works fine on PHP 5.1.2 & MySQL 4.0.21. Once we
upgraded to 5.1.4, the problem began. It looks as if the call is being
executed a couple of times in the MySQL queries.log. Our application
code has many such calls and after attempting to execute each one the
browser eventually timesout.
When I subtitute the SQL statment in the prepare, it comes back fine.
Reproduce code:
---
create procedure pdo_test() begin select dummy from dummy; end;
$pdo = new PDO("mysql:host=localhost;dbname=x","x","x");
$stmt = $pdo->prepare("call pdo_test()"/*"select dummy from
dummy;"*/);
$stmt->execute();
echo "outputting...";
while ($rs = $stmt->fetch(PDO::FETCH_OBJ)) {
echo "output: ".$rs->dummy."";
}
echo "".date("r")."";
Expected result:
should get
outputting...
output: 1
Fri, 26 May 2006 13:02:17 -0400
Actual result:
--
timeout
--
Edit this bug report at http://bugs.php.net/?id=37605&edit=1
#37706 [NEW]: OCI-Lob read advances wrong internal pointer
From: crescentfreshpot at yahoo dot com
Operating system: Win XP
PHP version: 5CVS-2006-06-05 (snap)
PHP Bug Type: OCI8 related
Bug description: OCI-Lob read advances wrong internal pointer
Description:
I think OCI-Lob::read() is reading from the wrong handle when called
multiple times on different lob descriptors.
Reproduce code:
---
sql:
create table lobtest (lobdata clob);
insert into lobtest (lobdata) values('data data data data data data data
data');
insert into lobtest (lobdata) values('data2 data2 data2 data2 data2 data2
data2 data2');
commit;
php:
$conn = oci_connect('xxx','yyy','zzz');
$stmt = oci_parse($conn, "select lobdata from lobtest");
oci_execute($stmt);
$row1 = oci_fetch_array($stmt, OCI_NUM);
$row2 = oci_fetch_array($stmt, OCI_NUM);
var_dump($row1[0]->tell());
var_dump($row1[0]->read(8192));
var_dump($row2[0]->tell());
var_dump($row2[0]->read(8192));
Expected result:
int(0)
string(39) "data data data data data data data data"
int(0)
string(0) "data2 data2 data2 data2 data2 data2 data2 data2"
Actual result:
--
int(0)
string(39) "data data data data data data data data"
int(39)
string(0) ""
--
Edit bug report at http://bugs.php.net/?id=37706&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=37706&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=37706&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=37706&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=37706&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=37706&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=37706&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=37706&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=37706&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=37706&r=support
Expected behavior:http://bugs.php.net/fix.php?id=37706&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=37706&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=37706&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=37706&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37706&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=37706&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=37706&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=37706&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=37706&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=37706&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=37706&r=mysqlcfg
#37706 [Opn->Bgs]: OCI-Lob read advances wrong internal pointer
ID: 37706
Updated by: [EMAIL PROTECTED]
Reported By: crescentfreshpot at yahoo dot com
-Status: Open
+Status: Bogus
Bug Type: OCI8 related
Operating System: Win XP
PHP Version: 5CVS-2006-06-05 (snap)
New Comment:
$row1[0] and $row2[0] are different variables pointing to the same LOB
descriptor.
This is how it works and it's expected.
Previous Comments:
[2006-06-05 22:18:18] crescentfreshpot at yahoo dot com
Description:
I think OCI-Lob::read() is reading from the wrong handle when called
multiple times on different lob descriptors.
Reproduce code:
---
sql:
create table lobtest (lobdata clob);
insert into lobtest (lobdata) values('data data data data data data
data data');
insert into lobtest (lobdata) values('data2 data2 data2 data2 data2
data2 data2 data2');
commit;
php:
$conn = oci_connect('xxx','yyy','zzz');
$stmt = oci_parse($conn, "select lobdata from lobtest");
oci_execute($stmt);
$row1 = oci_fetch_array($stmt, OCI_NUM);
$row2 = oci_fetch_array($stmt, OCI_NUM);
var_dump($row1[0]->tell());
var_dump($row1[0]->read(8192));
var_dump($row2[0]->tell());
var_dump($row2[0]->read(8192));
Expected result:
int(0)
string(39) "data data data data data data data data"
int(0)
string(0) "data2 data2 data2 data2 data2 data2 data2 data2"
Actual result:
--
int(0)
string(39) "data data data data data data data data"
int(39)
string(0) ""
--
Edit this bug report at http://bugs.php.net/?id=37706&edit=1
#37594 [Fbk->Opn]: mssql fails under load
ID: 37594 User updated by: mzamora at meritlending dot com Reported By: mzamora at meritlending dot com -Status: Feedback +Status: Open Bug Type: MSSQL related Operating System: windows 2000 sp4 PHP Version: 5.1.4 Assigned To: fmk New Comment: We have been running with php_dblib.dll for a little over a week now and have not noticed any instability issues. Is there any additional information that we can provide to assist in isolating the issue within mssql.dll? We are very interested in getting a stable version of mssql.dll as running with php_dblib.dll has caused a sizable increase in our query times. Previous Comments: [2006-05-30 15:44:19] mzamora at meritlending dot com We have the server running with the php_dblib.dll, but because of the long holiday weekend the server has not been under the load level that causes the failure. [2006-05-26 06:24:02] [EMAIL PROTECTED] Let's leave at feedback until then then. [2006-05-26 00:13:40] mzamora at meritlending dot com we are using php5apache2.dll. It will be some time tomorrow before I get a chance to do any testing with php_dblib.dll. [2006-05-25 23:54:13] [EMAIL PROTECTED] Are you using CGI or php5apache2.dll? The library used by the mssql extension is not thread safe. You might want to try php_dblib.dll. It's the same mssql_*() functions but it's compiled against FreeTDS. [2006-05-25 23:42:43] mzamora at meritlending dot com Description: Under heavy load the server responds with the following: "Warning: mssql_pconnect() [function.mssql-pconnect]: Unable to connect to server: servername" We see the same type issue with the connect function. Our configuration is as follows: OS - Windows 2000 SP4 Apache - 2.0.0.58 PHP - 5.1.4 Changes to the PHP.ini include Enabling the following extensions extension=php_curl.dll extension=php_mime_magic.dll extension=php_mssql.dll extension=php_openssl.dll extension=php_printer.dll All mssql relevant settings have been not been changed from php.ini-dist Please let me know what we can do to help find a resolution to this issue. As a note the issue we are encountering is exactly like the one reported in bug #32854 -- Edit this bug report at http://bugs.php.net/?id=37594&edit=1
#37705 [Opn->Csd]: Semaphore constants not available.
ID: 37705 Updated by: [EMAIL PROTECTED] Reported By: aeolianmeson at blitzeclipse dot com -Status: Open +Status: Closed Bug Type: Semaphore related Operating System: Fed4 PHP Version: 5.1.4 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: [2006-06-05 20:08:16] aeolianmeson at blitzeclipse dot com Description: The constants, as mentioned in the documentation (for msg_send() and msg_receive()), are not available. Specifically, the EAGAIN constant (which tells you to try resending a message because there was no space left), and the ENOMSG constant (which tells you that there was no message available and blocking was turned off). The IPC_CREAT constant should be there as well. This isn't mentioned officially in the documentation, but in one of the comments, as well as in bug #25961. Reproduce code: --- php -r 'print(EAGAIN);' Expected result: An integer. Actual result: -- PHP Notice: Use of undefined constant EAGAIN - assumed 'EAGAIN' in Command line code on line 1 -- Edit this bug report at http://bugs.php.net/?id=37705&edit=1
#37594 [Opn->Fbk]: mssql fails under load
ID: 37594 Updated by: [EMAIL PROTECTED] Reported By: mzamora at meritlending dot com -Status: Open +Status: Feedback Bug Type: MSSQL related Operating System: windows 2000 sp4 PHP Version: 5.1.4 Assigned To: fmk New Comment: Both the DBLIB and MSSQL versions of this extension uses the exact same C code. The difference between the two versions is the library used. The Library supplied by Microsoft and used in php_mssql.dll is not thread safe. Microsoft has not updated this library since SQL Server 6.5. The extension named php_dblib.dll uses FreeTDS and there are ways to improve performance as this is an open source project. In both cases it's the same server the performs the queries and it's the same C code that handles the output from the library, so the only differences I see is the transport protocols. If you have some examples of quieries that acts slower I'll take a look at those and see if tehre is anything that can be done. Previous Comments: [2006-06-05 22:34:40] mzamora at meritlending dot com We have been running with php_dblib.dll for a little over a week now and have not noticed any instability issues. Is there any additional information that we can provide to assist in isolating the issue within mssql.dll? We are very interested in getting a stable version of mssql.dll as running with php_dblib.dll has caused a sizable increase in our query times. [2006-05-30 15:44:19] mzamora at meritlending dot com We have the server running with the php_dblib.dll, but because of the long holiday weekend the server has not been under the load level that causes the failure. [2006-05-26 06:24:02] [EMAIL PROTECTED] Let's leave at feedback until then then. [2006-05-26 00:13:40] mzamora at meritlending dot com we are using php5apache2.dll. It will be some time tomorrow before I get a chance to do any testing with php_dblib.dll. [2006-05-25 23:54:13] [EMAIL PROTECTED] Are you using CGI or php5apache2.dll? The library used by the mssql extension is not thread safe. You might want to try php_dblib.dll. It's the same mssql_*() functions but it's compiled against FreeTDS. 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/37594 -- Edit this bug report at http://bugs.php.net/?id=37594&edit=1
#35886 [Asn->Csd]: file_get_contents() fails with some combinations of offset & maxlen
ID: 35886 Updated by: [EMAIL PROTECTED] Reported By: chris at lodesys dot com -Status: Assigned +Status: Closed Bug Type: Streams related Operating System: win32 only PHP Version: 5CVS-2006-01-03 (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. Edink applied the patch to PHP 5.2 and 6. Thanks! Previous Comments: [2006-06-05 12:00:26] [EMAIL PROTECTED] here is the patch: http://mega.ist.utl.pt/~ncpl/php_win_mmap_segfault.txt [2006-03-02 22:50:13] piecia2000 at tlen dot pl Temporary solution (slighty slower): $fd = fopen($filename, "rb"); fseek($fd, $offset); $file = fread($fd, $size); fclose($fd); please fix file_get_contents(), [2006-02-23 07:21:30] ninive at gmx dot at Please fix this critical bug. [2006-02-08 02:23:46] chris at lodesys dot com The example test file is C:/php/news.txt (part of the PHP Windows distribution). It is 74 KB (75,800 bytes). Was having problems with files larger than that (say up to 170 KB). Didn't test with extra large files. [2006-02-08 00:50:26] [EMAIL PROTECTED] How big is the 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/35886 -- Edit this bug report at http://bugs.php.net/?id=35886&edit=1
#37707 [NEW]: clone without assigning leaks memory
From: [EMAIL PROTECTED] Operating system: n/a PHP version: 5CVS-2006-06-05 (CVS) PHP Bug Type: Scripting Engine problem Bug description: clone without assigning leaks memory Description: cloning an object without assigning the return value to a variable leaks memory. Reproduce code: --- http://bugs.php.net/?id=37707&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37707&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=37707&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37707&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37707&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37707&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37707&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37707&r=needscript Try newer version:http://bugs.php.net/fix.php?id=37707&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37707&r=support Expected behavior:http://bugs.php.net/fix.php?id=37707&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37707&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37707&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37707&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37707&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37707&r=dst IIS Stability:http://bugs.php.net/fix.php?id=37707&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37707&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37707&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37707&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37707&r=mysqlcfg
#37707 [Opn->Asn]: clone without assigning leaks memory
ID: 37707 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Assigned Bug Type: Scripting Engine problem Operating System: n/a PHP Version: 5CVS-2006-06-05 (CVS) -Assigned To: +Assigned To: dmitry New Comment: so here it goes.. Previous Comments: [2006-06-05 23:16:45] [EMAIL PROTECTED] Description: cloning an object without assigning the return value to a variable leaks memory. Reproduce code: --- http://bugs.php.net/?id=37707&edit=1
#37707 [Asn]: clone without assigning leaks memory
ID: 37707 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: Scripting Engine problem Operating System: n/a PHP Version: 5CVS-2006-06-05 (CVS) Assigned To: dmitry New Comment: I even made a patch =) : http://mega.ist.utl.pt/~ncpl/zend_clone_memleak.txt Previous Comments: [2006-06-05 23:17:06] [EMAIL PROTECTED] so here it goes.. [2006-06-05 23:16:45] [EMAIL PROTECTED] Description: cloning an object without assigning the return value to a variable leaks memory. Reproduce code: --- http://bugs.php.net/?id=37707&edit=1
#37706 [Bgs]: OCI-Lob read advances wrong internal pointer
ID: 37706
User updated by: crescentfreshpot at yahoo dot com
Reported By: crescentfreshpot at yahoo dot com
Status: Bogus
Bug Type: OCI8 related
Operating System: Win XP
PHP Version: 5CVS-2006-06-05 (snap)
New Comment:
Three things:
a) AFAIK php has no problems with having multiple stream handles open,
so does your "it's expected" comment refer to limitations in the oci
library itself?
b) is this why there is no way to stop oci_fetch_all from automatically
fetching my lob data and instead return them to me as separate,
*individual* streams?
b) Is there no workaround for this? Something along the lines of
php_stream_copy_to_stream to save a reference to an oci stream as it's
fetched say in a fetchAll scenario?
Previous Comments:
[2006-06-05 22:21:38] [EMAIL PROTECTED]
$row1[0] and $row2[0] are different variables pointing to the same LOB
descriptor.
This is how it works and it's expected.
[2006-06-05 22:18:18] crescentfreshpot at yahoo dot com
Description:
I think OCI-Lob::read() is reading from the wrong handle when called
multiple times on different lob descriptors.
Reproduce code:
---
sql:
create table lobtest (lobdata clob);
insert into lobtest (lobdata) values('data data data data data data
data data');
insert into lobtest (lobdata) values('data2 data2 data2 data2 data2
data2 data2 data2');
commit;
php:
$conn = oci_connect('xxx','yyy','zzz');
$stmt = oci_parse($conn, "select lobdata from lobtest");
oci_execute($stmt);
$row1 = oci_fetch_array($stmt, OCI_NUM);
$row2 = oci_fetch_array($stmt, OCI_NUM);
var_dump($row1[0]->tell());
var_dump($row1[0]->read(8192));
var_dump($row2[0]->tell());
var_dump($row2[0]->read(8192));
Expected result:
int(0)
string(39) "data data data data data data data data"
int(0)
string(0) "data2 data2 data2 data2 data2 data2 data2 data2"
Actual result:
--
int(0)
string(39) "data data data data data data data data"
int(39)
string(0) ""
--
Edit this bug report at http://bugs.php.net/?id=37706&edit=1
#37706 [Bgs]: OCI-Lob read advances wrong internal pointer
ID: 37706
Updated by: [EMAIL PROTECTED]
Reported By: crescentfreshpot at yahoo dot com
Status: Bogus
Bug Type: OCI8 related
Operating System: Win XP
PHP Version: 5CVS-2006-06-05 (snap)
New Comment:
I don't see any way to bind several variables to one placeholder/column
in OCI API, so we reuse the same descriptor on each iteration.
Previous Comments:
[2006-06-06 00:29:57] crescentfreshpot at yahoo dot com
Three things:
a) AFAIK php has no problems with having multiple stream handles open,
so does your "it's expected" comment refer to limitations in the oci
library itself?
b) is this why there is no way to stop oci_fetch_all from automatically
fetching my lob data and instead return them to me as separate,
*individual* streams?
b) Is there no workaround for this? Something along the lines of
php_stream_copy_to_stream to save a reference to an oci stream as it's
fetched say in a fetchAll scenario?
[2006-06-05 22:21:38] [EMAIL PROTECTED]
$row1[0] and $row2[0] are different variables pointing to the same LOB
descriptor.
This is how it works and it's expected.
[2006-06-05 22:18:18] crescentfreshpot at yahoo dot com
Description:
I think OCI-Lob::read() is reading from the wrong handle when called
multiple times on different lob descriptors.
Reproduce code:
---
sql:
create table lobtest (lobdata clob);
insert into lobtest (lobdata) values('data data data data data data
data data');
insert into lobtest (lobdata) values('data2 data2 data2 data2 data2
data2 data2 data2');
commit;
php:
$conn = oci_connect('xxx','yyy','zzz');
$stmt = oci_parse($conn, "select lobdata from lobtest");
oci_execute($stmt);
$row1 = oci_fetch_array($stmt, OCI_NUM);
$row2 = oci_fetch_array($stmt, OCI_NUM);
var_dump($row1[0]->tell());
var_dump($row1[0]->read(8192));
var_dump($row2[0]->tell());
var_dump($row2[0]->read(8192));
Expected result:
int(0)
string(39) "data data data data data data data data"
int(0)
string(0) "data2 data2 data2 data2 data2 data2 data2 data2"
Actual result:
--
int(0)
string(39) "data data data data data data data data"
int(39)
string(0) ""
--
Edit this bug report at http://bugs.php.net/?id=37706&edit=1
