Меня зовут Кирилл Колодяжный этом канале я буду рассказывать про разработку открытой платформы машинного обучения Adept.
https://adept-platform.gitverse.site/adept-docs/
Post #51
156
Реализация DataSet для YOLOv11 на базе Adept завершена!
Рассказываю, как я наступил на грабли с разделяемой памятью в многопроцессном
🔍 Предыстория
В Adept есть модуль shared_mem_manager.cpp, который отвечает за межпроцессное взаимодействие через разделяемую память. При указании
Всё шло гладко, пока я не запустил тренировку с несколькими воркерами. И тут — segmentation fault 💥. Не в логике обработки данных, а в коде синхронизации.
⚠️ Симптомы
Ошибка валилась в коде:
Сначала я грешил на гонку потоков или двойное освобождение буфера.
Я потратил несколько часов, перепроверяя логику счётчика, синхронизацию процессов, порядок создания и удаления буферов. Всё выглядело корректно. Но segfault упрямо появлялся при обращении к
🧠 Истина оказалась прозаичнее
Если посмотреть на размер при создании и удалении отображения:
Конструктор:
Тут размер буфера увеличивается на
Деструктор / close:
В
Итог: выход за границы отображённой области, повреждение служебных структур, падение в самом неожиданном месте.
💡 Уроки
1. Двойное смещение — классика. Легко запутаться, когда константа применяется в разных местах. Лучшим решением было бы реализовать функцию возвращающую размер и использовать константу в одном месте.
2. Ошибки работы с памятью маскируются — проблемы могут возникнуть практически в произвольном месте кода не связанном с реальной ошибкой. Поэтому такие баги - одни из самых коварных.
3. Address Sanitizer (ASan) — лучший друг 🛠️. Если бы я сразу запустил бинарник с ASan, он скорее всего указал на некорректный размер в
Берегите память, коллеги, и пусть ваши
#Adept #C++ #DataLoader #Segfault #MemoryManagement #AddressSanitizer
Рассказываю, как я наступил на грабли с разделяемой памятью в многопроцессном
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
- ❤ 4
- 👌 1
