PHP-вызов oci_execute() приводит к дампу памяти

Я написал скрипт, который делает несколько очень простых вещей:

1) Подключается к базе данных Oracle 10.
2) Проверяет, существует ли временная таблица.
3) Если !exist, создает временную таблицу (копию существующей таблицы)
4) I выполнить некоторые манипуляции с данными в таблице 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(), код выполняется нормально, и возвращается пустой массив. Если я запускаю тот же запрос, который передается в oci_execute() в Oracle CLI, запрос работает нормально и возвращает ожидаемые данные.

Это вывод скрипта:

Segmentation fault (core dumped)

Я использую PHP версии 5.2.13 на машине Solaris. Кто-нибудь сталкивался с подобным поведением при вызовах oci_execute() раньше? Я немного теряюсь в этом.


person Nicholas Kreidberg    schedule 16.02.2011    source источник


Ответы (1)


После долгих размышлений я понял проблему, благодаря gdb. В системе, в которой я запускал этот скрипт из PHP, он был создан для разных библиотек Oracle, чем он был связан, поэтому возникло несоответствие, которое вызвало дамп ядра. Он был связан с библиотеками оракула 9, когда он был построен против 10g.

Вот вывод 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?)

Как вы можете видеть, он ссылался на библиотеки 9.2.0, когда должен был использовать библиотеки 10g.

В любом случае все хорошо, и скрипт работает, как и ожидалось.

person Nicholas Kreidberg    schedule 17.02.2011