#32859 [Asn->Fbk]: Error when attempting to write Clob to oracle
ID: 32859
Updated by: [EMAIL PROTECTED]
Reported By: Diomedes_01 at yahoo dot com
-Status: Assigned
+Status: Feedback
Bug Type: OCI8 related
Operating System: Solaris 9 (Server)
PHP Version: 5.0.4
Assigned To: tony2001
New Comment:
So you tried to write CLOB without setting it empty with EMPTY_CLOB() ?
Am I right?
Previous Comments:
[2005-06-13 02:03:35] ab5602 at wayne dot edu
This appears to possibly be parsing problem with the oci_parse function
not returning a real placeholder location. The placeholder :fieldname
does not work if used in this fashion during an sql statement in
v5.0.4, I've found this to work in previous versions:
update table mytable set clob1=:clob;
However, I've found it to work in v5.0.4 if the sql is rewritten such
as:
update table mytable set clob1=empty_clob() returning clob1 as :clob;
[2005-04-28 19:48:32] Diomedes_01 at yahoo dot com
Unfortunately, my website is behind a firewall and contains company
sensitive information; so I cannot grant access.
The reproducible code is already included; please note that I attempted
to continue using my previous PHP4 code (that worked beforehand) and it
failed. That code was:
WriteTemporary($comments);
OCIExecute ($sth, OCI_DEFAULT) or display_main_error();
$clob->close();
$clob->free();
OCIFreeStatement($sth);
?>
When I attempted to execute the above code, I received a fatal error
from PHP indicating that the writeTemporary method was not found.
According to what I read in the documentation, it appears to not be
part of the new OCI class.
So when I followed the documentation and re-implemented the code
following the instructions provided; which by the way, look like so:
(straight from your online help)
= 4.0.6).
* Example PL/SQL stored procedure signature is:
*
* PROCEDURE save_data
* Argument Name TypeIn/Out
Default?
* -- --- --
* KEYNUMBER(38) IN
* DATA CLOBIN
*
*/
$conn = oci_connect($user, $password);
$stmt = oci_parse($conn, "begin save_data(:key, :data); end;");
$clob = oci_new_descriptor($conn, OCI_D_LOB);
oci_bind_by_name($stmt, ':key', $key);
oci_bind_by_name($stmt, ':data', $clob, -1, OCI_B_CLOB);
$clob->write($data);
oci_execute($stmt, OCI_DEFAULT);
oci_commit($conn);
$clob->free();
oci_free_statement($stmt);
?>
Here is the documentation URL:
http://us2.php.net/manual/en/function.oci-new-descriptor.php
That is when I receive a problem with regards to the 'write' method.
So either this is a bug or a documentation problem; I know the stored
procedure I am using works and that the variables being passed are
valid. It works in SQL*Plus and it works if I revert back to PHP4.
Please advise.
[2005-04-28 15:04:53] [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.
Also, you don't have to modify your script to make it run with PHP5.
Old-style named functions are working in the same way as in PHP4.
[2005-04-27 21:44:58] Diomedes_01 at yahoo dot com
Description:
I am receiving errors after upgrading from php 4.3.9 to php 5.0.4 when
attempting to upload a clob to my Oracle database. The code has already
been modified to follow the PHP 5 paradigm; but it is refusing to
function. Code is as follows:
Reproduce code:
---
$sql1 = ("begin append_comments(:incident_id,:comments_id);end;");
$sth = oci_parse ( $connection, $sql1 ) or display_main_error();
$clob = oci_new_descriptor ($connection, OCI_D_LOB);
oci_bind_by_name ( $sth, ":incident_id", $incident );
oci_bind_by_name ($sth, ":comments_id", &$clob, -1, OCI_B_CLOB );
$clob->write($comments);
oci_execute ($sth, OCI_DEFAULT) or display_main_error();
oci_commit($connection);
$clob->free();
oci_free_statement($sth);
Expected result:
The above code should properly insert the clob into the Oracle
database. The code executed correctly in php4.3.9 and the stored
procedure being used functions normally in SQL*Plus.
Actual result:
--
I receive the following warnings from PHP
#32859 [Com]: Error when attempting to write Clob to oracle
ID: 32859
Comment by: ab5602 at wayne dot edu
Reported By: Diomedes_01 at yahoo dot com
Status: Assigned
Bug Type: OCI8 related
Operating System: Solaris 9 (Server)
PHP Version: 5.0.4
Assigned To: tony2001
New Comment:
This appears to possibly be parsing problem with the oci_parse function
not returning a real placeholder location. The placeholder :fieldname
does not work if used in this fashion during an sql statement in
v5.0.4, I've found this to work in previous versions:
update table mytable set clob1=:clob;
However, I've found it to work in v5.0.4 if the sql is rewritten such
as:
update table mytable set clob1=empty_clob() returning clob1 as :clob;
Previous Comments:
[2005-04-28 19:48:32] Diomedes_01 at yahoo dot com
Unfortunately, my website is behind a firewall and contains company
sensitive information; so I cannot grant access.
The reproducible code is already included; please note that I attempted
to continue using my previous PHP4 code (that worked beforehand) and it
failed. That code was:
WriteTemporary($comments);
OCIExecute ($sth, OCI_DEFAULT) or display_main_error();
$clob->close();
$clob->free();
OCIFreeStatement($sth);
?>
When I attempted to execute the above code, I received a fatal error
from PHP indicating that the writeTemporary method was not found.
According to what I read in the documentation, it appears to not be
part of the new OCI class.
So when I followed the documentation and re-implemented the code
following the instructions provided; which by the way, look like so:
(straight from your online help)
= 4.0.6).
* Example PL/SQL stored procedure signature is:
*
* PROCEDURE save_data
* Argument Name TypeIn/Out
Default?
* -- --- --
* KEYNUMBER(38) IN
* DATA CLOBIN
*
*/
$conn = oci_connect($user, $password);
$stmt = oci_parse($conn, "begin save_data(:key, :data); end;");
$clob = oci_new_descriptor($conn, OCI_D_LOB);
oci_bind_by_name($stmt, ':key', $key);
oci_bind_by_name($stmt, ':data', $clob, -1, OCI_B_CLOB);
$clob->write($data);
oci_execute($stmt, OCI_DEFAULT);
oci_commit($conn);
$clob->free();
oci_free_statement($stmt);
?>
Here is the documentation URL:
http://us2.php.net/manual/en/function.oci-new-descriptor.php
That is when I receive a problem with regards to the 'write' method.
So either this is a bug or a documentation problem; I know the stored
procedure I am using works and that the variables being passed are
valid. It works in SQL*Plus and it works if I revert back to PHP4.
Please advise.
[2005-04-28 15:04:53] [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.
Also, you don't have to modify your script to make it run with PHP5.
Old-style named functions are working in the same way as in PHP4.
[2005-04-27 21:44:58] Diomedes_01 at yahoo dot com
Description:
I am receiving errors after upgrading from php 4.3.9 to php 5.0.4 when
attempting to upload a clob to my Oracle database. The code has already
been modified to follow the PHP 5 paradigm; but it is refusing to
function. Code is as follows:
Reproduce code:
---
$sql1 = ("begin append_comments(:incident_id,:comments_id);end;");
$sth = oci_parse ( $connection, $sql1 ) or display_main_error();
$clob = oci_new_descriptor ($connection, OCI_D_LOB);
oci_bind_by_name ( $sth, ":incident_id", $incident );
oci_bind_by_name ($sth, ":comments_id", &$clob, -1, OCI_B_CLOB );
$clob->write($comments);
oci_execute ($sth, OCI_DEFAULT) or display_main_error();
oci_commit($connection);
$clob->free();
oci_free_statement($sth);
Expected result:
The above code should properly insert the clob into the Oracle
database. The code executed correctly in php4.3.9 and the stored
procedure being used functions normally in SQL*Plus.
Actual result:
--
I receive the following warnings from PHP when attempting to execute
the code:
Warning: OCI-Lob::write() [function.write]: OCILobGetLength:
OCI_INVALID_HANDLE in /www/htdocs/EtrackTest/oracle_update.php on line
218
Warning: oci_execute() [function.oci-execute]: OCIStm
#33313 [Csd->Opn]: I found a flaw in the ISAPI module
ID: 33313 User updated by: trustpunk at hotmail dot com Reported By: trustpunk at hotmail dot com -Status: Closed +Status: Open Bug Type: IIS related Operating System: Windows PHP Version: 5.0.4, 4.3.11 New Comment: I use PHP v4 , I tried the latest snapshot of PHP4 and the bug still exists , it would bne nice if you could fix it. Snapshot: v4.4.x-dev [June 12, 2005] Previous Comments: [2005-06-12 01:35:24] trustpunk at hotmail dot com Im proud to say that the Bug is fixed in that release :-) Make sure you apply that to v4.3 also. LateR! [2005-06-12 01:08:49] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-06-11 22:32:03] trustpunk at hotmail dot com Description: When running PHP as an ISAPI module , you can remotely crash the web server by creating a specially crafted URL. This bug was discovered by accident and I actually refer it as a DDoS type of attack on the web server. Please fix this! PHP versions effected so far: v4.3.11 , v5.0.4 Reproduce code: --- Using a URL like this will crash the web server , only ISAPI is effected. http://www.your-site.com/script.php/num=10101 I discovered this when writing a Binary to Decimal converter. -- Edit this bug report at http://bugs.php.net/?id=33313&edit=1
#33319 [Opn->Bgs]: Cannot re-assign $this
ID: 33319 Updated by: [EMAIL PROTECTED] Reported By: sailormax at gmail dot com -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: WinXP PHP Version: 5.1.0b1 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 You change $this into a reference here. Thus you still try to change it. Previous Comments: [2005-06-13 00:36:05] sailormax at gmail dot com But I don't re-assign "$this"! I re-assign "$obj"! Why I can't do this? [2005-06-12 23:22:14] [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 so don\'t assign it by reference... [2005-06-12 23:12:58] sailormax at gmail dot com Description: class member function do not accept bind to any variable address of $this. I do not want edit "$this"! I want work with it by another variable! (zend.ze1_compatibility_mode = On) Reproduce code: --- Expected result: everything must be ok Actual result: -- Fatal error: Cannot re-assign $this in index.php on line 6 -- Edit this bug report at http://bugs.php.net/?id=33319&edit=1
#33319 [Bgs->Opn]: Cannot re-assign $this
ID: 33319 User updated by: sailormax at gmail dot com Reported By: sailormax at gmail dot com -Status: Bogus +Status: Open Bug Type: Scripting Engine problem Operating System: WinXP PHP Version: 5.1.0b1 New Comment: But I don't re-assign "$this"! I re-assign "$obj"! Why I can't do this? Previous Comments: [2005-06-12 23:22:14] [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 so don\'t assign it by reference... [2005-06-12 23:12:58] sailormax at gmail dot com Description: class member function do not accept bind to any variable address of $this. I do not want edit "$this"! I want work with it by another variable! (zend.ze1_compatibility_mode = On) Reproduce code: --- Expected result: everything must be ok Actual result: -- Fatal error: Cannot re-assign $this in index.php on line 6 -- Edit this bug report at http://bugs.php.net/?id=33319&edit=1
#33320 [NEW]: unresolved external symbol _compiler_globals_id
From: sailormax at gmail dot com Operating system: WinXP PHP version: 5.1.0b1 PHP Bug Type: Compile Failure Bug description: unresolved external symbol _compiler_globals_id Description: if try use function "call_user_function_ex" in own extension, linker out error. (use Visual C++ 2005 Express and default skeleton for extensions) may be I just missing something, but where I can found some materials about it? On some forums was people with same problem... They sad: under Linux all work fine! Reproduce code: --- zval function_name zval *retval; ZVAL_STRING(&function_name, "GetPageFromURL", 0); if( call_user_function_ex(CG(function_table), NULL, &function_name, &retval, 0, NULL, 0, NULL TSRMLS_CC) == SUCCESS ); Expected result: compiled source Actual result: -- error LNK2019: unresolved external symbol _compiler_globals_id referenced in function foo -- Edit bug report at http://bugs.php.net/?id=33320&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33320&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33320&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33320&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33320&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33320&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33320&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33320&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33320&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33320&r=support Expected behavior: http://bugs.php.net/fix.php?id=33320&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33320&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33320&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33320&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33320&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33320&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33320&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33320&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33320&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33320&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33320&r=mysqlcfg
#33319 [Opn->Bgs]: Cannot re-assign $this
ID: 33319 Updated by: [EMAIL PROTECTED] Reported By: sailormax at gmail dot com -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: WinXP PHP Version: 5.1.0b1 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 so don't assign it by reference... Previous Comments: [2005-06-12 23:12:58] sailormax at gmail dot com Description: class member function do not accept bind to any variable address of $this. I do not want edit "$this"! I want work with it by another variable! (zend.ze1_compatibility_mode = On) Reproduce code: --- Expected result: everything must be ok Actual result: -- Fatal error: Cannot re-assign $this in index.php on line 6 -- Edit this bug report at http://bugs.php.net/?id=33319&edit=1
#33319 [NEW]: Cannot re-assign $this
From: sailormax at gmail dot com Operating system: WinXP PHP version: 5.1.0b1 PHP Bug Type: Scripting Engine problem Bug description: Cannot re-assign $this Description: class member function do not accept bind to any variable address of $this. I do not want edit "$this"! I want work with it by another variable! (zend.ze1_compatibility_mode = On) Reproduce code: --- Expected result: everything must be ok Actual result: -- Fatal error: Cannot re-assign $this in index.php on line 6 -- Edit bug report at http://bugs.php.net/?id=33319&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33319&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33319&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33319&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33319&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33319&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33319&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33319&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33319&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33319&r=support Expected behavior: http://bugs.php.net/fix.php?id=33319&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33319&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33319&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33319&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33319&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33319&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33319&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33319&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33319&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33319&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33319&r=mysqlcfg
#33318 [NEW]: throw 1; results in Invalid opcode 108/1/8
From: pornel at despammed dot com
Operating system: win? any
PHP version: 5.1.0b1
PHP Bug Type: Zend Engine 2 problem
Bug description: throw 1; results in Invalid opcode 108/1/8
Description:
throw NULL; throw 1; and probably all non-object throws result in "Invalid
Opcode" errors.
if PHP isn't supposed to allow throwing of scalar values, error should be
more precise.
Reproduce code:
---
function ERR() {throw 'x';}
Expected result:
C++-like throwing of anything or parse error.
--
Edit bug report at http://bugs.php.net/?id=33318&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33318&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33318&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33318&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33318&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33318&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33318&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33318&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33318&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33318&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33318&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33318&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33318&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33318&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33318&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33318&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33318&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33318&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33318&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33318&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33318&r=mysqlcfg
#33311 [Fbk->Csd]: PDO/PgSQL-Driver crashes Apache
ID: 33311 User updated by: martin dot stricker at rz dot hu-berlin dot de Reported By: martin dot stricker at rz dot hu-berlin dot de -Status: Feedback +Status: Closed Bug Type: PDO related Operating System: OS X 10.4.1 PHP Version: 5.1 snapshot 050611-1230 New Comment: fix confirmed with snapshot 200506012-1830 Previous Comments: [2005-06-12 19:19:44] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-06-11 19:08:32] martin dot stricker at rz dot hu-berlin dot de And this is from gdb: #0 0x00124c68 in pdo_pgsql_transaction_cmd (cmd=0x471384 "ROLLBACK", dbh=0x1da6a88) at /xxx/5dev0506111230/ext/pdo_pgsql/pgsql_driver.c:314 #1 0x00124d88 in pgsql_handle_rollback (dbh=0x1da6a88) at /xxx/5dev0506111230/ext/pdo_pgsql/pgsql_driver.c:336 #2 0x00118978 in pdo_dbh_free_storage (dbh=0x1da6a88) at /xxx/5dev0506111230/ext/pdo/pdo_dbh.c:1122 #3 0x003a3d3c in zend_objects_store_free_object_storage (objects=0x68c3f0) at /xxx/5dev0506111230/Zend/zend_objects_API.c:82 #4 0x003662e0 in shutdown_executor () at /xxx/5dev0506111230/Zend/zend_execute_API.c:272 #5 0x0037b384 in zend_deactivate () at /xxx/5dev0506111230/Zend/zend.c:823 #6 0x0031053c in php_request_shutdown (dummy=0x0) at /xxx/5dev0506111230/main/main.c:1237 #7 0x00442678 in main (argc=2, argv=0xb794) at /xxx/5dev0506111230/sapi/cli/php_cli.c:1139 (gdb) [2005-06-11 18:38:43] martin dot stricker at rz dot hu-berlin dot de chrashdump above concerns snapshot from today (with solved PDO/MySQL problem, bug http://bugs.php.net/bug.php?id=33310";>#33310) [2005-06-11 18:23:45] martin dot stricker at rz dot hu-berlin dot de I couldn't get gdb to work properly, but I think this crashdump report could be helpful. When I tested the PDO/PgSQL on the command line, the script executed properly just until the end, when the BUS Error ocurred (crashdump pretty much the same, without httpd sections, naturally). == chrashdump report Host Name: pBook Date/Time: 2005-06-11 17:53:02.408 +0200 OS Version: 10.4.1 (Build 8B15) Report Version: 3 Command: httpd Path:/usr/sbin/httpd Parent: httpd [8775] Version: ??? (???) PID:8826 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x Thread 0 Crashed: 0 libphp5.so 0x0212aee4 pdo_pgsql_transaction_cmd + 52 (pgsql_driver.c:314) 1 libphp5.so 0x0212b004 pgsql_handle_rollback + 48 (pgsql_driver.c:336) 2 libphp5.so 0x0211ebf4 pdo_dbh_free_storage + 96 (pdo_dbh.c:1123) 3 libphp5.so 0x023a9fb8 zend_objects_store_free_object_storage + 208 (zend_objects_API.c:76) 4 libphp5.so 0x0236c55c shutdown_executor + 1152 (zend_execute_API.c:273) 5 libphp5.so 0x02381600 zend_deactivate + 220 (zend.c:825) 6 libphp5.so 0x023167b8 php_request_shutdown + 1052 (main.c:1240) 7 libphp5.so 0x024464e8 apache_php_module_main + 336 (sapi_apache.c:60) 8 libphp5.so 0x02447a0c send_php + 964 (mod_php5.c:644) 9 libphp5.so 0x02447a98 send_parsed_php + 40 (mod_php5.c:656) 10 httpd 0xdd18 ap_invoke_handler + 232 11 httpd 0x00017dd4 process_request_internal + 640 12 httpd 0x00017e54 ap_process_request + 72 13 httpd 0x6b60 child_main + 1832 14 httpd 0x6dc4 make_child + 312 15 httpd 0x70f4 perform_idle_server_maintenance + 572 16 httpd 0x76d0 standalone_main + 964 17 httpd 0x7d74 main + 1052 18 httpd 0x238c _start + 348 19 httpd 0x222c start + 60 Thread 0 crashed with PPC Thread State: srr0: 0x0212aee4 srr1: 0x0200f030vrsave: 0x cr: 0x24000444 xer: 0x0006 lr: 0x0212b004 ctr: 0x0212afd4 r0: 0x0001 r1: 0xbfffdac0 r2: 0x r3: 0x02478898 r4: 0x003a7448 r5: 0x02d5 r6: 0x003a8c5b r7: 0xa753 r8: 0x0001 r9: 0x0211eb94 r10: 0x0236bab8 r11: 0x00058194 r12: 0x0212afd4 r13: 0x r14: 0x r15: 0x r16: 0x r17: 0x r18: 0x r19: 0x r20: 0x r21: 0x r22: 0x r23: 0x00056ec0 r24: 0x0001 r25: 0x0002 r26: 0x0183c038 r27: 0x01f4 r28: 0x0017 r29: 0x0183ffc0 r30: 0xbfffdac0 r31: 0x0212afec Binary Images Description: ... very lengthy part, which you probably wouldn't need, if otherwise, please give notice [2005-06-11 14:48:46] martin dot stricker at rz dot hu-berlin dot de Bug concerns 5.1beta1
#33316 [NEW]: configure problems detecting --with-pdo-odbc=unixODBC
From: [EMAIL PROTECTED] Operating system: IRIX 6.5.27 PHP version: 5CVS-2005-06-12 (dev) PHP Bug Type: PDO related Bug description: configure problems detecting --with-pdo-odbc=unixODBC Description: PHP was unable to bypass the configure when using --with-pdo-odbc=unixODBC,/usr/nekoware and latest mips c99 compiler. Thats sounds weird because checking for ext/unixodbc works like a charm. checking for unixODBC support... yes ... checking for ODBC v3 support for PDO... yes checking for selected PDO ODBC flavour... unixODBC libs /usr/nekoware/lib, headers/usr/nekoware/include Your ODBC library does not exist ... Config.log shows whats going wrong: configure:73675: c99 -o conftest -O3 -mips4 -I/usr/nekoware/include -OPT:Olimit=0:roundoff=3 -TAR G:platform=IP27:proc=r1 -I/usr/nekoware/include -D_XPG_IV -L/usr/nekoware/lib -lodbc -lm -ldl conftest.c -lm -lz -lm -lxml2 -lz -liconv -lm -lxml2 -lz -liconv -lm 1>&5 ld32: WARNING 84 : /usr/nekoware/lib/libodbc.so is not used for resolving any symbol. ld32: WARNING 84 : /usr/lib32/mips4/libm.so is not used for resolving any symbol. ld32: WARNING 84 : /usr/lib32/libdl.so is not used for resolving any symbol. ld32: WARNING 84 : /usr/nekoware/lib/libz.so is not used for resolving any symbol. ld32: WARNING 84 : /usr/nekoware/lib/libxml2.so is not used for resolving any symbol. ld32: ERROR 33 : Unresolved text symbol "SQLBindCol" -- 1st referenced by conftest.o. After adding -lodbc to the END of the line instead somewhere in the middle the configtest compiles fine and configure passes the check. The same issue 20 lines later when it tries to detecting libodbc > 3.x After the changes PHP head compiles fine. regards Joerg Reproduce code: --- Compile with '--with-unixODBC=shared,/usr/nekoware' \ '--with-pdo-odbc=unixODBC,/usr/nekoware' \ -- Edit bug report at http://bugs.php.net/?id=33316&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33316&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33316&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33316&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33316&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33316&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33316&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33316&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33316&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33316&r=support Expected behavior: http://bugs.php.net/fix.php?id=33316&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33316&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33316&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33316&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33316&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33316&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33316&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33316&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33316&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33316&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33316&r=mysqlcfg
#33311 [Opn->Fbk]: PDO/PgSQL-Driver crashes Apache
ID: 33311 Updated by: [EMAIL PROTECTED] Reported By: martin dot stricker at rz dot hu-berlin dot de -Status: Open +Status: Feedback Bug Type: PDO related Operating System: OS X 10.4.1 PHP Version: 5.1 snapshot 050611-1230 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip Previous Comments: [2005-06-11 19:08:32] martin dot stricker at rz dot hu-berlin dot de And this is from gdb: #0 0x00124c68 in pdo_pgsql_transaction_cmd (cmd=0x471384 "ROLLBACK", dbh=0x1da6a88) at /xxx/5dev0506111230/ext/pdo_pgsql/pgsql_driver.c:314 #1 0x00124d88 in pgsql_handle_rollback (dbh=0x1da6a88) at /xxx/5dev0506111230/ext/pdo_pgsql/pgsql_driver.c:336 #2 0x00118978 in pdo_dbh_free_storage (dbh=0x1da6a88) at /xxx/5dev0506111230/ext/pdo/pdo_dbh.c:1122 #3 0x003a3d3c in zend_objects_store_free_object_storage (objects=0x68c3f0) at /xxx/5dev0506111230/Zend/zend_objects_API.c:82 #4 0x003662e0 in shutdown_executor () at /xxx/5dev0506111230/Zend/zend_execute_API.c:272 #5 0x0037b384 in zend_deactivate () at /xxx/5dev0506111230/Zend/zend.c:823 #6 0x0031053c in php_request_shutdown (dummy=0x0) at /xxx/5dev0506111230/main/main.c:1237 #7 0x00442678 in main (argc=2, argv=0xb794) at /xxx/5dev0506111230/sapi/cli/php_cli.c:1139 (gdb) [2005-06-11 18:38:43] martin dot stricker at rz dot hu-berlin dot de chrashdump above concerns snapshot from today (with solved PDO/MySQL problem, bug http://bugs.php.net/bug.php?id=33310";>#33310) [2005-06-11 18:23:45] martin dot stricker at rz dot hu-berlin dot de I couldn't get gdb to work properly, but I think this crashdump report could be helpful. When I tested the PDO/PgSQL on the command line, the script executed properly just until the end, when the BUS Error ocurred (crashdump pretty much the same, without httpd sections, naturally). == chrashdump report Host Name: pBook Date/Time: 2005-06-11 17:53:02.408 +0200 OS Version: 10.4.1 (Build 8B15) Report Version: 3 Command: httpd Path:/usr/sbin/httpd Parent: httpd [8775] Version: ??? (???) PID:8826 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x Thread 0 Crashed: 0 libphp5.so 0x0212aee4 pdo_pgsql_transaction_cmd + 52 (pgsql_driver.c:314) 1 libphp5.so 0x0212b004 pgsql_handle_rollback + 48 (pgsql_driver.c:336) 2 libphp5.so 0x0211ebf4 pdo_dbh_free_storage + 96 (pdo_dbh.c:1123) 3 libphp5.so 0x023a9fb8 zend_objects_store_free_object_storage + 208 (zend_objects_API.c:76) 4 libphp5.so 0x0236c55c shutdown_executor + 1152 (zend_execute_API.c:273) 5 libphp5.so 0x02381600 zend_deactivate + 220 (zend.c:825) 6 libphp5.so 0x023167b8 php_request_shutdown + 1052 (main.c:1240) 7 libphp5.so 0x024464e8 apache_php_module_main + 336 (sapi_apache.c:60) 8 libphp5.so 0x02447a0c send_php + 964 (mod_php5.c:644) 9 libphp5.so 0x02447a98 send_parsed_php + 40 (mod_php5.c:656) 10 httpd 0xdd18 ap_invoke_handler + 232 11 httpd 0x00017dd4 process_request_internal + 640 12 httpd 0x00017e54 ap_process_request + 72 13 httpd 0x6b60 child_main + 1832 14 httpd 0x6dc4 make_child + 312 15 httpd 0x70f4 perform_idle_server_maintenance + 572 16 httpd 0x76d0 standalone_main + 964 17 httpd 0x7d74 main + 1052 18 httpd 0x238c _start + 348 19 httpd 0x222c start + 60 Thread 0 crashed with PPC Thread State: srr0: 0x0212aee4 srr1: 0x0200f030vrsave: 0x cr: 0x24000444 xer: 0x0006 lr: 0x0212b004 ctr: 0x0212afd4 r0: 0x0001 r1: 0xbfffdac0 r2: 0x r3: 0x02478898 r4: 0x003a7448 r5: 0x02d5 r6: 0x003a8c5b r7: 0xa753 r8: 0x0001 r9: 0x0211eb94 r10: 0x0236bab8 r11: 0x00058194 r12: 0x0212afd4 r13: 0x r14: 0x r15: 0x r16: 0x r17: 0x r18: 0x r19: 0x r20: 0x r21: 0x r22: 0x r23: 0x00056ec0 r24: 0x0001 r25: 0x0002 r26: 0x0183c038 r27: 0x01f4 r28: 0x0017 r29: 0x0183ffc0 r30: 0xbfffdac0 r31: 0x0212afec Binary Images Description: ... very lengthy part, which you probably wouldn't need, if otherwise, please give notice [2005-06-11 14:48:46] martin dot stricker at rz dot hu-berlin dot de Bug concerns 5.1beta1 [2005-06-11 14:45:34] martin dot stricker at rz dot hu-berlin dot de Description: PgSQL-Driver crashes Apache when attempting to c
#30931 [Com]: is_writable() and is_readable() return false when access is permitted via ACL
ID: 30931 Comment by: jr at terragate dot net Reported By: bugzilla-php at bwurst dot org Status: No Feedback Bug Type: Filesystem function related Operating System: gentoo linux (kernel 2.6) PHP Version: 5.0.2 New Comment: I've written a patch to address this issue. It uses POSIX's access function to determine file permissions. I tested this patch on Mac OS 10.4.1, Windows XP SP2 and FreeBSD 5.2.1. I am not sure if this patch also works for Win 9x (maybe R_OK, W_OK etc. are not defined there) and other non POSIX conformant OSes. Probably some more #ifndefs are required. http://jr.terragate.net/access.diff Previous Comments: [2005-05-12 21:34:01] nickls at apple dot com This also effects OS X Tiger ACLs. Why was this changed from access() on PHP 4.3.X? [2005-04-25 17:32:41] kibab at icehouse dot net This is not fixed yet as of Mar. 31 in the 5.0.4 release. [2005-03-08 01:00:08] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2005-02-28 21:21:59] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2004-11-29 17:26:56] bugzilla-php at bwurst dot org Description: PHP's is_readable() and is_writable() function report nonsense on ACLs... We have the following test case: A file containing \n"; echo __FILE__.' is '.(is_writable(__FILE__) ? '' : 'NOT ')."writable!\n"; ?> it's made accessible to the webserver via $ getfacl index.php # file: index.php # owner: someuser # group: webadm user::rw- user:apache:rw- group::r-- mask::rw- other::--- So apache is neither the owner nor in the group but it's accessible through ACL. If I call this file via the webserver, I get /srv/http/[...]/test/index.php is NOT readable! /srv/http/[...]/test/index.php is NOT writable! [...] has been inserted by me, of course. This method works perfectly, the webserver (and also PHP) *can* read and write the file but the is_readable() and is_writable() return wrong values. It really seems like bug #14923, but that one's fixed after php-4.1.0. Also it's CLOSED, so I cannot add a comment there. :-( -- Edit this bug report at http://bugs.php.net/?id=30931&edit=1
#33141 [Com]: libiconv dependency in gd extension not accounted for by linker
ID: 33141 Comment by: ntoge at amber dot plala dot or dot jp Reported By: liamr at umich dot edu Status: Assigned Bug Type: GD related Operating System: Linux 2.4.28 PHP Version: 5.0.4, 4.3.11 Assigned To: moriyoshi New Comment: Having a similar problem with php 5.1b1 on linux 2.6.11.11 (or 2.6.11.12) with gcc 3.3.2 or 3.4.1. With $ ./configure --with-apxs2=/usr/sbin/apxs --with-mysql=/usr/local/mysql --with-tidy --enable-mbstring --enable-mbregex --enable-zend-multibyte --with-zlib-dir=/usr/lib --with-gd --with-iconv-lib=/usr/local/lib Make dies with an undefined reference error on libiconv_open, called from ./ext/gd/libgd/gdkanji.c, although libiconv v.1.9.2 does live in /usr/local/lib. A quick work-around is to append -liconv in the definition of EXTRA_LIBS within Makefile, which allows make to proceed. The php module built that way works just fine. So I suspect a sort of a subtle bug with ./configure, but do not know what it is. Strangely, this problem never happened to me with php versions up to 5.0.4. Previous Comments: [2005-05-25 18:25:00] liamr at umich dot edu Description: The gd module can include undefined references to the following symbols.. U libiconv U libiconv_close U libiconv_open If compiled as a shared module, it can only load if something else w/ a libiconv dependency has loaded before it. On systems where GD detects libconv during configuration, -liconv should be added to GD_SHARED_LIBADD so the runtime linker can resolve those symbols. It looks like libiconv is only mentioned in gdkanji.c, but I had the same problem regardless of whether I built php with --enable-gd-jis-conv or not. -- Edit this bug report at http://bugs.php.net/?id=33141&edit=1
#33142 [Opn->Bgs]: Session info not getting saved correctly
ID: 33142 Updated by: [EMAIL PROTECTED] Reported By: jkump at everestgt dot com -Status: Open +Status: Bogus Bug Type: Session related Operating System: Solaris 9 PHP Version: 5.0.4 New Comment: You need to cast the stuff for it to become a string. $_SESSION["PRICE"] = (string) $InXML->price; Previous Comments: [2005-06-11 23:34:03] jkump at everestgt dot com Here is the flaming script. Red Nails $12.99 Robert E Howard 9/21/1977 '; $HTML_XML=''; $InXML = simplexml_load_string($XML); if (!isset($_REQUEST["SUBMIT"])) { $_SESSION["PRICE"] = $InXML->price; } echo "\n"; echo "Test PHP BUG 33142\n"; echo "\n"; echo "XML we are using: ".$HTML_XML."\n"; echo "\n"; if (isset($_SESSION["PRICE"])) { echo "PRICE before submit: ".$_SESSION["PRICE"]."\n"; } if (isset($_SESSION["PRICE"]) && isset($_REQUEST["SUBMIT"])) { echo "PRICE after submit: ".$_SESSION["PRICE"]."\n"; } echo "\n"; echo "\n"; echo "\n"; echo "\n"; echo "\n"; ?> [2005-06-11 19:50:43] [EMAIL PROTECTED] Impossible to test without a script -> bogus. (can not reproduce) [2005-06-08 20:38:45] jkump at everestgt dot com It seems as though the simplexml_load_string object is clobbering the Session object. http://www.fastcarrot.net/index.php [2005-06-08 02:40:42] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. [2005-06-07 06:34:15] jkump at everestgt dot com Please check this bug report with regard to sessions and simplexml_load_string() Thanks 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/33142 -- Edit this bug report at http://bugs.php.net/?id=33142&edit=1 Red Nails $12.99 Robert E Howard 9/21/1977
#31618 [Opn->Asn]: is_readable() results based on ownership of calling script, not file
ID: 31618
Updated by: [EMAIL PROTECTED]
Reported By: kibab at icehouse dot net
-Status: Open
+Status: Assigned
Bug Type: Filesystem function related
Operating System: redhat enterprise
PHP Version: 5CVS-2005-03-14
-Assigned To:
+Assigned To: wez
New Comment:
yet-another-streams-issue
Previous Comments:
[2005-05-19 06:14:33] kibab at icehouse dot net
>From memory, all files were mode 664 and all directories
had permissions of 775 being owned by root:root. However,
I no longer have that same structure to prove that. If
you like, I can setup an almost identical test case using
the code that I included below (but using my new
structure).
[2005-05-17 17:18:48] [EMAIL PROTECTED]
What are the permissions of all the directories in that path?
(/var/lib/php_packages/)
[2005-01-20 22:32:24] kibab at icehouse dot net
Maybe this isn't directly related, but
fopen($myfilename,"r") also fails, even though
include($myfilename) works. Again, $myfilename is in the
safe_mode_include_dir, so fopen should be able to open it.
[2005-01-19 23:05:35] kibab at icehouse dot net
Description:
is_readable($myfilename) in the repro code returns true if
the script calling it is owned by root, but false if it is
owned by someone else.
Permissions are:
-rw-r--r--1 root root 5452 Jan 13
13:02 /var/lib/php_packages/test_templ2.php
drwxr-xr-x4 root root 4096 Jan 19
08:19 /var/lib/php_packages
drwxr-xr-x 27 root root 4096 Jan 12
09:27 /var/lib
drwxr-xr-x 24 root root 4096 Sep 22
13:06 /var
drwxr-xr-x 20 root root 4096 Oct 29 09:48 /
Relevant Settings:
include_path =
".:/var/lib/php_packages:/var/lib/php_packages/pear"
safe_mode = On
safe_mode_gid = On
safe_mode_include_dir = /var/lib/php_packages
Reproduce code:
---
test.php ###
$myfilename = '/var/lib/php_packages/test_templ2.php';
if (is_readable($myfilename)) {
echo "is_readable: $myfilename (true)";
} else {
echo "is_readable: $myfilename (false)";
}
include($myfilename);
### test_templ2.php ###
TESTING!
Expected result:
I would expect is_readable() to return true in both
instances. The uid/gid check shouldn't matter despite
safe mode, as the file is in safe_mode_include_dir, and
even if it wasn't, the is_readable documentation says that
it does NOT take into account safe_mode restrictions.
Actual result:
--
// When test.php has the following ownership:
$ ls -l test.php
-rw-rw-r--1 root root 278 Jan 19 13:16
test.php
// I get the following output:
is_readable: /var/lib/php_packages/test_templ2.php (true)
TESTING!
// When test.php has the following permissions:
$ ls -l test.php
-rw-rw-r--1 dschlegel79 undergradadmiss 278 Jan
19 13:16 test.php
// I get the following output:
is_readable: /var/lib/php_packages/test_templ2.php (false)
TESTING!
--
Edit this bug report at http://bugs.php.net/?id=31618&edit=1
#33233 [Opn->Bgs]: mysqli_bind_param/simple_xml interaction problem
ID: 33233
Updated by: [EMAIL PROTECTED]
Reported By: blockcipher at yahoo dot com
-Status: Open
+Status: Bogus
Bug Type: SimpleXML related
Operating System: Windows 2000
PHP Version: 5.0.4
New Comment:
You need to cast the simplexml text to a string first.
Previous Comments:
[2005-06-07 21:11:46] blockcipher at yahoo dot com
There was no difference in behavior.
[2005-06-03 21:23:28] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
[2005-06-03 20:14:41] blockcipher at yahoo dot com
Here's a quick test case based on the problem. It demonstrates the
changing of the data type from an object to a string, but not the
crash.
test";
$xmlObj = simplexml_load_string($xmltext);
$tempArray['username'] = $xmlObj->user;
$dbh = new mysqli('localhost','username','password','mysql');
$stmt = $dbh->prepare('select host from user where user = ? LIMIT 1');
print "Before: ";
var_dump($tempArray);
print "Result: ";
$stmt->bind_param('s', $tempArray['username']);
$stmt->execute();
$stmt->bind_result($temp);
$stmt->fetch();
$stmt->close;
print "$tempAfter: ";
var_dump($tempArray);
$dbh->close;
?>
[2005-06-03 16:06:01] blockcipher at yahoo dot com
Description:
It appears that I found an interesting interaction between the
simple_xml library and the mysqli_bind_param function. The values
contained within an XML tag are returned as simple_xml object, not
strings (which is what I inferred from the Zend tutorial.) This had an
adverse side-effect when combined with the mysqli_bind_param function.
Please note that this may affect other functions/libraries as well.
The steps are as follows:
1. Copy the value of an XML element into a variable.
2. Use the element in a prepared mysqli statement, binding it to the
statement as a string.
3. Run the query.
4. Repeat steps 2 and 3, possibly with a different query.
After the bind or perhaps after I was done with the query, the actual
data was changed from a simple_xml object to a very odd looking string.
This would crash the apache web server approximately 80-90% of the time
when accessed.
Original variable data:
["username"]=>
object(SimpleXMLElement)#3 (1) {
[0]=>
string(4) "test"
}
Modified variable data:
["username"]=>
string(64) "a94a8fe5ccb19ba61c4c0873d391e987982fbbd3
"
Reproduce code:
---
No code provided since it is being developed for the company I work
for.
--
Edit this bug report at http://bugs.php.net/?id=33233&edit=1
