да, но это проблема возникает только при закрытии (X) одного из окон приложения и только в режиме debug, во всех остальных случаях, которые я видел и использовал,ничего подобного и критичного нет.Когда приложение создает окно дополнительное и ты его закрываешь, то приложение падает на строке, которую я писал выше. Ни на access violation ни на что-то подобное он не ругается

Проблема не обязательно именно в этой строке. Но, опять же, без кода это всё - гадание.

А он (отладчик) в "нутро" заходит? Т.е. если дойти до app.exec() и сделать "step in" (не знаю какая клавиша в Вашем IDE), то Вы "ходите" по коду Qt либы? Если нет, то надо "пересобирать", иначе ловить нечего. И собирать в новые папки/мамки  (а не поверх старых)

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

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

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

дебаг сборка без подключенного отладчика тоже падает? (например, если просто из файлового менеджера запустить)

можно еще на другой машине и/или в другой ОС потестить.

Так, отладчик работает и стек падения тоже есть - ну так это хорошо. Отладчик должен показывать код/исходники всех вызовов стека, по крайней мере для дебажных Qt либ. Напр по дабл-клику или контекстному меню - ищите. В крайнем случае поставить break в ассемблере перед падением