title: What causes a Sigtrap in a Debug Session
body: <p>In my c++ program I'm using a library which will "send?" a Sigtrap on a certain operations when
  I'm debugging it (using gdb as a debugger). I can then choose whether I wish to Continue or Stop the program. If I choose to continue the program works as expected, but setting custom breakpoints after a Sigtrap has been caught causes the debugger/program to crash.</p>
  
  <p>So here are my questions:</p>
  
  <ol>
  <li>What causes such a Sigtrap? Is it a leftover line of code that can be removed, or is it caused by the debugger when he "finds something he doesn't like" ?</li>
  <li>Is a sigtrap, generally speaking, a bad thing, and if so, why does the program run flawlessly when I compile a Release and not a Debug Version?</li>
  <li>What does a Sigtrap indicate?</li>
  </ol>
  
  <p><em>This is a more general approach to a question I posted yesterday</em> <a href="https://stackoverflow.com/questions/3469463/boost-filesystem-recursive-directory-iterator-constructor-causes-sigtraps-and-de">Boost Filesystem: recursive_directory_iterator constructor causes SIGTRAPS and debug problems</a>.<br>
  I think my question was far to specific, and I don't want you to solve my problem but help me (and hopefully others) to understand the background.</p>
  
  <p>Thanks a lot.</p>