Повышение файловой системы: конструктор recursive_directory_iterator вызывает SIGTRAPS и проблемы с отладкой - PullRequest
Новая
       13

Повышение файловой системы: конструктор recursive_directory_iterator вызывает SIGTRAPS и проблемы с отладкой

2 голосов
/ 12 августа 2010

Я хочу использовать recursive_directory_iterator, предлагаемый boost :: filesystem, для удаления каталога.Но во время построения отладчик останавливается с сообщением Полученный сигнал: Sigtrap .Я могу выбрать продолжить (придется делать это несколько раз, потому что перехватывается несколько Sigtraps), и программа будет работать как положено, но отладка с точками останова custum больше не работает.Путь, на который указывает "fs :: path dir", действителен, и я также попытался использовать строку типа fs :: ... dirIter ("D: / validPath") , нопроблема остается. 

#include <boost/filesystem.hpp> 
namespace boost::filesystem = fs;
void recursiveDeleteDir( fs::path dir ) 
 fs::recursive_directory_iterator endIter; 
 //At this point debugging is stopped with the message
 //Signal Received: SIGTRAP
 fs::recursive_directory_iterator dirIter( dir );      
 for(;dirIter != endIter ; ++dirIter) 
 { 
  // do something 
 } 
}

Когда я пытаюсь точно определить, откуда приходит Sigtrap, я теряюсь в глубине деталей реализации boost :: filesystem.

Есть ли у кого-нибудьИдея, почему существуют эти Sigtraps или как они активируются и что еще более важно: есть ли способ избавиться от них

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

Спасибо за вашу помощь!

edit: я работаю с IDE NetBeans и не имею доступа к полному стеку вызовов,Но это то, что он содержит при получении сигнала sigtrap.: ntdll! LdrFindEntryForAddress ()
05: адрес: [@ 0x003e0000]
06: адрес: [@ 0x50000061]
07: std :: basic_string, std :: allocator> :: _ Rep :: _ S_empty_rep_storage ()
08: адрес: [@ 0x003e0000]
09: std :: basic_string, std :: allocator> :: _ Rep :: _ S_empty_rep_storage ()
10: адрес: [@ 0x40000060]
11: Адрес: [@ 0x0022f968]
12: адрес: [@ 0x00000000]

1 Ответ

3 голосов
/ 13 августа 2010

После долгих поисков и расспросов я решил проблему.Этот вопрос (или, скорее, ответ) дал мне подсказку:
Является ли получение случайных сигналов SIGTRAP (в MinGW-gdb) признаком повреждения памяти?вопрос доступа к поврежденной памяти, вызванный использованием неинициализированной динамической библиотеки.

Использование статических (отладочных) версий библиотеки boost :: filesystem и boost :: system и активация -статический переключатель для компоновщика, можно избавиться от проблемы.

...