Как поймать Segmentation fault?

Пробовал уже различные -fsanitize=X?

Пробовал уже различные -fsanitize=X?

+, вдогонку хочется спросить, компиляет ли ОП со всеми ворнингами и правил ли то, что ворнинги пишут?

Валгринд попробуйте обязательно. Он конечно тормозит сильно, но вскрывает много проблем.

Добро пожаловать во всратый мир крестов. Если еще не понял.

Это ты еще не отлаживал говно на крестах, которое в релизной сборке падает на клиентской машине, к которой нет доступа. Через корку.

Это одна из причине по которой кресты, да и в принципе сишечку, надо выкидывать отовсюду откуда можно.

Для видеостриминга вообще с головой и за глаза хватает дотнета или же например лиспа.

Ошибки с malloc это обычное дело когда повреждается куча из-за багов с переполнением буфера выделенного через malloc. -fsanitize=address должно быть достаточно чтобы поймать падение, и должно быть проще использования valgrind.

и должно быть проще использования valgrind

Намного быстрее в плане производительности. Но требует перекомпиляции проекта, в отличие от valgrind. Для валгринда есть гуишки, alleyoop например очень лёгок в использовании

Настрой чтоб при сегфолте создавало корку. Потом помедитируешь над ней на досуге.

Когда-то у меня был «неуловиный Джо» в коде на сишке, я сделал чтоб по сигналу создавалась корка и процесс продолжал работать. Потом когда возник глюк, отправил сигнал и отловил где проблема.

Настрой чтоб при сегфолте создавало корку

Он уже в отладчике сегфолт поймал, и видно повреждение памяти, зачем тут корка. Не, ну конечно может повезти и выпадет крэш с более информативный трейсом, но шансы на это невелики

CHandleH264::HandleRead(CHandlers::stPkt_t&) ()

Получаем ссылку на пакет, не спеша с ним работаем. А тем временем тред принимающий пакеты решает что память под нашим пакетом ему нужна…

-fsanitize=address

Кроме ASAN-а не забыть -fno-omit-frame-pointer, чтоб стек показывался нормально в отчёте. Можно с ним релизную версию собирать - быстрее ошибка случится.

Для видеостриминга вообще с головой и за глаза хватает дотнета или же например лиспа.

Тогда уж питона. Он хотя бы язык программирования.

причем тут malloc_consolidate, видишь #3 0xb6ac1aca in __GI___libc_realloc (oldmem=0x0, bytes=1264) at malloc.c:3001 ? как реалочить нулевой указатель, алё?

If ptr is NULL, then the call is equivalent to malloc(size), for all values of size

само наличие realloc говорит о существенных проблемах.

Можно с ним релизную версию собирать - быстрее ошибка случится.

Не можно, а нужно — не факт, что ошибка вообще воспроизведётся в дебажной версии.

#3 0xb6ac1aca in __GI___libc_realloc (oldmem=0x0, bytes=1264) at malloc.c:3001

Видимо произошла порча памяти кучи. Это могло ароизойти например из-за исподьзования после освобождения, двойного освобождения, записи по неправильному адресу в результате чего повредилась метаинфоомация кучи.

в моем коде нет прямого вызова realloc, внутри HandleRead работа с очередью, размер которой выделен при запуске и не меняется никогда.

пробую как посоветовали -fsanitize=address -fno-omit-frame-pointer -Wall -pedantic -O3

упало и при export MALLOC_CHECK_=3 не написав ничего

Стек падения почти сразу же уходит в ffmpeg, который часть приложения или нет? Если давать кривые указатели для ffmpeg, который не пересобран с указанными флагами, то он у себя испортит память, санитайзер не поможет.

Например, если ffmpeg нужен буфер большего размера, чем ему передали, и он его переполнит у себя.

часть приложения, спасибо если не поможет пересоберу его

если ffmpeg нужен буфер большего размера

он и делает realloc буфера, поскольку кадры складываются в очередь из одних и тех же указателей

Надо пересобрать ffmpeg с санитайзером, если он входит в приложение. В ffmpeg тоже могут быть баги, или он неправильно используется. Кстати, может еще так быть что есть системный libffmpeg и хидеры для него, и есть локальный ffmpeg в приложении, но при сборке хидеры локального путаются с системными. Что может что-нибудь сломать, если есть изменения API между версиями.

нет, я указываю откуда линковать и хедеры и либы принудительно.

а вот гонка при релоке буфера и обращении к нему это мысль, буду ее проверять

Был случай, когда С++ писатель инициализировал поток прямо в конструкторе класса через «initializer list», а поля инициализируются по порядку объявления в классе, этот поток сразу же стартует и начинает обращаться к полям объявленным ниже потока. Есть шанс что эти поля не успеют проинициализироваться, когда поток уже начнёт их использовать. Я этот баг нашел. Типичный С++, когда обмазался абстрациями и уже потерял понимание как это работает.

) тогда бы сегфолилось в начале, а не непредсказуемо через несколько часов

Так это же состояние гонки, обычно поток с задержкой выполняется, и класс успевает проинициализироваться. Но если система тормознёт основной поток, и потом запустит дочерний раньше, а это редко происходит, то только тогда будет проблема.

Вот пример по памяти:

#include <chrono>
#include <thread>
#include <iostream>

struct X;
void f1(X *x);

struct W {
  W(int delay) {
    std::this_thread::sleep_for(std::chrono::milliseconds(delay));
  }
};

struct X {
  X() : t(f1, this) {};
  ~X() { t.join(); };
  std::thread t;
  W wait = 10;
  int canary = 123;
};

void f1(X *x) {
  std::cout << x->canary << '\n';
}

int main() { X(); }

-fsanitize=address -fno-omit-frame-pointer

нормально так с этими ключами у меня памяти заняло 70%, свят свят такое в релиз собрать

А чего тут искать, санитары это сразу отловят независимо от имеется там задержка или нет, даже если дочерний поток притормозит со стартом и все поля успеют проинициализироваться

Меня просто бомбит от таких высказываний. Естественно он тормозит, это интерпретатор машинного кода. Он для того и нужен, чтобы выполнить программу через него и отследить ее поведение.

А вы уверены, что функции потокобезопасны, которые используются?

Конечно, этот код уже есть, но в следующий раз хорошенько подумайте, а не вариант ли сделать распараллеливание через процессы ОС.

Слышал про преступление и наказание? Ты в своих прошлых темах очень сильно злоупотреблял хаками в многопоточном программировании. Цпп такое не прощает и награждает сегфолтами. Теперь наслаждайся.

какие такие хаки я использовал?

если пользуете внешний код в разных потоках, надо обязательно выяснить насколько он thread-safe - это должно быть написано большими красными буквами в любой документации.

если он не thread-safe, можете убиться от стену, но никакого нормального многопотока на таком коде вы не получите.

зарактер повреждений говорит о том, что похоже ваша либа не thread safe. ну или ваш код работы с ней не таков(если она thread-safe).

Да пожалуйста

Требуется реализовать очередную хитро.опую очередь для многопоточной обработки, поступающих с h264 камеры nalu блоков, которые в контексте libav библиотек от ffmpeg будем считать условными кадрами.

На каждую хитроопую очередь у цпп найдётся сегфолт с левой резьбой. И таки нашёлся.

Из твоих комментов получается что питон-говно, с/с++ говно.

Получается есть 2 яп, лисп и c# которые не говно?

На каждую хитроопую очередь у цпп найдётся сегфолт с левой резьбой. И таки нашёлся.

пока что звучит как «просто не надо брать C++». А где же «убийство старушки»?

) да это ж не первый, прошлый раз помогли найти тоже на форуме этом и сейчас уверен все получится, жду когда упадет

так то да есть мысль такая, ибо уже столкнулся с тем, что нельзя декодированный кадр одновременно 2 потоками пожать в разные кодеки, пришлось копировать память в одном

На каждую хитроопую очередь у цпп найдётся сегфолт с левой резьбой. И таки нашёлся.

хе хе, а похоже вы без всяких санитайзеров правы, что если всему виной очередь, это объяснило бы длительность до падения (поток чтение с камеры ВДРУГ догоняет поток делающий с нее jpeg) и трассировку стека

… на крестах, которое в релизной сборке падает на клиентской машине …
… за глаза хватает дотнета …

Как-то раз пришлось воспользоваться либой на Си-шарпе. Всё работало, пока не запустили релизную сборку. Оказалось, как и в Си, там тоже меняют поведение программы в зависимости от типа сборки.

Эта относится к любому языку. Многопоток это просто тупо сложно. И тупое отсутствие data race вообще не делает программу валидной. И все эти потуги «безопасных» язычков смешны, как и их адепты, которые свято верят, что вот на своём правильном язычке они не наговнокодят как эти старперы на цпп. Примут за обе щеки как только решат написать что-то сложнее простешего примера с одним мьютексом из букваря

Только в языках типа Go у тебя есть инструменты эти ошибки найти и исправить очем быстро, а вот в крестах нет)

пиши на c/++ @ лови

Только в языках типа Go у тебя есть инструменты эти ошибки найти и исправить очем быстро, а вот в крестах нет)

Какие там инструменты? Получилось так, что молодые и дерзкие язычки пришли убивать цпп, но великодушный цпп раздал всем своим убийцкам по санитайзеру. Вот Go:

The race detector is based on the C/C++ ThreadSanitizer runtime library, which has been used to detect many errors in Google’s internal code base and in Chromium. The technology was integrated with Go in September 2012; since then it has detected 42 races in the standard library. It is now part of our continuous build process, where it continues to catch race conditions as they arise

Вот и все инструменты. И это только самая элементарщина - отлов data race. Если пишешь не хелоу ворлд с несколькими горутинами, в каждой из которых логика относительно независима, а более менее сложную систему, где несколько потоков, общих данных, мьютексов и тп, то обосраться как два пальца об асфальт на самых простых (вроде бы) задачах - например, поменять состояние всей системы разом, чтобы никто не увидел никакой неконсистентости, при этом, естественно, не вляпаться в dead lock’и, и никакие санитайзеры здесь не помогут. Бьюсь об заклад, львиная доля модников на своих убийцах цпп жидко обделаются и убегут со скулежом обратно писать хелоу ворлды

since then it has detected 42 races in the standard library

Статья 2013 года, меньше чем за год в стандартной либе найдено 42 data race )). Охерительные у вас там инструменты, пока цпп не выдал вам санитайзер, даже свою стд не могли написать без говнокода ))

Интересный конечно спор про языки, только у меня все равно под железо пишется и чем дальше тем более узко, сейчас пришли люто дешёвые ip камеры на goke, натянули на них openipc, картинка огонь, стоят почти ничего, конкуренты так вообще прям на них сервисы мудрят - какие шарпы, го и тыпы )

видеостриминг на бидоне это какая-то неудачная шутка

Обработку изображений, кодирование и проч. никто дрочить на Питоне не будет. Питон в таких случаях используется как обвязка над сишными или плюсовыми либами.

таки упало с этими санитайзерами с ошибкой Bus error и больше ничего, в gdb не запускал, в дмесге

[129545.817301] Alignment trap: not handling instruction e8502f00 at [<0026aaa8>]
[129545.824701] Unhandled fault: alignment exception (0x221) at 0x45000009
[129545.831377] pgd = db3ba5c0
[129545.834213] [45000009] *pgd=43138003, *pmd=00000000

Упало уже в ядре? Поздравляю. Видимо ffmpeg использует аппаратное ускорение.

Это может быть не связанной проблемой, а багом в ffmpeg или драйверах. Если вы крутили код несколько суток под полной загрузкой, то это может быть сбой железа вызванный перегревом.

сейчас переделал один из потоков работающий с очередью, скорее всего проблема в этом, как заметил ox55ff

скорее всего поток делающий снимок по полученным с ip камеры кадрам натыкается на кадры, которые не может декодировать (иногда декодер пишет что нибудь в духе non-existing PPS 0 referenced или Error splitting the input into NAL units.), а в общем случае я декодеру подсовываю буфер из очереди в котором SPS блок находится и поэтому почти всегда работает, но иногда видимо не успевает и поток чтения с камеры переписывает буфер)