Комментарии 41
Спасибо за статью. Возникала такая проблема, но и в голову не пришло воспользоваться gdb.
НЛО прилетело и опубликовало эту надпись здесь
Тут есть масса информации про это: ru2.php.net/manual/en/internals2.variables.intro.php
Ну и не забывайте про исходники.
Поддержка ctags или cscope в редакторе так же помогает.
Ну и не забывайте про исходники.
Поддержка ctags или cscope в редакторе так же помогает.
Так а проблему то свою изначальную решили?
Проблему изначальную не решил, потому что она не в PHP-скрипте моем была — зацикливается внутри libcurl. Каким-то образом linked list, хранящий в себе все хендлеры загрузок, превращается в кольцо, поэтому обход этого списка через while(curr) {blabla; curr = curr->next;} никогда не заканчивается. Отписался им в рассылку по этому поводу (вот, жду модерации). Без gdb я бы этого никогда не узнал )
НЛО прилетело и опубликовало эту надпись здесь
Попробуйте другую (более старую) версию curl. Посмотрите, повторяется ли ошибка.
Скорее всего это связано с race condition, нужно искать где curl забывает защищать списки mutex'ами.
Скорее всего это связано с race condition, нужно искать где curl забывает защищать списки mutex'ами.
Я еще не проверил, повторяется ли эта ошибка в версии 7.22. Написал в рассыку, там говорят, тоже похожую проблему наблюдали, но в транке она уже якобы решена. Вот ссылка, если интересно: curl.haxx.se/mail/lib-2011-10/0061.html
Тут еще другая штука — мне было необходимо узнать, это у меня проблема или нет. Узнал, что в libcurl — теперь это не мое дело (разве что ради интереса поколупать в свободное время), потому что мы не можем физически собирать для каждого проекта-граббера патченный libcurl. Проще и дешевле написать демона, который после нескольких минут отсутствия записей в логах будет просто прибивать зациклившийся процесс.
За наводку на race condition спасибо, если будет время поковыряю посмотрю. Я как-то об этом и не подумал, хотя вроде же в PHP все в одном потоке идет.
Тут еще другая штука — мне было необходимо узнать, это у меня проблема или нет. Узнал, что в libcurl — теперь это не мое дело (разве что ради интереса поколупать в свободное время), потому что мы не можем физически собирать для каждого проекта-граббера патченный libcurl. Проще и дешевле написать демона, который после нескольких минут отсутствия записей в логах будет просто прибивать зациклившийся процесс.
За наводку на race condition спасибо, если будет время поковыряю посмотрю. Я как-то об этом и не подумал, хотя вроде же в PHP все в одном потоке идет.
Иногда чтобы найти причину проблемы достаточно strace -f -p $pid
Спасибо. А посмотреть зазенденые файлы не пробовали?
В Дебиан можно было не пересобирать php, а поставить пакет php5-dbg
Не совсем хотелось ставить глобально дебаг-версию PHP на полубоевом сервере
Прочитал как «полуебовом сервере». Кажется, пора идти спать.
Так оно только хедеры ставит. Сам бинарь php не меняется, экстеншены тоже.
Если честно, я до конца не разобрался, что именно кроме .h-файлов и утилит типа phpize ставится пакетом php5-dev и чем отличаются пакеты php5-dev в ubuntu от этого php5-dbg на debian (или может быть это два разных пакета, имеющиеся на обоих системах). Но. Если он не меняет бинарник php, то отдебажить его не получится — нужно, чтобы бинарник был собран с ключом -g (в него должна быть включена информация для дебаггера), и наличие хедеров никак тут не поможет.
статья зачетная,
только вот на реальном хостинге компилить пхп с ключом -d не хотелось бы — это раз
для реал-тайм мониторинга используем пимбу — это два.
только вот на реальном хостинге компилить пхп с ключом -d не хотелось бы — это раз
для реал-тайм мониторинга используем пимбу — это два.
для этого и компилил локально php с ключом -g, чтобы использовать его только для ловли бага на одном только скрипте. Все остальные кроны, веб-интерфейс, а так же остальные сайты на этом сервере, по-прежнему работают на основном, не пересобранном php, посталенном стандартным способом.
Не понимаю почему все думают, что «сборка == установка».
У меня 5 разных версий по крону собираются каждый день, но при этом ни одной не установлено — зачем?
Для дебага или тестирования не надо ничего ставить, достаточно собрать всё в один бинарник (но не делать make install!) и его запускать.
У меня 5 разных версий по крону собираются каждый день, но при этом ни одной не установлено — зачем?
Для дебага или тестирования не надо ничего ставить, достаточно собрать всё в один бинарник (но не делать make install!) и его запускать.
>Все что необходимо — это чтобы PHP был собран с ключом "-g".
На самом деле очень желательно -g3 и еще -O0 к нему в добавок.
Ибо без них многие нужные в дебаге переменные оптимизируются и выходит вот такое:
На самом деле очень желательно -g3 и еще -O0 к нему в добавок.
Ибо без них многие нужные в дебаге переменные оптимизируются и выходит вот такое:
(gdb) p var
var =
В `man gcc` уровни опций -g и -O описаны довольно подробно.
>По каким-то причинам PHP 5.2.17 собрался у меня не в debug сборке с этим ключом
Понятно по каким - если он упадёт, то в корке хоть что-то должно быть читабельное, иначе не о чем будет баг-репорты писать в Дебиан.там было «var = <value optimized out>»
Насколько я понимаю, желательно все-таки -O0, -g3 не очень-то и нужно (по крайней мере я в манах когда про -g читал, понял это будто какая-то дополнительная инфа)
По поводу сборки PHP не совсем понял. Тот, который ставился из пакетов не имел дебажной инфы в себе, а тот который я просто скомпилил с --disable-debug почему-то имел при компиляции ключи помойму -g -O2, если я не ошибаюсь. Т.е. вроде как и оптимизация на полную, и вроде как и дебаг-инфа включается. Впрочем, я не стал загоняться сильно — мне хватило такого. Если вы поясните точнее почему это так как есть, буду благодарен.
По поводу сборки PHP не совсем понял. Тот, который ставился из пакетов не имел дебажной инфы в себе, а тот который я просто скомпилил с --disable-debug почему-то имел при компиляции ключи помойму -g -O2, если я не ошибаюсь. Т.е. вроде как и оптимизация на полную, и вроде как и дебаг-инфа включается. Впрочем, я не стал загоняться сильно — мне хватило такого. Если вы поясните точнее почему это так как есть, буду благодарен.
Разница в этом:
-g (то же, что и -g1):
Level 1 produces minimal information, enough for making backtraces in parts of the program that you don't plan to debug.
Т.е. так прямо в мануале и написано, что -g — это если вы не планируете дебажить, это так, для бэктрэйса максимум.
-g3:
Level 3 includes extra information, such as all the macro definitions present in the program. Some debuggers support macro expansion when you -g3.
Почувствуйте разницу. Здесь точно всё-всё останется, даже макросы. Но и размер бинарника будет соотв-щий.
"-g -O2" — это универсальные дефолтовые ключи сборки, так везде.
Зачем нужен -g я только что уже сказал.
-O2 — это неэкстремальные оптимизации, как раз для сферического продакшена в вакууме.
Есть еще и -O3, см. man gcc.
-g (то же, что и -g1):
Level 1 produces minimal information, enough for making backtraces in parts of the program that you don't plan to debug.
Т.е. так прямо в мануале и написано, что -g — это если вы не планируете дебажить, это так, для бэктрэйса максимум.
-g3:
Level 3 includes extra information, such as all the macro definitions present in the program. Some debuggers support macro expansion when you -g3.
Почувствуйте разницу. Здесь точно всё-всё останется, даже макросы. Но и размер бинарника будет соотв-щий.
"-g -O2" — это универсальные дефолтовые ключи сборки, так везде.
Зачем нужен -g я только что уже сказал.
-O2 — это неэкстремальные оптимизации, как раз для сферического продакшена в вакууме.
Есть еще и -O3, см. man gcc.
Кстати, для отладки под Apache, скажем тех же PHP-модулей, есть полезный ключик для него — "-X". Помогло при отладке, когда с консоли PHP-модуль работал нормально, а под Apache упорно валился.
Вот тут есть подробные инструкции на (почти?) все случаи жизни: bugs.php.net/bugs-generating-backtrace.php
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
PHP под С-шным дебаггером: копаемся внутри Zend Engine