问题描述
我想使用boost :: filesystem提供的recursive_directory_iterator来删除目录。但在施工时，调试器停止，并显示信号接收到信号：Sigtrap 。我可以选择继续（因为多个Sigtraps被捕获而需要执行几次），并且程序将按预期工作，但是使用custum break点进行调试不再工作。 fs :: path dir指向的路径是有效的，我也尝试使用像 fs :: ... dirIter（D：/ validPath）这样的字符串，但是问题一直存在。
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
}
}
当我尝试找出Sigtrap来自哪里时，我会在boost :: filesystem实现细节的深度中迷失。
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.
有没有人有一个想法为什么这些Sigtraps存在或如何激活
甚至更重要：
有办法摆脱他们
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 )
感谢您的帮助！
编辑：
我正在使用NetBeans IDE并且无法访问完整的Call Stack。但是这是收到sigtrap信号时包含的内容：
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（） br>
03：ntdll！RtlpNtMakeTemporaryKey（）
04：ntdll！LdrFindEntryForAddress（）
05：地址：[@ 0x003e0000]
06 ：地址：[@ 0x50000061]
07：std :: basic_string，std :: allocator> :: _ Rep :: _ S_empty_rep_storage（）
08：地址：[@ 0x003e0000] br>
09：std :: basic_string，std :: allocator> :: _ Rep :: _ S_empty_rep_storage（）
10：地址：[@ 0x40000060]
11：地址：[@ 0x0022f968]
12：地址：[@ 0x00000000]
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:
Does getting random SIGTRAP signals (in MinGW-gdb) is a sign of memory corruption?
似乎是要访问损坏的内存，这是由使用未初始化的动态库引起的。
It seems to be a matter of trying to access corrupted memory, which is caused by using an uninitialized dynamic library.
通过使用static调试）版本的boost :: filesystem和boost ::系统库，并激活链接器的-static开关，可以摆脱这个问题。
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 Filesystem：recursive_directory_iterator构造函数引起SIGTRAPS和调试问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！