Плохо. Надо аккуратнее код писать и поменьше указателей и магии с ними... valgrind тебе в помощь, по идее он умеет такое.

На borland пишу, подскажи, чем ловить там. Встроенный codeguard не ловит. По стеку оставшемуся только видно, что до этого было delete[], которое возможно потерло чужую память.

билдится в дебаг моде? почему нет стек трейса? он быть должен

это видал?

http://man7.org/linux/man-pages/man3/backtrace.3.html

Да в настройках проекта стоят галочки оставлять дебаг инфу. При остановке на acess violtaion в дебаг вкладке стек трейс ничего нету. Почему-то теряет видимо эту инфу. Нужен какой-нибудь внешний инструмент, более продвинутый чем среда разработки видимо.

улететь из кода в данные в плюсах можно только двумя способами(остальные от него производные)

1. вызвать функцию по мусорному указателю на функцию
2. попортить виртуальную таблицу класса и вызвать вирт. функцию

ну плюс чудачества со встроенным асмом.

Сами в коде по указателю другую функцию не вызываем, но в коде есть активное использование memset, memcpy, полагаем, где-то есть выход за пределы памяти.

трейсить стек в линухе можно ручками, я сцылку дал. я у себя трейсы делаю именно так, если вывалился интеррапт, и надо сделать красиво.

А как на офтопике это сделать ?

а… значит мемсетами своими улетели за границу сегмента данных, или стек попортили. смотри карту памяти, кто там лежит за сегментом данных. и какие переменные или там близко к концу. вот если их расписывали - могли вылезьти за конец сегмента. смотри где стек, куда растет. если стек растет в сторону меньших адресов, то расписывание стека в большую сторону затирает адрес возврата и возврат происходит по мусорному адресу. это кстати еще один способ улететь черти куда.

А как на офтопике это сделать ?

с офтопиком не работал лет 10. но принципы те же. вот думаю, стек вы там расписали.

то до этого было delete[],

a new у этого delete[] было new[]?

Да все new[] убираем через delete[], не через free, если ты про это.

ну если интерапт рельно по исполнению в секции данных, а функпоинтеров нет, то похоже на расписывание стека и затирание адреса возврата. потому что больше неоткуда вроде. причем обломится сразу, то есть виновата функция что вызывалась последней. ей расписали фрейм и возврат из нее сразу рухнул.

затем. вруби все возможные варнинги(не помню какие они там у борланда есть и рантаймовые проверки, типа выхода за границу массива, проверку стека, если есть такое и прочее, это все в дебаг моде). убери все сомнительные места в коде, что вызывают варнинги, и пускай

«следовательно»(есть вероятность крайне больше нуля) трётся именно место откуда(либо чем) дебагер инфу колектит

а сырцы/код ваще ваш али исследуется?

от ответа на вопрос зависит ошибка это или …. https://en.wikipedia.org/wiki/Antoine_Jacques_Claude_Joseph,_comte_Boulay_de_la_Meurthe

3. Затереть адрес возврата на стеке.

3. Затереть адрес возврата на стеке.

написал это двумя постами выше

На borland пишу, подскажи, чем ловить там. Встроенный codeguard не ловит. По стеку оставшемуся только видно, что до этого было delete[], которое возможно потерло чужую память

Открывать окно дизасма и вручную проходить по стэку. В VS есть фича отображения неочищенных стэков, которое иногда помогает, а борлендовские поделия последних лет печалят больше и больше.

улететь из кода в данные в плюсах можно только двумя способами(остальные от него производные)

Можно просто затереть какие-либо данные /например за пределами массива, …/.
И тогда происходят - «чудеса».

Кошки  - гавкают.
Собаки - мяукают.
...

Владимир

Если стек навернулся уже, трейса не будет.

Вообще valgrind это внешняя штука (но только для linux-ов, маков, андроида и есть неофициальные порты на другие unix-like системы), но если у тебя windows only код, то тогда можешь попробовать статистическим анализатором по коду пробежаться. Оно, конечно не для этого, но какое-то говно найдёт скорее всего, если повезёт то и твоё. cppcheck как опенсорсный вариант.

но если у тебя windows only код,

https://docs.microsoft.com/en-us/windows/win32/debug/debugging-functions

Владимир

https://docs.microsoft.com/en-us/windows/win32/debug/debugging-functions

Целостность stack можно проверить, …

Владимир

попортить виртуальную таблицу класса

А что, их не в read-only секции складывают? Странно, если так. Впрочем, всегда можно попортить указатель на vtable.

Если проверять, то не этим.

Вообще-то, для офтопика лучше бы WinDbg. Идёт в составе офтопного SDK и, по сути, рекомендованное M$ средство отладки. Пример разборок со стеком – https://www.codeproject.com/Articles/6470/Debug-Tutorial-Part-2-The-Stack

Как там борманд живёт, да ещё и под офтопиком, я сейчас уже давно без понятия (всерьёз считал что борманд уже сдох давно и его закопали). Но, как выясняется, эта стюардесса отличается крайне неуёмным нравом… =)))

Думаю, вот… А нет ли здесь какой пропаганды виндов? =))) Не тот же сайт, не?

https://www.codeproject.com/search.aspx?q=Debug+Tutorial+Part+&doctypeid=1%3b2%3b3%3b13

Владимир

LLVM Address Sanitizer

А как на офтопике это сделать ?

http://drmemory.org/

На borland пишу

Я бы начал с того, что убрал бы borland.

И что дальше? Я в курсе что приведённая мною ссылка, это только одна часть. Но у ТС проблема со стеком, я ему именно эту ссылку и привёл, наивно полагая что по кодепроджекту, если ему нужно, то он остальное нароет сам.

И да. Всё таки WinDbg здесь более «к лицу», чем альтернативы.

Плюсую. Неистово плюсую. =)))

Я бы начал с того, что убрал бы borland.

Да. С этого и следовало бы начать.

На офтопике есть аналог valgrind, DrMemory. Но с ним больше мороки. Если valgrind лопает любую сборку программы, то этому подавай с отладочными символами.

Логи и тесты - наше всё. Нет их? ССЗБ.

Логи и тесты - наше всё. Нет их? ССЗБ.

Хороший совет.
Без логов это как - «телега без кобылы».

Владимир

Бесполезны в данном случае

Ну и +1 address sanitizer

Убеждай себя дальше и пердолься в отладчике как ТС.

+2 Адрес Ассенизатор

Но если ты всё-таки ССЗБ - то отладчиком конечно тоже можно…

Например, если падает по одному и тому же адресу под отладкой, то можно подумать как поставить условный вотчпоинт на запись в eip указанного адреса. Но без тестов это вполне себе может оказаться дохлым номером.

Я знаю, что логи и тесты помогут локализовать место _проявления_ ошибки с точностью до пары десятков строк исходника, на этом всё. В чём я себя должен убеждать?

Как отловить в с++ прыжок из секции кода в секцию данных ?

Просто используй Rust или вот Bosque - очередной убийца C++ от MS, например, и все у тебя будет хорошо в жизни.

Разорванный Владимир

В том, что дальше глазами ошибка ищется тривиально, тем же написанием более качественных тестов например.

+3 AddressSanitizer

дальше глазами ошибка ищется тривиально

Это когда ошибка в логике или что техническое по мелочи. А у ТС-а жесть с перетёртым стеком. Вот тебе пример даже: логи и тесты показали функцию f(), в которой процесс упал. Но истинная причина в том, что кто-то _выше_ по стэку вызовов перетёр текущий фрейм. Санитайзер скорее всего сразу укажет на проблемную функцию, а чувак с логами и тестами будет обходить весь граф вызовов f() и глазами искать ошибку. И правда тривиально

Не будет у тебя в тестах большого стек трейса, либо ты их неверно готовишь. То что санитайзеры нужны - спору нет, но без тестов они чуть менее нужны как ни крути.

Не будет у тебя в тестах большого стек трейса

Большого не будет, будет непонятный - за счёт того что ошибочный код и место проявления ошибки удалены друг от друга более чем на десяток строк(в execution order). Поинт в том, что ub и прочее непотребство намного удобнее ловить санитайзерами. А нужность логов и, тем более, тестов я тоже не отрицаю

windbg[br] !analyze -v

капец сколько мамкиных какеров в теме дали бестолковых советов
но я уже windbg посоветовал /thread

А как прикрутить санитайзер в борланд ?