Boost Filesystem: recursive_directory_iterator constructor causes SIGTRAPS and debug problems

Question

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 activated and 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]

Answer 1

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-corruption

It 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.