PHP 7, пытающийся уничтожить ресурс, полученный из C-расширения, производит segfault - PullRequest
0 голосов
/ 23 февраля 2019

Написал C-расширение для PHP 5, а сейчас обновляю его до PHP 7.

Я изменил все вызовы API в соответствии с новыми требованиями Zend Framework, чтобы код компилировался.Поместил мой .so-файл в расположение расширения, и служба php-fpm начинает работу.

В основном я запрашиваю настраиваемую хеш-таблицу (устаревший код) из моего расширения C, преобразовываю ее в zval и использую в phpи затем, когда область действия заканчивается, должен вызываться деструктор, но здесь есть проблема, и мы видим ошибку сегментации.

Вот мой код C-файла:

static int le_myResource;
#define le_myResource_name  "a myResource resource"

void myResource_destruction_handler(zval *rsrc TSRMLS_DC)
{
    myResource *d = (myResource *)zend_fetch_resource(Z_RES_P(rsrc), le_myResource_name, le_myResource);
    myResource_free(d);
}

rsrc_dtor_func_t myResource_destruction_handler;
le_myResource = zend_register_list_destructors_ex(myResource_destruction_handler, NULL, le_myResource_name, module_number);

ZEND_FUNCTION(myhash_new)
{
    myResource *d;
    d = myHash_new(); // my legacy project code returning a hash. The same way it returned to php5

    RETURN_RES(zend_register_resource(d, le_myResource));
}

И этоэто вызывающий PHP-файл

<?php
class dbd {

    function query()
    {
        $reply = myhash_new()
        // use $reply
        // print statement here works

    }// this is where the problem occurs
}
?>

В трассировке стека GDB показано следующее:

Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `php-fpm: pool www                                                             '.
Program terminated with signal 11, Segmentation fault.
#0  0x0000000900000000 in ?? ()
Missing separate debuginfos, use: debuginfo-install ironwood-php-7.2.3.bfeature.B.88927_upgrade_to_php7-r20180313172814.9f25293.bLOCAL.x86_64
(gdb) bt
#0  0x0000000900000000 in ?? ()
#1  0x000000170000003e in ?? ()
#2  0x0000000001fb3250 in ?? ()
#3  0x0000000000000003 in ?? ()
#4  0x00007fbbff29e160 in ?? ()
#5  0x000000000079f8fa in list_entry_destructor ()
#6  0x00000000007971ba in zend_hash_index_del ()
#7  0x000000000084168f in zend_leave_helper_SPEC ()
#8  0x00000000007d4228 in execute_ex ()
#9  0x0000000000841327 in zend_execute ()
#10 0x0000000000787094 in zend_execute_scripts ()
#11 0x000000000071300e in php_execute_script ()
#12 0x000000000084ebfe in main ()

Не уверен, что я могу контролировать память, генерируемую из сторонней библиотеки, итогда избегайте его повреждения.Этот же кусок раньше работал с php5.Сканировал много на WWW, но не смог взломать его.Любые указатели будут полезны.

1 Ответ

0 голосов
/ 25 февраля 2019

Нашел проблему.это было из-за использования rsrc_dtor_func_t для моей функции деструктора.У меня были проблемы с компиляцией ранее, когда я не использовал указанное выше ключевое слово.

Также заменил zval * на zend_resource * в myResource_destruction_handler и изменил функцию на static void myResource_destruction_handler ()который решил все мои проблемы.

На данный момент я не сталкиваюсь с падениями уровня разрушения.

...