Здравствуйте, rg45, Вы писали:
R>Упс. А утебя реально new и delete вот так по коду исппользуются, не смар-поинтеры? Так может, ты просто где-нидудь дважды удаляешь какой-то объект?
Использование смартпоинтеров считаю признаком плохого тона и отсутствию понимания о времени жизни объектов и проекта вообще. Мол, "мы сами неместные, хрен вас знает что где у всё тут нужно и когда. Поэтому вот есть смартпоинтер, он сам поймет когда удалицца". Но это тема для срача в КСВ, если есть желание — надо дуть туда.
Я же точно знаю время жизни своих объектов.
Дважды — точно нет. Если конечно std::list в remove не вызывает за каким то хреном delete для хранящихся в ём указателей...
Здравствуйте, sgenie, Вы писали:
S>А где в CSingleTone логгер инициализируется в NULL?
В двух местах. Второе — лишнее, но макросу пофигу. В nullptr. При создании CSingleTone и при уничтожении.
Здравствуйте, Sheridan, Вы писали:
S>Использование смартпоинтеров считаю признаком плохого тона и отсутствию понимания о времени жизни объектов и проекта вообще. Мол, "мы сами неместные, хрен вас знает что где у всё тут нужно и когда. Поэтому вот есть смартпоинтер, он сам поймет когда удалицца". Но это тема для срача в КСВ, если есть желание — надо дуть туда. S>Я же точно знаю время жизни своих объектов. S>Дважды — точно нет. Если конечно std::list в remove не вызывает за каким то хреном delete для хранящихся в ём указателей...
Ну, это ты зря. Смартпоинтеры и вообще RAII — это не только и не столько контроль времени жизни, это еще и безопасность с точки зрения исключений, и общее качество структуры кода. Этот устав написан кровью:
Здравствуйте, Sheridan, Вы писали:
S> Использование смартпоинтеров считаю признаком плохого тона и отсутствию понимания о времени жизни объектов и проекта вообще. Мол, "мы сами неместные, хрен вас знает что где у всё тут нужно и когда. Поэтому вот есть смартпоинтер, он сам поймет когда удалицца". Но это тема для срача в КСВ, если есть желание — надо дуть туда. S> Я же точно знаю время жизни своих объектов.
Смелое заявление.
S> Проблемы есть, но не в моём коде.
Очень смелое заявление .
S> А где в CSingleTone логгер инициализируется в NULL? S> В двух местах. Второе — лишнее, но макросу пофигу. В nullptr. При создании CSingleTone и при уничтожении.
Здравствуйте, Sheridan, Вы писали:
S>Накидайте идей что это может быть? Может уже встречалось такое?...
Судя по описанию, причина падения почти наверняка с порядком создания/разрушения глобальных (включая статик) объектов. Например, если где-то используется std::cout/std::cerr/std::cin, то вполне возможно, что их попытались использовать до создания или после разрушения.
Так же падение возможно, если главный поток (нить) не дожидается завершения других нитей.
Здравствуйте, Hobbes, Вы писали:
_>>попробуй заменить строку m_filename на m_filename.c_str() или на std::string(m_filename) H>Чем это может помочь?
Это могло сразу падать в случае проблем с this или this->m_filename
Здравствуйте, Sheridan, Вы писали:
S>Полный стек вызовов, крашится в Thread 1:
...
#15 0x000000000049692e in eing::graphic::world::CBlock::~CBlock (this=0x105d070) at ../../../src/graphic/world/cblock.cpp:48
#16 0x0000000000496c89 in eing::graphic::world::CBlock::~CBlock (this=0x105d070) at ../../../src/graphic/world/cblock.cpp:41
...
S>Накидайте идей что это может быть? Может уже встречалось такое?...
А что твориться в файле cblock.cpp в строках 40-50
Предположу по собственным граблям, что проблема не в недрах std, а в коррупте памяти еще до вызова.
Возможные причины: необнуление указателей в членах класса в конструкторе с последующим удалением.
Пронос мимо памяти по индексу в массиве с последующей попыткой удаления объекта
Удаление одного и того же объекта дважды
кривой #pragma pack
ну и попытка конкурентной записи в лог при отсутствии лока на стрим-это харакири
по симптомам лидирует первый вариант, за него работоспособность в отладочном виде и под всякими valgrid'ами, они любят отдавать в new обнуленную память вместо мусора
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, sgenie, Вы писали:
S>>А где в CSingleTone логгер инициализируется в NULL? S>В двух местах. Второе — лишнее, но макросу пофигу. В nullptr. При создании CSingleTone и при уничтожении.
При каких условиях освобождается память под m_logger и является ли освобождение памяти потокобезопасным? Может ли в твоём коде происходить:
1. поток 1 освободил память m_logger
2. поток 2 попытался что-то записать в лог
3. поток 1 обнулил m_logger.
Здравствуйте, Sheridan, Вы писали:
S>Накидайте идей что это может быть? Может уже встречалось такое?...
Конечно, в 99% проблема коде которая используюет библиотеку. Посмотри внимательно на свой код, выделение/удаление ресурсов и удели внимание многопоточному взаимодействию.
Здравствуйте, Слава, Вы писали:
С>Теперь тебе понятно, почему люди сделали Java и C#, и стали писать на них?
Только проблемы в джава и C# не были решены, а были перенесены в другую плоскость. С>PS: переходи на Rust.
А вот тут попытались решить, кстати.
Здравствуйте, ViTech, Вы писали:
S>> А где в CSingleTone логгер инициализируется в NULL? S>> В двух местах. Второе — лишнее, но макросу пофигу. В nullptr. При создании CSingleTone и при уничтожении.
VT>Хорошо бы показать код инициализации.
Ничего там сверхестественного...
Здравствуйте, AleksandrN, Вы писали:
AN>При каких условиях освобождается память под m_logger и является ли освобождение памяти потокобезопасным? Может ли в твоём коде происходить: AN>1. поток 1 освободил память m_logger AN>2. поток 2 попытался что-то записать в лог AN>3. поток 1 обнулил m_logger.
Нет. Логгер создаётся при старте приложения и удаляется при выходе. Пока приложение работает — логгер априори жив.