PHP 调用 oci_execute() 导致核心转储答案

【问题标题】：PHP call to oci_execute() results in core dumpPHP 调用 oci_execute() 导致核心转储
【发布时间】：2011-02-16 19:11:42
【问题描述】：

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

1) 连接到 Oracle 10 数据库。
2) 检查是否存在 tmp 表。
3) 如果 !exist，则创建 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() 时遇到过类似的行为？我对这个有点不知所措。

【问题讨论】：

标签： php sql oracle

【解决方案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 库。

无论如何，一切都很好，脚本正在按预期运行。

【讨论】：