Открыть список
Как стать автором
Обновить

Комментарии 41

Спасибо за статью. Возникала такая проблема, но и в голову не пришло воспользоваться gdb.
НЛО прилетело и опубликовало эту надпись здесь
Так а проблему то свою изначальную решили?
Проблему изначальную не решил, потому что она не в PHP-скрипте моем была — зацикливается внутри libcurl. Каким-то образом linked list, хранящий в себе все хендлеры загрузок, превращается в кольцо, поэтому обход этого списка через while(curr) {blabla; curr = curr->next;} никогда не заканчивается. Отписался им в рассылку по этому поводу (вот, жду модерации). Без gdb я бы этого никогда не узнал )
НЛО прилетело и опубликовало эту надпись здесь
Если curl подвисает в бесконечном цикле без системных вызовов — что вы ожидаете увидеть?
НЛО прилетело и опубликовало эту надпись здесь
Ядро не занимается инспекцией кода user-level, это не его дело. Висит приложение в цикле или нет — не ядра дело, оно не знает, что приложение в цикле делает.

Не забудьте поставить ту-же версию curl.
В syslog не смотрел, но согласен с davinchi: ничего там не должно оказаться по идее.
Попробуйте другую (более старую) версию curl. Посмотрите, повторяется ли ошибка.

Скорее всего это связано с race condition, нужно искать где curl забывает защищать списки mutex'ами.
Я еще не проверил, повторяется ли эта ошибка в версии 7.22. Написал в рассыку, там говорят, тоже похожую проблему наблюдали, но в транке она уже якобы решена. Вот ссылка, если интересно: curl.haxx.se/mail/lib-2011-10/0061.html
Тут еще другая штука — мне было необходимо узнать, это у меня проблема или нет. Узнал, что в libcurl — теперь это не мое дело (разве что ради интереса поколупать в свободное время), потому что мы не можем физически собирать для каждого проекта-граббера патченный libcurl. Проще и дешевле написать демона, который после нескольких минут отсутствия записей в логах будет просто прибивать зациклившийся процесс.
За наводку на race condition спасибо, если будет время поковыряю посмотрю. Я как-то об этом и не подумал, хотя вроде же в PHP все в одном потоке идет.
Просто попробуйте собрать cURL из транка, если с ним повторяется — можно дальше в листе ругаться, если нет — profit!
Иногда чтобы найти причину проблемы достаточно strace -f -p $pid
Спасибо, буду иметь ввиду.
В данном случае не поможет — системных вызовов не делается, strace не покажет ничего.
Спасибо. А посмотреть зазенденые файлы не пробовали?
Пока что не ставил такую задачу перед собой. Не думаю, что там чего интересного будет, хотя разобраться и понять, как это работает — не помешало бы, наверное. Для общего развития.
dezend есть уже давно :)
В Дебиан можно было не пересобирать php, а поставить пакет php5-dbg
Не совсем хотелось ставить глобально дебаг-версию PHP на полубоевом сервере
Прочитал как «полуебовом сервере». Кажется, пора идти спать.
Так оно только хедеры ставит. Сам бинарь php не меняется, экстеншены тоже.
Если честно, я до конца не разобрался, что именно кроме .h-файлов и утилит типа phpize ставится пакетом php5-dev и чем отличаются пакеты php5-dev в ubuntu от этого php5-dbg на debian (или может быть это два разных пакета, имеющиеся на обоих системах). Но. Если он не меняет бинарник php, то отдебажить его не получится — нужно, чтобы бинарник был собран с ключом -g (в него должна быть включена информация для дебаггера), и наличие хедеров никак тут не поможет.
Да, был неправ, спутал -dev и -dbg. Тем не менее, -dbg не заменяет бинари, а ставит файлы в /usr/lib/debug/
Эти символы и нужны gdb или другим дебаггерам, чтобы показать читаемый stacktrace. Насчет ключа -g не знаю, нужно будет почитать…
-dbg предоставляет информацию для отладки помещая её в специальное место, где и ищет её gdb.
Местоположение и название пакетов зависят от дистрибутива.
статья зачетная,
только вот на реальном хостинге компилить пхп с ключом -d не хотелось бы — это раз
для реал-тайм мониторинга используем пимбу — это два.
для этого и компилил локально php с ключом -g, чтобы использовать его только для ловли бага на одном только скрипте. Все остальные кроны, веб-интерфейс, а так же остальные сайты на этом сервере, по-прежнему работают на основном, не пересобранном php, посталенном стандартным способом.
Не понимаю почему все думают, что «сборка == установка».
У меня 5 разных версий по крону собираются каждый день, но при этом ни одной не установлено — зачем?
Для дебага или тестирования не надо ничего ставить, достаточно собрать всё в один бинарник (но не делать make install!) и его запускать.
Тони, ты бы лучше человека поправил с «пимбой» :).
>Все что необходимо — это чтобы PHP был собран с ключом "-g".

На самом деле очень желательно -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, если я не ошибаюсь. Т.е. вроде как и оптимизация на полную, и вроде как и дебаг-инфа включается. Впрочем, я не стал загоняться сильно — мне хватило такого. Если вы поясните точнее почему это так как есть, буду благодарен.
Разница в этом:
-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 упорно валился.
Кстати именно с этой страницы развилась моя идея «а давайте влезем в работающий скрипт из gdb»
НЛО прилетело и опубликовало эту надпись здесь
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.