Question

我写了一个脚本，它做了一些非常简单的事情：

1）连接到Oracle 10数据库 2）检查是否存在tmp表 3）如果！存在，则创建tmp表（现有表的副本）
4）我对tmp表进行了一些数据操作（以模拟生产中会发生什么） 5）执行查询以获得两个表之间的差异，这是我遇到问题的地方。有问题的代码块低于具有前后星号的特定功能。

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);

如果我删除对oci_execute（）的调用，则代码可以正常运行，并返回一个空数组。如果我运行在Oracle CLI中传递给oci_execute（）的相同查询，则查询正常工作并返回我期望的数据。

这是脚本输出：

Segmentation fault (core dumped)

我在Solaris机器上使用PHP 5.2.13版。以前有没有人遇到过与oci_execute（）调用类似的行为？我对此感到有点失落。

Answer 1

经过大量的敲击，我想出了问题，感谢gdb。在我运行这个PHP脚本的系统上，它是针对不同的Oracle库而不是链接而构建的，因此存在导致核心转储的不匹配。当它与10g构建时，它链接到oracle 9库。

以下是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?)

正如您所看到的，当它应该使用10g库时它引用了9.2.0库。

任意速率都很好，脚本正在按预期运行。

PHP调用oci_execute（）会导致核心转储

1 个答案: