Здравствуйте, night beast, Вы писали:
S>>Дело было не в бобине. S>>Похоже, внутри urho3d отсутствуют проверки внутри их "умных" указателей. Причём они, похоже, это монго встроили везде куда могли дотянуться.
NB>проверка чего? того что кто-то самостоятельно удаляет объекты, которые используются?
Они уже не используются. Я их удаляю из сцены методами сцены. И оно потом уже, при очистке объекта крешится, так как вызывает delete на уже очищенной памяти.
S>>Казалось бы — валидный код. Ан нет, нифига подобного. У них почти любой объект — refcounted, в том числе и этот вертексбуффер. В результате валится в ReleaseRef(); внутри urho NB>это валидный код до тех пор пока ты не передал его куда-то.
Нираспарсил. Куда я этот код передавать буду? В git?
S>>Далее, интерфейсы SetVertexBuffer и SetIndexBuffer явно указывают на утечки памяти, если не удалять самостоятельно. Собственно вот поэтому и рулил сам.
NB>они указывают на то, что Geometry этими объектами не владеет.
Ты начинаешь понимать!
Это означает что раз я их использую, то значит должен владеть я, правильно? NB>по хорошему, они должны быть WeakPtr.
По хорошему он должны бы проверять на nullptr при работе с указателями, которыми владеет ктото другой.
S>>И на самом деле я до сих пор сомневаюсь что там нет утечек. NB>если ты самостоятельно следишь за сырыми указателями, то вполне обоснованно сомневаешься.
Ещё раз, следи за пальцами и читай по губам: у меня утечек нет, у меня проблем нет. Единственная возникшая проблема связана с "умными" указателями.
И я не пойму, что тут за экивоки в сторону "шеридан глупый". Ты сам соглашаешься что мой код правильный, ты сам соглашаешься что "Geometry этими объектами не владеет", сам понимаешь что раз не владеет, то значит надо самому владеть, раз используешь. В функцию что передаётся? raw ptr. Какой вывод? Управлять памятью этого объекта самостоятельно. Или нет? Какой уровень телепатии должен быть чтобы догадаться что там нужен "умный" указатель?
PM>Всего 5 дней потребовалось, чтобы найти ошибку, но выводы, похоже, еще не сделаны
6 часов. Времени особо не было посидеть в коде нормально, сидел урывками...
Выводы сделал и они подтверждают то что "умные" указатели — то ещо монго.
Смотри сам: я никогда не использую их, у меня в проектах всё ровно, ничего не течот и так далее.
Стоило только в проект попасть "умному" указателю — так сразу проблемы. НЕт, с этих пор категорически и принципиально они у меня будут только там, где без них совершенно невозможно.
PM>Шеридану спасибо!
Всем тут тоже.
Здравствуйте, Sheridan, Вы писали:
S>Ты имеешь в виду ошибки типа "память кончилась"?
Память, кончилась, юзер что-то не так сделал, да мало ли...
S>Ну явно их надо перехватывать не в каждой из функций программы и вообще желательно повыше и в одном месте. А уж там то можно сделать всё без утечек памяти.
По-моему, ты не совсем понял сценарий ошибки.
class cobject
{
public:
cobject()
: p1(new vertexbuf())
, p2(new vertexbuf()) // <--- Вот здесь летит исключение, объект p1 подвис навеки.
{
}
virtual ~cobject()
{
delete p1;
delete p2;
}
private:
vertexbuf* p1;
vertexbuf* p2;
};
Никакими перехватами, тем более "повыше" эта проблема не решается.
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, Sheridan, Вы писали:
S>Я хз какой доктор какие у вас болезни диагностирует.
Еще никто не добавил, что использование синглтонов в принципе дурной тон и на самом деле есть то самое "я что тут происходит, кому объект может понадобиться и когда он будет удаляццо"?
Здравствуйте, Sheridan, Вы писали:
S>>>Дело было не в бобине. S>>>Похоже, внутри urho3d отсутствуют проверки внутри их "умных" указателей. Причём они, похоже, это монго встроили везде куда могли дотянуться.
NB>>проверка чего? того что кто-то самостоятельно удаляет объекты, которые используются? S>Они уже не используются. Я их удаляю из сцены методами сцены. И оно потом уже, при очистке объекта крешится, так как вызывает delete на уже очищенной памяти.
они используются пока есть хоть один умный указатель, который им владеет.
S>>>Казалось бы — валидный код. Ан нет, нифига подобного. У них почти любой объект — refcounted, в том числе и этот вертексбуффер. В результате валится в ReleaseRef(); внутри urho NB>>это валидный код до тех пор пока ты не передал его куда-то. S>Нираспарсил. Куда я этот код передавать буду? В git?
не код а сырой указатель.
S>>>Далее, интерфейсы SetVertexBuffer и SetIndexBuffer явно указывают на утечки памяти, если не удалять самостоятельно. Собственно вот поэтому и рулил сам.
NB>>они указывают на то, что Geometry этими объектами не владеет. S>Ты начинаешь понимать!
S>Это означает что раз я их использую, то значит должен владеть я, правильно?
это значит, что если ты владеешь указателем, то должен явно выразить свое желание, обернув его в шаред.
NB>>по хорошему, они должны быть WeakPtr. S>По хорошему он должны бы проверять на nullptr при работе с указателями, которыми владеет ктото другой.
проверять на nullptr что?
S>>>И на самом деле я до сих пор сомневаюсь что там нет утечек. NB>>если ты самостоятельно следишь за сырыми указателями, то вполне обоснованно сомневаешься. S>Ещё раз, следи за пальцами и читай по губам: у меня утечек нет, у меня проблем нет. Единственная возникшая проблема связана с "умными" указателями.
читай по губам: у тебя проблемы с пониманием того, как работают умные указатели с интрузивным подсчетом ссылок. других проблем не вижу.
S>И я не пойму, что тут за экивоки в сторону "шеридан глупый". Ты сам соглашаешься что мой код правильный, ты сам соглашаешься что "Geometry этими объектами не владеет", сам понимаешь что раз не владеет, то значит надо самому владеть, раз используешь.
как выяснилось, владеет.
S>В функцию что передаётся? raw ptr. Какой вывод? Управлять памятью этого объекта самостоятельно. Или нет? Какой уровень телепатии должен быть чтобы догадаться что там нужен "умный" указатель?
в функцию передается raw ptr, скорее всего, чтобы избежать лишних инкрементов/декрементов на ровном месте.
телепатии не нужно, просто используй объекты так, как планировали их разработчики, и все будет нормально.
Здравствуйте, rg45, Вы писали:
S>>Ты имеешь в виду ошибки типа "память кончилась"? R>Память, кончилась, юзер что-то не так сделал, да мало ли...
Мало ли, да. Только давай мух отдельно, котлеты отдельно. Если юзер чтото не так сделал, то это одно, а если ресурсы закончились, то редко когда можно чего сделать. Ну, разве что попробовать освободить память, если есть какие кеши...
S>>Ну явно их надо перехватывать не в каждой из функций программы и вообще желательно повыше и в одном месте. А уж там то можно сделать всё без утечек памяти. R>По-моему, ты не совсем понял сценарий ошибки. R>Никакими перехватами, тем более "повыше" эта проблема не решается.
Почему исключение нельзя перехватить в конструкторе? Почему ты придумываешь мне редкие аварии?
Здравствуйте, landerhigh, Вы писали:
L>Еще никто не добавил, что использование синглтонов в принципе дурной тон и на самом деле есть то самое "я что тут происходит, кому объект может понадобиться и когда он будет удаляццо"?
Нет. У меня синглтон как раз по делу. Репозиторий объектов, которые в приложении нужны в единственном экземпляре. Причом глобально приложению.
Можно конечно было и через наследование всеми и каждым некоего CObject сделать с нужными полями, но такое по моему совершенный зашквар.
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, night beast, Вы писали:
NB>>тьфу блин. смотрел Graphics.h, там эти переменные -- сырые указатели. S>Но при этом S>Хотя тут же рядом
и?
S>Что тут можно решить кроме "а, ну если бы им нужен был "умный", то они бы его и попросили, а тут просят raw. Ну будет тебе raw."
объясни мне простую вещь, у них в примерах/документации тоже везде ручные delete используются?
class cobject
{
public:
cobject()
: p1(new vertexbuf())
, p2(new vertexbuf()) // <--- Вот здесь летит исключение, объект p1 подвис навеки.
{
}
virtual ~cobject()
{
delete p1;
delete p2;
}
private:
vertexbuf* p1;
vertexbuf* p2;
};
S>Почему исключение нельзя перехватить в конструкторе? Почему ты придумываешь мне редкие аварии?
Можно. Но!
1. Что ты будешь с этим исключением делать? Как ты определишь, какой из объектов кинул исключение? Они ведь неразличимы. Или ты будешь инициализацию каждого мембера в отдельности обраблять в try- catch?
2. Эту проблему нужно будет решать в КАЖДОМ классе, содережащем более одного указателя. Представь, во что превратится твой код и какое количество ошибок будет плодиться в этом аду.
3. Откуда у тебя уверенность, что эта ситуация редкая? А даже если и редкая, то что — можно игнорировать что ли?
И главное: зачем создавать сложности, когда все эти "но" разрешаются предельно просто:
class cobject
{
public:
cobject()
: p1(new vertexbuf())
, p2(new vertexbuf()) // <--- Вот здесь летит исключение - а нам насрать!
{
}
virtual ~cobject(){}
private:
shared_ptr<vertexbuf> p1;
shared_ptr<vertexbuf> p2;
};
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, night beast, Вы писали:
NB>>>проверка чего? того что кто-то самостоятельно удаляет объекты, которые используются? S>>Они уже не используются. Я их удаляю из сцены методами сцены. И оно потом уже, при очистке объекта крешится, так как вызывает delete на уже очищенной памяти. NB>они используются пока есть хоть один умный указатель, который им владеет.
Они уже не используются. Всё. Нода из сцены удаляется. Удаление как раз в момент между кадрами, когда эти данные никому не нужны.
Владеть указателем может только "умная" обёртка?
S>>>>Казалось бы — валидный код. Ан нет, нифига подобного. У них почти любой объект — refcounted, в том числе и этот вертексбуффер. В результате валится в ReleaseRef(); внутри urho NB>>>это валидный код до тех пор пока ты не передал его куда-то. S>>Нираспарсил. Куда я этот код передавать буду? В git? NB>не код а сырой указатель.
Я владею этим указателем, управляю его жизнью. Почему я не могу его передать кому то еще на время — непонятно.
Почему это нельзя только мне, а можно в urho тоже неясно.
S>>>>Далее, интерфейсы SetVertexBuffer и SetIndexBuffer явно указывают на утечки памяти, если не удалять самостоятельно. Собственно вот поэтому и рулил сам. NB>>>они указывают на то, что Geometry этими объектами не владеет. S>>Это означает что раз я их использую, то значит должен владеть я NB>это значит, что если ты владеешь указателем, то должен явно выразить свое желание, обернув его в шаред.
Нет. Владеть указателем могут не только "умные" обёртки, тебя обманули.
NB>>>по хорошему, они должны быть WeakPtr. S>>По хорошему он должны бы проверять на nullptr при работе с указателями, которыми владеет ктото другой. NB>проверять на nullptr что?
Указатель, который к ним приходит, которым владеет ктото извне. Ваш кэп. не благодарите.
S>>>>И на самом деле я до сих пор сомневаюсь что там нет утечек. NB>>>если ты самостоятельно следишь за сырыми указателями, то вполне обоснованно сомневаешься. S>>Ещё раз, следи за пальцами и читай по губам: у меня утечек нет, у меня проблем нет. Единственная возникшая проблема связана с "умными" указателями. NB>читай по губам: у тебя проблемы с пониманием того, как работают умные указатели с интрузивным подсчетом ссылок. других проблем не вижу.
Я лично вижу что работает это совершенно рукожопно. Баги на ровном месте.
S>>И я не пойму, что тут за экивоки в сторону "шеридан глупый". Ты сам соглашаешься что мой код правильный, ты сам соглашаешься что "Geometry этими объектами не владеет", сам понимаешь что раз не владеет, то значит надо самому владеть, раз используешь. NB>как выяснилось, владеет.
Нихрена не владеет. Эти данные ктото другой в туда поставлять должен, а геометри просто хранит указатель на них.
S>>В функцию что передаётся? raw ptr. Какой вывод? Управлять памятью этого объекта самостоятельно. Или нет? Какой уровень телепатии должен быть чтобы догадаться что там нужен "умный" указатель? NB>в функцию передается raw ptr, скорее всего, чтобы избежать лишних инкрементов/декрементов на ровном месте.
Во, начались гадания. Скорее всего...
Вы уж определитесь со своими "умными" указателями. Они должны быть либо умными, и тогда никаких get raw ptr методов, либо не нужны.
NB>телепатии не нужно, просто используй объекты так, как планировали их разработчики, и все будет нормально.
Глядя на их код хер поймош чего они там планировали.
Здравствуйте, night beast, Вы писали:
S>>Что тут можно решить кроме "а, ну если бы им нужен был "умный", то они бы его и попросили, а тут просят raw. Ну будет тебе raw." NB>объясни мне простую вещь, у них в примерах/документации тоже везде ручные delete используются?
У них там везде явные SharedPtr, причом на ровных местах даже там где не нужны.
Но в метод они явно и недвусмысленно ожидают прилёта raw указателя. Значит этим указателем должен владеть я, выделяя ему память и удаляя потом.
Здравствуйте, rg45, Вы писали:
R>1. Что ты будешь с этим исключением делать? Как ты определишь, какой из объектов кинул исключение? Они ведь неразличимы.
Значит перепишу так, чтобы были различимы, раз уж именно тут надо перехватить и именно в таких условиях.
R>2. Эту проблему нужно будет решать в КАЖДОМ классе, содережащем более одного указателя. Представь, во что превратится твой код и какое количество ошибок будет плодиться в этом аду.
Если ВНЕЗАПНО чтото начинает пригождаться в ЛЮБОМ классе, то явно нужно сделать шаг выше. Или ниже. Чтобы свернуть веер решений до одного.
R>3. Откуда у тебя уверенность, что это "авария" и что она редкая. А даже если и редкая, то что — можно игнорировать что ли?
Оттуда что у меня всё что делает не так юзер — перехватывается совершенно в другом месте. А если в отлаженном коде прилетел exception, то варианта ровно два:
1. Это явная авария, причом такая что скорее всего надо извиниться перед юзером и здохнуть, отправив отчот.
2. Проект еще у разрабов и они как раз чегото пилят рядом.
R>И главное: зачем создавать сложности, когда все эти "но" разрешаются предельно просто:
Потому что "умные" указатели — говённое говно, в чом я лишний раз только что убедился.
Здравствуйте, Sheridan, Вы писали:
S>Владеть указателем может только "умная" обёртка?
начинаешь о чем-то подозревать?
NB>>не код а сырой указатель. S>Я владею этим указателем, управляю его жизнью. Почему я не могу его передать кому то еще на время — непонятно. S> Почему это нельзя только мне, а можно в urho тоже неясно.
может быть потому что эти классы разрабатывали они, а не ты?
NB>>это значит, что если ты владеешь указателем, то должен явно выразить свое желание, обернув его в шаред. S>Нет. Владеть указателем могут не только "умные" обёртки, тебя обманули.
ну нет, так нет. успехов в дальнейших поисках "непонятных крашей".
NB>>>>по хорошему, они должны быть WeakPtr. S>>>По хорошему он должны бы проверять на nullptr при работе с указателями, которыми владеет ктото другой. NB>>проверять на nullptr что? S>Указатель, который к ним приходит, которым владеет ктото извне. Ваш кэп. не благодарите.
скажи мне, кэп, откуда они узнают что ты у себя где-то обнулил этот указатель?
S>>>И я не пойму, что тут за экивоки в сторону "шеридан глупый". Ты сам соглашаешься что мой код правильный, ты сам соглашаешься что "Geometry этими объектами не владеет", сам понимаешь что раз не владеет, то значит надо самому владеть, раз используешь. NB>>как выяснилось, владеет. S>Нихрена не владеет. Эти данные ктото другой в туда поставлять должен, а геометри просто хранит указатель на них.
шаредптр предполагает совместное владение. если там использован шаредптр, то значит владеет, как бы тебе не хотелось обратного.
S>Во, начались гадания. Скорее всего... S>Вы уж определитесь со своими "умными" указателями. Они должны быть либо умными, и тогда никаких get raw ptr методов, либо не нужны.
объясняю.
если есть гарантии, что пока используется raw ptr, есть живые шареды, то использовать их можно. не благодари.
Здравствуйте, Sheridan, Вы писали:
S>>>Что тут можно решить кроме "а, ну если бы им нужен был "умный", то они бы его и попросили, а тут просят raw. Ну будет тебе raw." NB>>объясни мне простую вещь, у них в примерах/документации тоже везде ручные delete используются? S>У них там везде явные SharedPtr, причом на ровных местах даже там где не нужны. S>Но в метод они явно и недвусмысленно ожидают прилёта raw указателя. Значит этим указателем должен владеть я, выделяя ему память и удаляя потом.
то есть в документации показано, как правильно использовать их либу, но ты решил что знаешь лучше, как надо, и теперь жалуешься что что-то не работает?
Здравствуйте, night beast, Вы писали:
S>>Владеть указателем может только "умная" обёртка? NB>начинаешь о чем-то подозревать?
Я не подозреваю, я знаю.
NB>>>не код а сырой указатель. S>>Я владею этим указателем, управляю его жизнью. Почему я не могу его передать кому то еще на время — непонятно. S>> Почему это нельзя только мне, а можно в urho тоже неясно. NB>может быть потому что эти классы разрабатывали они, а не ты?
Софистика.
NB>>>это значит, что если ты владеешь указателем, то должен явно выразить свое желание, обернув его в шаред. S>>Нет. Владеть указателем могут не только "умные" обёртки, тебя обманули. NB>ну нет, так нет. успехов в дальнейших поисках "непонятных крашей".
Когда я не хочу управлять памятью, я беру перл, питон, js и так далее.
NB>>>>>по хорошему, они должны быть WeakPtr. S>>>>По хорошему он должны бы проверять на nullptr при работе с указателями, которыми владеет ктото другой. NB>>>проверять на nullptr что? S>>Указатель, который к ним приходит, которым владеет ктото извне. Ваш кэп. не благодарите. NB>скажи мне, кэп, откуда они узнают что ты у себя где-то обнулил этот указатель?
Проверить на nullptr например?
S>>>>И я не пойму, что тут за экивоки в сторону "шеридан глупый". Ты сам соглашаешься что мой код правильный, ты сам соглашаешься что "Geometry этими объектами не владеет", сам понимаешь что раз не владеет, то значит надо самому владеть, раз используешь. NB>>>как выяснилось, владеет. S>>Нихрена не владеет. Эти данные ктото другой в туда поставлять должен, а геометри просто хранит указатель на них. NB>шаредптр предполагает совместное владение. если там использован шаредптр, то значит владеет, как бы тебе не хотелось обратного.
Моя ошибка в том что я не дочитал сорцы до конца.
S>>Во, начались гадания. Скорее всего... S>>Вы уж определитесь со своими "умными" указателями. Они должны быть либо умными, и тогда никаких get raw ptr методов, либо не нужны. NB>объясняю. NB>если есть гарантии, что пока используется raw ptr, есть живые шареды, то использовать их можно. не благодари.
Я и так гарантировал что пока данные нужны — они есть. И если бы не "умные" указатели — это бы работало.
Здравствуйте, night beast, Вы писали:
S>>>>Что тут можно решить кроме "а, ну если бы им нужен был "умный", то они бы его и попросили, а тут просят raw. Ну будет тебе raw." NB>>>объясни мне простую вещь, у них в примерах/документации тоже везде ручные delete используются? S>>У них там везде явные SharedPtr, причом на ровных местах даже там где не нужны. S>>Но в метод они явно и недвусмысленно ожидают прилёта raw указателя. Значит этим указателем должен владеть я, выделяя ему память и удаляя потом. NB>то есть в документации показано, как правильно использовать их либу, но ты решил что знаешь лучше, как надо, и теперь жалуешься что что-то не работает?
Все примеры в документации не предполагают изменение сцены. Как создали сцену, так её и используют. Ну, иногда добавляют объекты. Но не удаляют. А мне надо еще и удалять.
Здравствуйте, Sheridan, Вы писали:
NB>>>>>>по хорошему, они должны быть WeakPtr. S>>>>>По хорошему он должны бы проверять на nullptr при работе с указателями, которыми владеет ктото другой. NB>>>>проверять на nullptr что? S>>>Указатель, который к ним приходит, которым владеет ктото извне. Ваш кэп. не благодарите. NB>>скажи мне, кэп, откуда они узнают что ты у себя где-то обнулил этот указатель? S>Проверить на nullptr например?
что тут происходит, кому объект может понадобиться и когда он будет удаляццо"?
