开发者

PHP call to oci_execute() results in core dump

I wrote a script that does a few very simple things:

1) Connects to an Oracle 10 database.

2) Checks to see if a tmp table exists.

3) If !exist, creates tmp table (copy of existing table)

4) I do some data manipulation to the tmp table (to simulate what will happen in production)

5) A query is performed to get the difference between the two tables and this is where I run into problems. The problematic block of code is below w/ the specific function having asterisks before and after it.

printf("  Finding difference between current and previous data .......");
$sCmd = sprintf("SELECT * FROM hrms_mview_previous WHERE cstatus='A' MINUS SELECT * FROM hrms_mview_current");
if (!($hDB_Results = oci_parse($hDB, $sCmd)))
{
  fprintf(STDERR, "ERROR\n  Error in MINUS query.\n\n");
  exit(1);
}
else
{
  **oci_execute($hDB_Results);**
  $iRows = oci_fetch_all($hDB_Results, $aRes);
  print_r($aRes);
  printf("done\n");
}

oci_free_statement($hDB_Results);

If I remove the call to oci_execute() the code excutes fine and an empty array is returned. If I run that 开发者_C百科same query that is being passed to oci_execute() in the Oracle CLI the query works fine and returns the data I expect it to.

This is the script output:

Segmentation fault (core dumped)

I am using PHP version 5.2.13 on a Solaris machine. Has anyone experienced similar behavior with calls to oci_execute() before? I am at a bit of a loss on this one.


After a lot of banging my head I figured out the problem, thanks to gdb. On the system I was running this script from PHP had been built against different Oracle libraries than it was linking to hence there was a mismatch which caused the core dump. It was linking to the oracle 9 libraries when it is built against 10g.

Here is the output from gdb: [gdb /opt/bin/php core]

Core was generated by `/opt/bin/php ./dbupdate_wfterm.php'.
Program terminated with signal 11, Segmentation fault.
#0  0xff050938 in memcpy () from /platform/SUNW,Sun-Fire-V490/lib/libc_psr.so.1
(gdb) backtrace
#0  0xff050938 in memcpy () from /platform/SUNW,Sun-Fire-V490/lib/libc_psr.so.1
#1  0xfdf5feac in nioqrc () from /opt/oracle/9.2.0/9.2.0/lib/libclntsh.so.9.0
#2  0xfe0ee0d0 in ttcdrv () from /opt/oracle/9.2.0/9.2.0/lib/libclntsh.so.9.0
#3  0xfdf6975c in nioqwa () from /opt/oracle/9.2.0/9.2.0/lib/libclntsh.so.9.0
#4  0xfdd61c40 in upirtrc () from /opt/oracle/9.2.0/9.2.0/lib/libclntsh.so.9.0
#5  0xfdd61c40 in upirtrc () from /opt/oracle/9.2.0/9.2.0/lib/libclntsh.so.9.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

As you can see it was referencing the 9.2.0 libraries when it should be using the 10g libs.

At-any-rate all is well and the script is running as expected.

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜