Boost文件系统：recursive_directory_iterator构造函数会导致SIGTRAPS和调试问题

本文介绍了Boost文件系统：recursive_directory_iterator构造函数会导致SIGTRAPS和调试问题的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述 我想使用由boost :: filesystem提供的recursive_directory_iterator来删除目录。但在构建时，调试器停止并显示消息 Signal Received：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; //此时调试停止，消息 //接收到的信号：SIGTRAP fs :: recursive_directory_iterator dirIter（dir）; for（; dirIter！= endIter; ++ dirIter） { //做某事} } 当我尝试找出Sigtrap来自哪里时，我迷失在boost :: filesystem实现细节的深度。 有没有人有一个想法为什么这些Sigtraps存在或如何激活更重要：有一种方法来摆脱他们 （当然，它们只发生在调试模式，程序在发布模式下工作正常，但我必须能够继续调试） 感谢您的帮助！ 编辑：我使用NetBeans IDE，并且无法访问完整的呼叫堆栈。但这是它接收sigtrap信号时它包含： 01：ntdll！RtlpNtMakeTemporaryKey（） 02：ntdll！RtlpNtMakeTemporaryKey br> 03：ntdll！RtlpNtMakeTemporaryKey（） 04：ntdll！LdrFindEntryForAddress（） 05：地址：[@ 0x003e0000] 06 ：Address：[@ 0x50000061] 07：std :: basic_string，std :: allocator> :: _ Rep :: _S_empty_rep_storage（） 08：Address：[@ 0x003e0000] 09：std :: basic_string，std :: allocator> :: _ Rep :: _ S_empty_rep_storage（） 10：地址：[@ 0x40000060] 11：地址：[@ 0x0022f968] 12：地址：[@ 0x00000000] 解决方案搜索和问我解决了问题。 这个问题（或者答案）给了我一个提示： http://stackoverflow.com/questions/2307621/does-getting-random-sigtrap-signals-in-mingw-gdb-is- a-sign-of-memory-corruption 这似乎是一个尝试访问损坏的内存，这是由使用未初始化的动态库。 通过使用boost :: filesystem和boost :: system库的静态（调试）版本，并激活链接器的-static开关，摆脱问题。 I want to use the recursive_directory_iterator offered by boost::filesystem to delete a directory. But at construction time the debugger stops with the message Signal Received: Sigtrap . I can choose to continue ( have to do it several times because multiple Sigtraps are caught ) and the program will work as expected, but debugging with custum break points doesn't work anymore. The path the "fs::path dir" points to is valid, and I've also tried to use a string like fs::... dirIter( "D:/validPath" ), but the problem stays.#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 } }When I try to find out exactly where the Sigtrap is coming from I get lost in the depths of the boost::filesystem implementation details.Does anyone have an Idea why these Sigtraps exist or how they are activatedand even more important:Is there a way to get rid of them ( Of course they only occur in Debug Mode and the program works fine in Release Mode, but I have to be able to continue Debugging somehow )Thanks for your help!edit:I'm working with the NetBeans IDE and don't have access to the full Call Stack. But this is what it contains when the sigtrap Signal is Received:01: ntdll!RtlpNtMakeTemporaryKey()02: ntdll!RtlpNtMakeTemporaryKey()03: ntdll!RtlpNtMakeTemporaryKey()04: ntdll!LdrFindEntryForAddress()05: Address:[@0x003e0000]06: Address:[@0x50000061]07: std::basic_string, std::allocator>::_Rep::_S_empty_rep_storage()08: Address:[@0x003e0000]09: std::basic_string, std::allocator>::_Rep::_S_empty_rep_storage()10: Address:[@0x40000060]11: Address:[@0x0022f968]12: Address:[@0x00000000] 解决方案 After a lot of searching and asking around I solved the problem.This question (or rather the answer) gave me a hint:http://stackoverflow.com/questions/2307621/does-getting-random-sigtrap-signals-in-mingw-gdb-is-a-sign-of-memory-corruptionIt seems to be a matter of trying to access corrupted memory, which is caused by using an uninitialized dynamic library.By using the static (debug) versions of the boost::filesystem and boost::system library, and activating the -static switch for the linker, one can get rid of the problem. 这篇关于Boost文件系统：recursive_directory_iterator构造函数会导致SIGTRAPS和调试问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！