Re[6]: Крашит в дебрях std при работе с ofstream
От: Sheridan Россия  
Дата: 17.12.18 12:12
Оценка:
Здравствуйте, B0FEE664, Вы писали:


BFE>Метод logger() не является потокобезопасным. Если он вызывается из двух и более ниток, то может быть создано два и более объектов типа CLogger.
Знаю. Там где крашится — поток из которгго пишутся логи — единственный.
Matrix has you...
Re[2]: Крашит в дебрях std при работе с ofstream
От: Sheridan Россия  
Дата: 17.12.18 12:19
Оценка:
Здравствуйте, kov_serg, Вы писали:

_>Здравствуйте, 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
Это деструктор.
40 CBlock::~CBlock()
41 {
42    { do { eing::CSingleTone::instance()->logger()->start() << "[Debg] {" << eing::CSingleTone::instance()->debug_counter++ << "} " << std::string(std::string("Point" " in file " __FILE__ " at line " __LINE__ " in method ") + std::string(__func__));; eing::CSingleTone::instance()->logger()->stop();; } while(false); };
43    if(m_dynamicMesh)
44    {
45        m_dynamicMesh->removeBlock(this);
46        if(m_dynamicMesh->empty())
47        {
48            delete m_dynamicMesh;
49            m_dynamicMesh = nullptr;
50        }
51    }
52    m_worldBlock->removeGraphicsBlock();
53    m_worldBlock = nullptr;
54    { do { eing::CSingleTone::instance()->logger()->start() << "[Debg] {" << eing::CSingleTone::instance()->debug_counter++ << "} " << std::string(std::string("Point" " in file " __FILE__ " at line " __LINE__ " in method ") + std::string(__func__));; eing::CSingleTone::instance()->logger()->stop();; } while(false); };
55 }
Matrix has you...
Re[7]: Крашит в дебрях std при работе с ofstream
От: reversecode google
Дата: 17.12.18 12:30
Оценка:
или надо выкладывать весь проект целиком
либо нужно начать сомневаться во всех своих догмах
начиная с замены синглтона на потоконезависимый
Re[3]: Крашит в дебрях std при работе с ofstream
От: Igore Россия  
Дата: 17.12.18 14:10
Оценка: +1
Здравствуйте, 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
S>Это деструктор.

47        {
48            delete m_dynamicMesh;
49            m_dynamicMesh = nullptr;

Теперь нужен деструктор m_dynamicMesh, и removeBlock(у тебя там случайно delete this не происходит)?
Отредактировано 17.12.2018 14:52 Igore . Предыдущая версия . Еще …
Отредактировано 17.12.2018 14:14 Igore . Предыдущая версия .
Отредактировано 17.12.2018 14:13 Igore . Предыдущая версия .
Re[3]: Крашит в дебрях std при работе с ofstream
От: kov_serg Россия  
Дата: 17.12.18 14:17
Оценка: 8 (1)
Здравствуйте, Sheridan, Вы писали:

S>Здравствуйте, kov_serg, Вы писали:

_>>Здравствуйте, 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
S>Это деструктор.
S>
S>40 CBlock::~CBlock()
S>41 {
S>42    { do { eing::CSingleTone::instance()->logger()->start() << "[Debg] {" << eing::CSingleTone::instance()->debug_counter++ << "} " << std::string(std::string("Point" " in file " __FILE__ " at line " __LINE__ " in method ") + std::string(__func__));; eing::CSingleTone::instance()->logger()->stop();; } while(false); };
S>43    if(m_dynamicMesh)
S>44    {
S>45        m_dynamicMesh->removeBlock(this);
S>46        if(m_dynamicMesh->empty())
S>47        {
S>48            delete m_dynamicMesh;
S>49            m_dynamicMesh = nullptr;
S>50        }
S>51    }
S>52    m_worldBlock->removeGraphicsBlock();
S>53    m_worldBlock = nullptr;
S>54    { do { eing::CSingleTone::instance()->logger()->start() << "[Debg] {" << eing::CSingleTone::instance()->debug_counter++ << "} " << std::string(std::string("Point" " in file " __FILE__ " at line " __LINE__ " in method ") + std::string(__func__));; eing::CSingleTone::instance()->logger()->stop();; } while(false); };
S>55 }
S>

Смущает что в #15 и #16 this одинаковый (0x105d070) т.е. сначала 48: delete m_dynamicMesh; а затем контрольный #41 ~CBlock() -- очень подозрительно, или нумерация строк съехала.
я бы добавил что-то вида
struct CBlock {
...
struct State { int x; State() { x=0; } ~State() { if (x) panic(); x=1; } } state;
...
~CBlock() {
    if (state.x) panic();
...
Re[5]: Крашит в дебрях std при работе с ofstream
От: Igore Россия  
Дата: 17.12.18 14:23
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Не статических. Я создаю и удаляю объект.... Крч.

S>
S>class CLogger
S>{
S>    CLogger &start() { m_mutex.lock(); m_logstream.open(m_filename, std::ofstream::out | std::ofstream::ate | std::ofstream::app); return *this; }
S>};

S>


Добавь проверку что m_logstream.open был успешен.
Отредактировано 17.12.2018 14:31 Igore . Предыдущая версия .
Re: Крашит в дебрях std при работе с ofstream
От: B0FEE664  
Дата: 17.12.18 15:02
Оценка: :)
Здравствуйте, Sheridan, Вы писали:

S>Я предполагал что это краш в другом потоке, но уже дважды всё там переписал — не должно
S>Ну и крашится на вызове логгера из деструктора объекта. При этом оно к объекту самому разрушаемому не обращается

Ещё вариант: у базового объекта нет виртуального деструктора, а у наследника деструктор виртуальный.
И каждый день — без права на ошибку...
Re[7]: Крашит в дебрях std при работе с ofstream
От: nekocoder США  
Дата: 17.12.18 15:43
Оценка: +2
Здравствуйте, Sheridan, Вы писали:

S>Я же точно знаю время жизни своих объектов.

Нет, не знаешь. Поэтому у тебя портится память и ты мучаешься с непонятным крашем.
Re[4]: Крашит в дебрях std при работе с ofstream
От: Sheridan Россия  
Дата: 17.12.18 16:30
Оценка:
Здравствуйте, Igore, Вы писали:

I>[ccode]
I>47        {
I>48            delete m_dynamicMesh;
I>49            m_dynamicMesh = nullptr;
I>

I>Теперь нужен деструктор m_dynamicMesh, и removeBlock(у тебя там случайно delete this не происходит)?

CDynamicMesh::CDynamicMesh(eing::graphic::world::CBlock *parentBlock) :
    m_parentBlock(parentBlock),
    m_dynamicModel(nullptr)
{
    m_vertexBuffer = new Urho3D::VertexBuffer(EING_ST->graphic()->context());
    m_indexBuffer  = new Urho3D::IndexBuffer(EING_ST->graphic()->context());
    m_geometry     = new Urho3D::Geometry(EING_ST->graphic()->context());
    m_vertexBuffer->SetShadowed(true);
    m_indexBuffer->SetShadowed(true);
    m_podElements.Push(Urho3D::VertexElement(Urho3D::TYPE_VECTOR3, Urho3D::SEM_POSITION));
    m_podElements.Push(Urho3D::VertexElement(Urho3D::TYPE_VECTOR3, Urho3D::SEM_NORMAL));
    dynamicModel()->SetNumGeometries(1);
    addBlock(m_parentBlock);
}


CDynamicMesh::~CDynamicMesh()
{
    EING_LOG_DBG_POINT;
    if(m_dynamicModel) { EING_ST->graphic()->physicsWorld()->RemoveCachedGeometry(m_dynamicModel); } // Это urho3d, не смотрел что там происходит
    delete m_vertexBuffer;
    delete m_indexBuffer;
    delete m_geometry;
    m_podElements.Clear();
    if(m_dynamicModel) { delete m_dynamicModel; } // Это urho3d объект, не мой
    EING_LOG_DBG_POINT;
}

void CDynamicMesh::addBlock(eing::graphic::world::CBlock *block)
{
    m_blocks.push_back(block);
    recalculate();
}

void CDynamicMesh::removeBlock(eing::graphic::world::CBlock *block)
{
    m_blocks.remove(block);
    if(block == m_parentBlock)
    {
        m_parentBlock = m_blocks.empty() ? nullptr : m_blocks.front();
    }
    recalculate();
}

void CDynamicMesh::recalculate()
{
    if(m_blocks.size() && m_parentBlock)
    { ... }
}


Вообще я склоняюсь к мысли что это действительно не логгер, а что то не так с умными указателями urho3d
Matrix has you...
Отредактировано 17.12.2018 16:35 Sheridan . Предыдущая версия .
Re[4]: Крашит в дебрях std при работе с ofstream
От: Sheridan Россия  
Дата: 17.12.18 16:31
Оценка:
Здравствуйте, kov_serg, Вы писали:

_>Смущает что в #15 и #16 this одинаковый (0x105d070) т.е. сначала 48: delete m_dynamicMesh; а затем контрольный #41 ~CBlock() -- очень подозрительно, или нумерация строк съехала.

Да, меня тоже это смущает, но я склоняюсь к мысли что дебаггер тут просто показывает место вызова delete в деструкторе.
Matrix has you...
Re[6]: Крашит в дебрях std при работе с ofstream
От: Sheridan Россия  
Дата: 17.12.18 16:32
Оценка:
Здравствуйте, Igore, Вы писали:


I>Добавь проверку что m_logstream.open был успешен.
Проходил через это. Даже вообще по месту новый создавал явно. Не помогает. Всё больше склоняюсь к мысли что не в логгере дело.
Matrix has you...
Re[2]: Крашит в дебрях std при работе с ofstream
От: Sheridan Россия  
Дата: 17.12.18 16:32
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>Ещё вариант: у базового объекта нет виртуального деструктора, а у наследника деструктор виртуальный.
Есть виртуальный, есть...
Matrix has you...
Re[8]: Крашит в дебрях std при работе с ofstream
От: Sheridan Россия  
Дата: 17.12.18 16:35
Оценка: :)
Здравствуйте, nekocoder, Вы писали:

S>>Я же точно знаю время жизни своих объектов.
N>Нет, не знаешь. Поэтому у тебя портится память и ты мучаешься с непонятным крашем.
У меня не портится. А вот за urho3d не ручаюсь. Достаточно посмотреть на реализацию их "умных" указателей, не к ночи они помянуты будут...
Matrix has you...
Re[9]: Крашит в дебрях std при работе с ofstream
От: nekocoder США  
Дата: 17.12.18 16:50
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Достаточно посмотреть на реализацию их "умных" указателей, не к ночи они помянуты будут...

Что не так с их умными указателями?
Re: Крашит в дебрях std при работе с ofstream
От: B0FEE664  
Дата: 17.12.18 17:17
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>#17 0x000000000045c05f in eing_helper::cube::AppCubeHelper::redrawTestCube (this=0x77cee0) at ../../../src/applications/cube_helper/main.cpp:350
S> e = @0xae6100: {_vptr.exception = 0xae61b0}
S>#18 0x000000000045d2af in eing_helper::cube::AppCubeHelper::HandleUpdate (this=0x77cee0, eventType=..., eventData=...) at ../../../src/applications/cube_helper/main.cpp:289

А почему вообще вызываются деструкторы? Кто-то бросил исключение?
И каждый день — без права на ошибку...
Re[5]: Крашит в дебрях std при работе с ofstream
От: kov_serg Россия  
Дата: 17.12.18 18:22
Оценка: 8 (1)
Здравствуйте, Sheridan, Вы писали:

S>Да, меня тоже это смущает, но я склоняюсь к мысли что дебаггер тут просто показывает место вызова delete в деструкторе.
С другой стороны. Ошибка говорит о том что кто-то помял память.
Можно попробывать вызвть проверку целосности памяти в разных местах что бы локализовать момент разрушения.
Re[2]: Крашит в дебрях std при работе с ofstream
От: Sheridan Россия  
Дата: 18.12.18 06:52
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>А почему вообще вызываются деструкторы? Кто-то бросил исключение?
Нет. Просто по событию пришло время удалить объект.
Matrix has you...
Re[9]: Крашит в дебрях std при работе с ofstream
От: AleksandrN Россия  
Дата: 18.12.18 09:16
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Здравствуйте, nekocoder, Вы писали:

S>>>Я же точно знаю время жизни своих объектов.
N>>Нет, не знаешь. Поэтому у тебя портится память и ты мучаешься с непонятным крашем.
S>У меня не портится. А вот за urho3d не ручаюсь. Достаточно посмотреть на реализацию их "умных" указателей, не к ночи они помянуты будут...

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

У тебя не падает при запуске из под валгринда, но падает, когда запускаешь без валгринда. Похоже на неинициализированную переменную или испорченный стек. При сборке в debug и в release программа ведёт себя одинаково? sprintf нигде не используется?
Re[7]: Крашит в дебрях std при работе с ofstream
От: B0FEE664  
Дата: 18.12.18 09:38
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Если конечно std::list в remove не вызывает за каким то хреном delete для хранящихся в ём указателей...

Эээээ..... Чего????
И каждый день — без права на ошибку...
Re[10]: Крашит в дебрях std при работе с ofstream
От: Sheridan Россия  
Дата: 18.12.18 09:38
Оценка:
Здравствуйте, AleksandrN, Вы писали:


AN>Ты ещё не нашёл ошибку, но уверен, что у тебя память не портиться. Откуда такая уверенность? При ошибках работы с памятью упасть может не там, где память испорчена, а совсем в другом месте.
В своих объектах я уверен просто, пока что не могу себе представить ситуацию когда чтото удалится или создастса невовремя.

AN>У тебя не падает при запуске из под валгринда, но падает, когда запускаешь без валгринда. Похоже на неинициализированную переменную или испорченный стек.
Да, похоже на то. Сегодня еще раз поищу-почитаю как в urho объектами рулить можно. В предыдущие итерации ничего не обнаружил хитрого...

AN>При сборке в debug и в release программа ведёт себя одинаково?
Да.

AN>sprintf нигде не используется?
Нет, только std::out
Matrix has you...
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.