как обнаружить течь памяти и падение потока

[qate]

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

[Igors]

..как можно узнать, что память утекает именно изз тех вызовов в другом потоке и что приложение упало изза того потока ?

Наверное "как можно доказать" - и наверное необходимость доказывать уже возникла 
Ищите утилиты для своей платформы. Напр я использую Leaks (Instruments) на OSX и пусть не всегда, но часто он течи находит

[qate]

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

[Igors]

я думаю никак не доказать, т.к. если память утекла через new в общей кучи, то и не узанаю

Утилиты хранят список распределенных блоков и место в коде кто их выделял - доказать вполне возможно

а упаду я вместе с потоком

Если немаскируемое исключение - то да, но с др стороны это хорошо, т.к. отладчик покажет место выброса. А если С++ исключение, то ничего и падать не обязано - отлавливается в том же потоке через try/catch

Больше оптимизма 

[qate]

Утилиты хранят список распределенных блоков и место в коде кто их выделял - доказать вполне возможно

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

Если немаскируемое исключение - то да, но с др стороны это хорошо, т.к. отладчик покажет место выброса. А если С++ исключение, то ничего и падать не обязано - отлавливается в том же потоке через try/catch

да, в отладчике все ясно, а как без него ?

[Igors]

...пробовал valgrind - очень много сообщений не по делу
да и не пойдет данный способ, ...

Ну если заранее настраивать себя на "ничего не выйдет" - зачем тогда вообще начинать? "Умывайте руки" - да и все 

... в реальной работе, например через день текет или падает...

Для падения есть CrashLog - когда я рассказал какая это классная штука на OSX, линухоиды мне сказали что на линухе он тоже (разумеется) есть. Вот у них и спросите. На Вындоуз - мрачно, не знаю

А так основной метод - вести лог(и). Да, кропотливая работа, но ее никто не отменял

[qate]

Ну если заранее настраивать себя на "ничего не выйдет" - зачем тогда вообще начинать? "Умывайте руки" - да и все 

ну это с целью не делать бесцельные вещи )
запуск под valgrind тормозит весь процесс в очень много раз, так делать нельзя

Для падения есть CrashLog - когда я рассказал какая это классная штука на OSX, линухоиды мне сказали что на линухе он тоже (разумеется) есть. Вот у них и спросите. На Вындоуз - мрачно, не знаю
А так основной метод - вести лог(и). Да, кропотливая работа, но ее никто не отменял

немного логи ведутся, но не понимаю как это поможет выявить new без delete ?

[Racheengel]

Для винды.

Попробуйте Google Breakpad и Google TCMalloc. Первый - оффлайн-крэшдампер, второй - менеджер памяти с расширенной диагностикой.

Еще рекомендую время от времени запускать CppCheck и Eclipse Codan - это статистические анализаторы кода, они могут выявлять, например, проблемы типа new a[];... delete a; (т.е. когда надо на самом деле delete[] a).