Освободятся, так же как и несохраненные данные пользователя пропадут, или вообще любые данные, если в связи с этим похерится какая-нить структура файла до того состояния, что данные нельзя будет никак восстановить. Ну це есть це, это нормально. Есть определенные тулзы, которые могут чем то помочь по ошибкам кучи, но я никогда не использовал их, чтобы советовать.
Тут только расстановка ассертов поможет, причем делать это нужно заранее, а не когда ошибка уже проявилась. И никакой windbg/ollydbg никак не поможет в поиске таких багов.
Ну для начала можно попробовать прогнать статические анализаторы типа CppCheck и PVS-Studio, ты удивишься, сколько они могут находить типичных проколов цешников. Потом, если не помогло, можно поэкспериментировать с дебажной кучей или динамическими анализаторами типа: https://www.teamblue.unicomsi.com/products/purify/ и оными.
Microedition, Rel, pvs студию пробовал, хорошая вещь, но конкретно тот баг не нашла. Там была какая фишка - структура вида NODE { dword x; PNODE next; } или чето такое; это было частью еще одной огромной структуры и т.д. Суть ошибки в том, что память для нового элемента выделялась кaк HeapAlloc(sizeof(PNODE) , т.е. выделялся размер указателя. При этом - на 32 бит все работало супер , вообще никаких ошибок, а вот на 64 бит время от времени софт падал. И неясно было почему, т.к. перезаписывались какие-то другие участки памяти. Вручную нашел ошибку один специалист (с этого форума), потратил много времени и не знаю какие методы, но нашел.
При возникновении исключения можно будет корректно освободить ресурсы. Тот же самый подход как и с goto CleanUp только + еще поддерживаются исключения. Это при завершении процесса, а если продолжить работу тот тут уже может быть все печально. К примеру неразлоченная критическая секция повесит другие потоки запрашивающие доступ навсегда. Это только один пример. Вот как раз языки с безопасной концепцией исключают подобные ошибки. Прелесть плюсов в том что там можно писать в С стиле, а когда нужно можно использовать ООП/шаблоны и т.п. вещи. Как выгода например работа с COM на плюсах проще реализуется.
M0rg0t, > И неясно было почему, т.к. перезаписывались какие-то другие участки памяти. Наверно ты не знаком с отладкой, те не можешь ничего толком отладить. Если есть ошибка, то есть поток последовательность выборки, пересылки данных, которые элементарно находятся в отладчике. Известно место исключения - его причина источник данных и так назад по цепочке. Для решения таких ошибок даже автоматика не нужна(в данном случае было бы то самое deref under ref), тем более системная куча содержит множество механизмов диагностики, стектрейс логгеры в крайнем случае оптимизация может выключаться полностью(pageheap", когда под каждый блок выделяется физическая страница - сделано спецом для поиска таких ошибок с произвольной выборкой на запись, тк рандом запись испортит всю среду менеджера памяти его структуры). Что выше обсуждаете про исключения - это не верное понимание, исключение в сишке нельзя назвать хардверным, это механизм обмена данными. На какое то событие бросается нотифи, не эффективный конечно механизм. Причём обычно это делается через интернал компилера механизм, не затрагивая системный механизм ловушек. Тоесть никакое исключение не возникает, просто доставляется сообщение между частями апп.
Rel, УК не читал, за знание срок не дают. Лишь когда используешь что знаешь заберут. Кстате я на вашем форуме нашёл знакомые мне механизмы, что то по обратным вызовам гуя. https://xss.is/threads/49888/ что интересно сможет ли весь тот ресурс собрать рабочую сборку пусть хоть пригодную к отладке или же просто пройти отладчиком сам механизм без сборки. Судя по коментам там даже не понимают что такое компилер. Это жесть, просто слов нет. Не удивительно что ты выбрал соотв окружение такое же тупое. Но зато там можно барыжить примитив текстами, яшечка тоже это не потерял.
Ну ты довольно много слов сказал, хотя утверждаешь, что их нет. Это что-то из психологии, наверное. Инди, не нужно завидовать. Я понимаю, что ты своего места найти не можешь. Но обвинять людей в том, что какое-то комьюнити их ценит, это полный бред.
Ну-ну, зачем оскорблять? Просто некоторые к сороковнику сохраняют тело 20-летнего, а некоторые - разум
Facepalm.jpg. Ты хоть раз в жизни отслеживал многопоточное приложение? С асинхронной обработкой? Тебе отладчик не поможет в принципе. --- Сообщение объединено, 27 мар 2021 --- Отладчик укажет лишь на место проявления ошибки, а не на место её возникновения. Которое может быть совершенно в другом месте.
тут ещё от кода зависит == можно в коде прописывать метки по доступу к общим ресурсам, тогда вполне сносную корреляцию можно получать для выщимления истинного места сбоя. --- Сообщение объединено, 27 мар 2021 --- молодость невозможно сохранить без разума
Да, можно с точностью до строки кода определить (причем без отладчика). Но это всё будут костыли, не предусмотренные стандартами си/си++, увы. Приходится страдать, тратить время на построение этой отладочной инфраструктуры в коде, вместо решения задач.
Microedition, > Ты хоть раз в жизни отслеживал многопоточное приложение? Отслеживал, все которые были на крэклабе, тоесть всё. Он так разработан(дий), что нужные операции атомарны; никогда небыло проблем с синхроном. > Отладчик укажет лишь на место проявления ошибки Нуби пришёл и тут говорить что я кнопки не знаю какие нажать. Чувак ты сошёл с ума, я архитектуру знаю вдоль и поперёк как всё устроено и отладчик для меня просто развлекуха, в отличие от тебя. Желательно конечно ядерный, в юзер нужно большое терпение. Опыт все дела.. Ты же застрянешь на самом примитиве, не смотря на твои понты.
а без режима логирования никуда == к тому же, этот режим так же помогает оптимазить код + может применяться акь защита от реверса
Причем тут архитектура? Ты пытаешься для отладки косяков (относительно) высокого уровня применить какие-то убогие низкоуровневые возможности убогой архитектуры.
Microedition, > Отлаживал то есть, описка у меня. Не опечатка просто потому что уже иные инструменты давно используются, там отслеживается, а не отлаживается. Юзер отладчик это игрушка, детский инструмент.