Я написал расширение PHP, и теперь у меня действительно действительно странный segfault.PHP Extension - Segfault С компиляцией выпуска PHP
Это нормально, если я запустить тестовый скрипт php test.php
или php < test.php
, но если я вход точно такие же команды в интерактивном режиме (php -a
), будет выдаёт ошибку сегментации.
46 char *_class_name = (char *)emalloc(_class_name_len);
(gdb) s
Program received signal SIGSEGV, Segmentation fault.
0x000055555578f664 in _emalloc()
я поначалу думал, что там могут быть некоторые проблемы с копией PHP бинарных файлов из Launchpad и я собрал свой собственный. Команда configure была './configure' '--prefix=/opt/php7-dbg' '--with-gd' '--with-mysqli' '--with-readline' '--with-curl'
. (Аргумент оптимизатора был -O2
.)
У меня точно такая же проблема, но на этот раз я мог пойти дальше.
46 char *_class_name = (char *)emalloc(_class_name_len);
(gdb) s
_emalloc (size=4) at /home/frederick/Programming/C/php-7.0.6/Zend/zend_alloc.c:2439
2439 {
(gdb) n
2442 if (UNEXPECTED(AG(mm_heap)->use_custom_heap)) {
(gdb) n
2450 return zend_mm_alloc_heap(AG(mm_heap), size ZEND_FILE_LINE_RELAY_CC ZEND_FILE_LINE_ORIG_RELAY_CC);
(gdb) s
zend_mm_alloc_heap (size=4, heap=0x7fffef000040) at /home/frederick/Programming/C/php-7.0.6/Zend/zend_alloc.c:1365
1365 if (size <= ZEND_MM_MAX_SMALL_SIZE) {
(gdb) n
1366 ptr = zend_mm_alloc_small(heap, size, ZEND_MM_SMALL_SIZE_TO_BIN(size) ZEND_FILE_LINE_RELAY_CC ZEND_FILE_LINE_ORIG_RELAY_CC);
(gdb) s
zend_mm_small_size_to_bin (size=4) at /home/frederick/Programming/C/php-7.0.6/Zend/zend_alloc.c:1211
1211 if (size <= 64) {
(gdb) n
1213 return (size - !!size) >> 3;
(gdb) s
zend_mm_alloc_heap (size=<optimised out>, heap=0x7fffef000040) at /home/frederick/Programming/C/php-7.0.6/Zend/zend_alloc.c:1366
1366 ptr = zend_mm_alloc_small(heap, size, ZEND_MM_SMALL_SIZE_TO_BIN(size) ZEND_FILE_LINE_RELAY_CC ZEND_FILE_LINE_ORIG_RELAY_CC);
(gdb) s
zend_mm_alloc_small (bin_num=<optimised out>, size=<optimised out>, heap=0x7fffef000040) at /home/frederick/Programming/C/php-7.0.6/Zend/zend_alloc.c:1286
1286 size_t size = heap->size + bin_data_size[bin_num];
(gdb) n
1287 size_t peak = MAX(heap->peak, size);
(gdb) n
1288 heap->size = size;
(gdb) n
1289 heap->peak = peak;
(gdb) n
1293 if (EXPECTED(heap->free_slot[bin_num] != NULL)) {
(gdb) n
1295 heap->free_slot[bin_num] = p->next_free_slot;
(gdb) p bin_num
$1 = <optimised out>
(gdb) n
Program received signal SIGSEGV, Segmentation fault.
zend_mm_alloc_small (bin_num=<optimised out>, size=<optimised out>, heap=0x7fffef000040) at /home/frederick/Programming/C/php-7.0.6/Zend/zend_alloc.c:1295
1295 heap->free_slot[bin_num] = p->next_free_slot;
Соответствующая функция в моем коде:
static std::string bnode_object_get_class_name(zval *object) {
char *ini_ns_key = estrdup("bencode.namespace");
zend_bool ini_ns = zend_ini_long(ini_ns_key, strlen(ini_ns_key), 0);
efree(ini_ns_key);
size_t _class_name_len = ZSTR_LEN(Z_OBJ_P(object)->ce->name);
// segfault line!
char *_class_name = (char *)emalloc(_class_name_len);
strcpy(_class_name, ZSTR_VAL(Z_OBJ_P(object)->ce->name));
std::string class_name(_class_name);
efree(_class_name);
if (ini_ns) {
return class_name.substr(8);
} else {
return class_name;
}
}
я тогда знал, какая линия произвела Segfault, и я хотел бы, чтобы решить эту проблему. Поэтому я сразу же скомпилировал отладочную сборку PHP (команда configure: './configure' '--prefix=/opt/php7-dbg' '--with-gd' '--with-mysqli' '--with-readline' '--with-curl' '--enable-debug'
, оптимизатор: -O0
).
Но с отладочной сборкой, основанной на тех же кодах, segfault просто ушел!
Я не очень опытный разработчик C/C++, и это первый случай, когда я столкнулся с такой проблемой. Пожалуйста, помогите, спасибо большое.
UPDATE
кажется, что проблема была вызвана глупой ошибкой. Линия, которая вызвала Segfault, должны быть
char *_class_name = (char *)emalloc(_class_name_len + 1);
, как строки C должны заканчиваться «\ 0»
Но почему это нормально с отладочных?
Интересный. Я посмотрел на это немного прошлой ночью и не видел никаких вопиющих ошибок.Я все еще не убежден, что ваше исправление действительно решает проблему. Насколько я знаю, 'emalloc' не знает, что он выделяет пространство для строки и нуждается в пространстве для' '\ 0''. Тот факт, что это отрыв, является странным. По моему опыту, при оптимизации оптимизации возникают проблемы, которые не наблюдаются при оптимизации. Моя ставка заключается в том, что у вас есть код UB в коде, который не показан, и по какой-либо причине он подвергается воздействию, когда вы вызываете 'emalloc'. Являются ли функции zend_' вашими? Что такое 'zval'? Что такое макросы? – yano
@yano Спасибо за ваш ответ! Эти макросы в основном из PHP, а PHP определяет собственный API-интерфейс 'emalloc': #define emalloc (размер) _emalloc ((размер) ZEND_FILE_LINE_CC ZEND_FILE_LINE_EMPTY_CC)'. Более того, PHP 'emalloc' будет вести себя по-разному в зависимости от многих факторов (будь то отладка или под Windows, или использование clang и т. Д.). Это довольно сложно, и я не знаю, откуда эта проблема. Возможно, вам нужен исходный код PHP https://secure.php.net/downloads.php#v7.0.6 –
eh ,, Я ничего не знаю о 'php'. Эта функция 'C++' вы отправили только код 'C++', который вы вызываете, или это вызвано из другого кода 'c/C++', который не был отправлен? Спасибо, что указали, что 'php' имеет функцию' emalloc', мне было интересно, почему ваш 'gdb' шаг в' emalloc' выглядел совершенно иначе, чем версия 'c': http: //www.cdf.toronto. edu/~ ajr/270/a2/soln/emalloc.c – yano