Recently I've occasionally encountered strange breakpoints in Qt Creator when debugging some simple plain C++ programs.

According Qt Creator, The breakpoint occurs in Disassembler (ntdll!DbgBreakPoint). More precisely, in debugger log:
Qt Code:
  1. Program received signal
  2. SIGTRAP, Trace/breakpoint trap.
  3. [Switching to Thread 4632.0x13e4]
  4. 0x7718000d in ntdll!DbgBreakPoint () from C:\Windows\SysWOW64\ntdll.dll
  5. *stopped,reason="signal-received",signal-name="SIGTRAP",signal-meaning="Trace/breakpoint trap",frame={addr="0x7718000d",func="ntdll!DbgBreakPoint",args=[],from="C:\\Windows\\SysWOW64\\ntdll.dll"},thread-id="2",stopped-threads="all"
  6. NOTE: INFERIOR SPONTANEOUS STOP
  7. Stopped.
  8. State changed from InferiorRunOk(11) to InferiorStopOk(14) [master]
  9. 105importPlainDumpers off
  10. SIGTRAP CONSIDERED HARMLESS. CONTINUING.
  11. Stopped: "signal-received".
  12. =thread-selected,id="2"
  13. Thread 2 selected
  14. ......
  15. Dump of assembler code for function ntdll!DbgBreakPoint:
  16. 0x7718000c <+0>: cc int3
  17. => 0x7718000d <+1>: c3 ret **where the code breaks**
  18. 0x7718000e <+2>: 90 nop
  19. 0x7718000f <+3>: 90 nop
  20. 0x77180010 <+4>: 90 nop
  21. 0x77180011 <+5>: 90 nop
  22. 0x77180012 <+6>: 90 nop
  23. 0x77180013 <+7>: 90 nop
  24. 0x77180014 <+8>: 90 nop
  25. 0x77180015 <+9>: 90 nop
  26. 0x77180016 <+10>: 90 nop
  27. 0x77180017 <+11>: 90 nop
  28. 0x77180018 <+12>: 90 nop
  29. 0x77180019 <+13>: 90 nop
  30. 0x7718001a <+14>: 90 nop
  31. 0x7718001b <+15>: 90 nop
  32. 0x7718001c <+16>: 90 nop
  33. 0x7718001d <+17>: 90 nop
  34. 0x7718001e <+18>: 90 nop
  35. 0x7718001f <+19>: 90 nop
  36. 0x77180020 <+20>: 8b 4c 24 04 mov 0x4(%esp),%ecx
  37. 0x77180024 <+24>: f6 41 04 06 testb $0x6,0x4(%ecx)
  38. 0x77180028 <+28>: 74 05 je 0x7718002f <ntdll!DbgBreakPoint+35>
  39. 0x7718002a <+30>: e8 a1 1d 01 00 call 0x77191dd0 <ntdll!ZwTestAlert>
  40. 0x7718002f <+35>: b8 01 00 00 00 mov $0x1,%eax
  41. 0x77180034 <+40>: c2 10 00 ret $0x10
  42. 0x77180037 <+43>: 90 nop
  43. End of assembler dump.
To copy to clipboard, switch view to plain text mode 

  1. This behavior only occurs occasionally. I've not found a way to reproduce it consistently.
  2. The C++ code is VERY simple. Two entire examples shown below.
  3. This behavior is only observed when debugging the code in Qt Creator (using MinGW 5.3.0 32-bit).
  4. The breakpoint occurs in a 2nd thread, not the one where the main function is. This 2nd thread seems to only exist when debugging the code.
  5. I've tried to reproduce this behavior outside of Qt Creator, such as using gdb directly from cmd, but with no success.
  6. I've read posts/articles on similar problems such as here and here. Both points to heap corruption. However, my example code is SO SIMPLE that I don't see how heap corruption can occur in my code. Or am I missing something extremely basic?
  7. Qt version 5.7.0 (probably irrelevant)
    Qt Creator version 4.1.0
    OS: Windows 7 Pro SP1 64-bit


Any comments / suggestions / solutions welcomed.
Thanks in advance!

Example code 1:
Qt Code:
  1. #include <vector>
  2. #include <iostream>
  3. using namespace std;
  4.  
  5. int main()
  6. {
  7. vector<int> v;
  8. for(long long i=0; i<1000000; i++)
  9. v.push_back(i);
  10. cout << v.size() << endl;
  11. }
To copy to clipboard, switch view to plain text mode 
Example code 2:
Qt Code:
  1. #include <iostream>
  2. #include <fstream>
  3. using namespace std;
  4.  
  5. int main()
  6. {
  7. ofstream f("..\\fio\\a.txt");
  8. if( !f.is_open() ) {
  9. cerr << "failed to open file" << endl;
  10. exit(EXIT_FAILURE);
  11. }
  12. for(int i=0; i<10000; i++)
  13. f << i << endl;
  14. f.close();
  15. }
To copy to clipboard, switch view to plain text mode