dgb + qt + thread = ????

>и как его бороть?

не отлаживать треды дебаггером

ну ты еще скажи, что gdb для подобного не предназначен

если бы в гугле набрали "gdb linux threads" то увидели бы что абсолютное большинство версий gdb имеет массу проблем с тредами.

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

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

если другие - это просто вывод в лог или на консоль отладочной информации - в данном случае это оччччень канительно, не вру, ейбогу. в проекте более 600 классов, множественное наследование и прочее. и гдето там в этой куче течет память, что в конце концов приводит к падению программы. core не создается(почему - хз, c ulimit уже по всякому выкручивал). хотелось просто запустить программу под gdb и после падения просмотреть стек вызовов. чего тут придумать то можно?

>и гдето там в этой куче течет память, что в конце концов приводит к падению программы.

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

>что в конце концов приводит к падению программы.

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

совмещать треды и С++ весчь довольно не тривиальная

все может быть. увы, программа не моя. ее тут два любителя написали под виндой, там все работало. перегнали под линух и вот тут начались чудеса - как оно под виндой жило, одному Гейтцу известо. уже центнер багов отловили и все равно падает. тут в гугле постоянно фраза проскакивает про gdb patch для корректной работы с multi thread приложениями. чтото ничего найти не могу. может, чего не так понял?

>тут в гугле постоянно фраза проскакивает про gdb patch для корректной работы с multi thread приложениями.

это для "старых" gdb. хотя если точно то какие работают без дебвггера - незнаю. проще с коркой разобратся