Реализация DataSet для YOLOv11 на базе Adept завершена!
Реализация DataSet для YOLOv11 на базе Adept завершена! Рассказываю, как я наступил на грабли с разделяемой памятью в многопроцессном DataLoader’е. 🔍 Предыстория В Adept есть модуль shared_mem_manager.cpp, который отвечает за межпроцессное взаимодействие через разделяемую память. При указании num_workers > 0 в DataLoader каждый воркер — отдельный процесс, и они синхронизируются через общий буфер. Всё шло гладко, пока я не запустил тренировку с несколькими воркерами. И тут — segmentation fault 💥. Не в логике обработки данных, а в коде синхронизации. ⚠️ Симптомы Ошибка валилась в коде: struct ShmInfo { std::atomic<int> ref_counter; }; class SharedMemoryBuffer : public SharedBuffer { void close() { ShmInfo* shm_info = static_cast<ShmInfo*>(ptr_); if (--shm_info->ref_counter == 0) { // ... } }; Сначала я грешил на гонку потоков или двойное освобождение буфера. ref_counter — atomic, всё должно быть потокобезопасно. Но почему тогда падает? Я потратил несколько часов, перепроверяя логику счётчика, синхронизацию процессов, порядок создания и удаления буферов. Всё выглядело корректно. Но segfault упрямо появлялся при обращении к shm_info. 🧠 Истина оказалась прозаичнее Если посмотреть на размер при создании и удалении отображения: Конструктор: SharedMemoryBuffer(void* ptr, const std::string& filename, size_t size, bool create) : ptr_(ptr), filename_(filename), size_(size + shm_alloc_offset) { ... } Тут размер буфера увеличивается на shm_alloc_offset — это нужно для хранения метаданных (в том числе ShmInfo) в начале сегмента. Деструктор / close: CHECK(munmap(ptr_, size_ + shm_alloc_offset) == 0, ...); В close() мы снова прибавляем shm_alloc_offset к size_, но size_ уже включает это смещение. В итоге munmap пытается освободить больше памяти, чем было выделено. Итог: выход за границы отображённой области, повреждение служебных структур, падение в самом неожиданном месте. 💡 Уроки 1. Двойное смещение — классика. Легко запутаться, когда константа применяется в разных местах. Лучшим решением было бы реализовать функцию возвращающую размер и использовать константу в одном месте. 2. Ошибки работы с памятью маскируются — проблемы могут возникнуть практически в произвольном месте кода не связанном с реальной ошибкой. Поэтому такие баги - одни из самых коварных. 3. Address Sanitizer (ASan) — лучший друг 🛠️. Если бы я сразу запустил бинарник с ASan, он скорее всего указал на некорректный размер в munmap. Не пренебрегайте санитайзерами. Берегите память, коллеги, и пусть ваши munmap всегда точно совпадают с mmap! 😉 #Adept #C++ #DataLoader #Segfault #MemoryManagement #AddressSanitizer