Есть боооольшой скрипт. Использует несколько внешних сишных модулей (не моих).
Если он достаточно долго работает под нагрузкой - молча валится с segmentation fault.
Насколько я понимаю, с наибольшей долей вероятности - это сишная проблема. То ли модуля какого-то, толи интрепретатора.

Отсмотреть по коду - после какого вызова это проиходит - оочень сложно (оочень много кода =)

Как-бы понять - кто виноват?

P.S. на ум приходят разные мельком слышанные слова - типа stack trace - но в С я слабо шарю. Если дейсвительно нужен этот stack trace - то как его добыть?

shiza
P.S. на ум приходят разные мельком слышанные слова - типа stack trace - но в С я слабо шарю. Если дейсвительно нужен этот stack trace - то как его добыть?

Читать документацию gdb на предмет post-mortem dubugging. Если коротко, то:
$ gdb /path/to/python /path/to/core

(gdb) bt

Понятно, что питон и библиотеки должны быть сбраны с отладочной информацией. Без стека бессмысленно что-то предполагать. Но даже с ней может оказаться не всё так просто: падение очень часто происходит не там, где ошибка. В этом случае помогут средства отладки вроде valgrind: он выставляет “защиту” на границах переменных и при обращении к этим местам об этом сообщает, что позволяет поймать ошибку ближе к её месту в коде.

Как все непросто… Попробовал под windows запусить - так-же выпадает. Может под виндовс проще отдебажить это?

На самом деле не всё так сложно, как кажется, даже знание C обычно не требуется. В UNIX для такой отладки есть все средства. А вот под Windows я даже не знаю, с какой стороны подойти.

Ето 99% проблем сишние модулы. segmetation fault - ето переполнение какой-то string/ array, индексирование out of range, что-то такое, думаю. Есть вероятность где-то вызываешь С-функция с некорректными параметры вроде длина, граница, что-то такое. Но если так, то ето значит, что внешний модуль не отработать ошибке. Трудное сказать что-то конкретнее, труднее писать по русскому тоже, но если нет С-исходники , то нечего не поделаешь

ods все правильно пишет…

если С модуль сделан ввиде питон-расширения то я фик знат…
НО если это просто библиотека то _точно_ можно отдебежить только ее.

Процесс получае sigsegv в момент обращения к невалидному участку памяти.
А вот почему он таким стал…

Всем спасибо. =)
Перспектива процесса пересборки всех библиотек, и бибилиотек от которых зависят эти бибиотеки в debug режиме меня несколько смутила.
Поступил проще - погуглил всех замешенных лиц с “segmantation fault” и нашел виновника в баг-траке (libcurl - оказался виноват).

Та версия pycurl, которая доступна на сайте, требовала такую версию libcurl в которой видимо была бага при работе с FTP.
Мне показалось (судя по колву задокументированных багов) что у курла вообще с фтп не очень.
Обошел тем, что перестал парсить FTP. =)

хм. у меня курл не в нитях работает. а с его мултиселектом.
Хотя нити есть в самой проге.

У меня такое подозрение - что этот fork жрет дофига памяти.
Там же небось на каждый форк уходит своя копия питона?

shiza
хм. у меня курл не в нитях работает. а с его мултиселектом.
Хотя нити есть в самой проге.

У меня такое подозрение - что этот fork жрет дофига памяти.
Там же небось на каждый форк уходит своя копия питона?

сам интерпретатор – это шареная либа. внутренние структуры наверняка будут создаваться заново для форка, но сам код – общий?