Реализация DataSet для YOLOv11 на базе Adept завершена!
Рассказываю, как я наступил на грабли с разделяемой памятью в многопроцессном DataLoader’е.
🔍 Предыстория
В Adept есть модуль shared_mem_manager.cpp, который отвечает за межпроцессное взаимодействие через разделяемую память. При указании num_workers > 0 в DataLoader каждый воркер — отдельный процесс, и они синхронизируются через общий буфер.
Всё шло гладко, пока я не запустил тренировку с несколькими воркерами. И тут — segmentation fault 💥. Не в логике обработки данных, а в коде синхронизации.
⚠️ Симптомы
Ошибка валилась в коде:
struct ShmInfo {
std::atomic ref_counter;
};
class SharedMemoryBuffer : public SharedBuffer {
void close() {
ShmInfo* shm_info = static_cast(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
Рассказываю, как я наступил на грабли с разделяемой памятью в многопроцессном DataLoader’е.
🔍 Предыстория
В Adept есть модуль shared_mem_manager.cpp, который отвечает за межпроцессное взаимодействие через разделяемую память. При указании num_workers > 0 в DataLoader каждый воркер — отдельный процесс, и они синхронизируются через общий буфер.
Всё шло гладко, пока я не запустил тренировку с несколькими воркерами. И тут — segmentation fault 💥. Не в логике обработки данных, а в коде синхронизации.
⚠️ Симптомы
Ошибка валилась в коде:
struct ShmInfo {
std::atomic ref_counter;
};
class SharedMemoryBuffer : public SharedBuffer {
void close() {
ShmInfo* shm_info = static_cast(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