Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call.  This is usually a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention.

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

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

Это сообщение отредактировал(а) mrgloom - 5.4.2012, 15:30

сделал clean+rebuild all
теперь пишет
Detected memory leaks! Dumping objects -> 


как можно отловить?

Дамп этих самых ликов тебе в помощь.
Среда, как я понимаю MSVC? Тогда в начале каждого cpp-файла нужно вставить код:

Это поможет сделать дамп ликов более вразумительным: тебя должен интересовать только самый верхний, остальные, как правило, следствие.
В дампе указано место создание и тип объекта.
Но может, ты и сам вспомнишь, где накосячил с памятью. Наиболее вероятные ошибки:
1) циклическая ссылка с умным указателем (т.е. А держит B, B держит A; возможны более длинные рекурсивнче цепочки)
2) невиртуальный деструктор в полиморфном объекте
3) тупое отсутствие delete, если вдруг ты используешь обычные указатели
4) неправильный delete для массива
...

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


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


причем попробовал включить в интеерсующий меня .cpp файл и теперь ругается на 


прочитал тут еще 
http://msdn.microsoft.com/en-us/library/e5...3(v=vs.80).aspx

добавил сей код в stdafx.h


но непонятно на каком месте надо вызывать _CrtDumpMemoryLeaks();


что мне даст анализ дампа памяти? 



например тут из полезной информации только строчка на которой это происходит (на 20 строчке как я понимаю leaktest.cpp(20) )
означает ли это, что реально на 20 строке происходит утечка или эта строчка обозначает что то другое?

да кстати написал #define _CRTDBG_MAP_ALLOC в stdafx.h  и все равно файл и строчку в которой произошли мемори лики не выводит

Это сообщение отредактировал(а) mrgloom - 6.4.2012, 09:30

Это подмена "обычного" new на специальный, который запоминает что, где, когда

Да, такая засада есть: этот "специальный" new конфликтует с другими new с аргументами. Сталкивалась с этим, но не помню, как выкрутилась. 

Это строчка, в которой создан объект, оставшийся висеть. Если там ничего нет, то можно попробовать по содержимому и размеру понять, кто это. 

Лики при остановке отладки в студии - это нормально: там скорее всего terminate работает, который за собой не чистит. А вот завершение по крестику должно быть нормальным. Лики всегда возникают только при завершении, ибо предполагается, что процесс должен освободить все, что занял. В процессе выполнения никто не знает, где утечка, а где нужный в настоящий момент объект.

Добавлено через 7 минут и 17 секунд
С ликами бесполезно бороться механически (т.е. ждать, что кто-то тебе укажет, где ты накосячил). Нужно включать голову по любому и анализировать свой код. Еще можно попробовать расхваливаемый автором анализатор кода ... какое-то Studio (не помню точно название, недавно тема опять была)

ну... и total debugging никто не отменял... логирование, заремливание кусков кода... return true в начале "подозрительных" функций...


http://www.viva64.com/ru/pvs-studio/

Добавлено через 3 минуты
гыыыы. пока искал ссылку

это на заметку Thunderbolt

Да, точно, оно.

Ну, строго говоря, то, что Гугель помнит запрос, вовсе не означает, что есть нужный ответ (т.е. этот самый крак).

мемори лик нашёл путем долгого ручного труда, как работает 

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

и я так и не понял, не существует никаких дополнительных  средств\ методик?
может что порекомендуете почитать?


п.с. pvs studio платный, да и еще я так понимаю выдаёт кучу ненужных\подозрительных предупреждений.

Это бывает, если  в файле, где создается объект, нет нужной вставки (подмены new) - либо забыл, либо не твой код, либо ...

Ошибки с памятью проще не совершать, чем искать. Всегда, когда создаешь объект, думай, сколько он будет жить и где разрушаться. Лучше, чтобы создание и разрушение образовывали "скобки" (как бы замыкали код). Везде где можно, используй умные указатели, но помни о циклических ссылках.
Со временем привыкаешь, и такого рода ошибки становятся очень редкими.

Добавлено через 31 секунду

Это бывает, если  в файле, где создается объект, нет нужной вставки (подмены new) - либо забыл, либо не твой код, либо ...

Ошибки с памятью проще не совершать, чем искать. Всегда, когда создаешь объект, думай, сколько он будет жить и где разрушаться. Лучше, чтобы создание и разрушение образовывали "скобки" (как бы замыкали код). Везде где можно, используй умные указатели, но помни о циклических ссылках.
Со временем привыкаешь, и такого рода ошибки становятся очень редкими.