Home/ Questions/Q 1004875
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-16T08:12:07+00:00

I want to use the recursive_directory_iterator offered by boost::filesystem to delete a directory. But

  • 0

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]

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    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.

    • 0