Databases
StackOverflow2013
Postsdbo
POQt Creator/GDB - Debugging session ends unexpectedly
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POQt Creator/GDB - Debugging session ends unexpectedly
    primarykey
    data
    text
    <p><strong>1. The symptoms</strong></p> <p>Debugging sessions in Qt Creator terminate unexpectedly, in a random fashion (i.e., sometimes they terminate normally), with one of the following errors:</p> <ul> <li>PC register is not available (the most common error, usually with “Internal error: pc 0×0 in read in psymtab, but not in symtab”)</li> <li>SIGSEV</li> <li>SIGILL</li> </ul> <p>The first sign that this is going to happen is when stepping on a line of my code takes me to an assembler window, into NTDLL (usually, <code>ntdll!LdrFindResource_U+60953</code>).</p> <p>I’m running Qt Creator 2.6.2 with Qt 5.0.1, using QT Creator’s MinGW (32 bit), on Win7 64. I've since tested on another machine with Win732 bit, and the behaviour is the same.</p> <p>Following a response I received on the Qt Forums, Rebuild or Clean + Build don't have any noticeable effect on this issue.</p> <p><strong>2. First analysis</strong></p> <p>Since the first error was the most common, I searched the web for it, which led me to <a href="http://sourceware.org/bugzilla/show_bug.cgi?id=14018" rel="nofollow noreferrer">this</a>. It seemed spot on – there was definitely a SIGTRAP, which led to that error.</p> <p>However, as I double-checked all my saved debugger logs, I found several occasions where that error didn’t happen (although the SIGTRAP was always there).</p> <p><strong>3. The pattern</strong></p> <p>Armed with WinMerge and some patience, I was finally able to perceive a pattern in all the error cases. All the logs (<em>both error and success</em>) had something like this:</p> <pre><code>&gt;=thread-created,id="2",group-id="i1" sThread 2 created </code></pre> <p>which created a 2nd thread, in addition to my app (which was running on thread id=“1”). However, all the success logs had something like this:</p> <pre><code>&gt;=thread-exited,id="2",group-id="i1" sThread 2 in group i1 exited </code></pre> <p>So, I ran a few more more debugging sessions, and checked the running threads when the first breakpoint was hit. On all the error cases, I was getting something like this:</p> <pre><code>&lt;455info threads &gt;&amp;"info threads\n" &gt;~" Id Target Id Frame \n" &gt;~" 2 Thread 7160.0x33ec 0x76f1fd71 in ntdll!RtlFindSetBits () from C:\\Windows\\system32\\ntdll.dll\n" &gt;~"* 1 Thread 7160.0x128c main (argc=1, argv=0xbb30d8) at ..\\Exeample\\main.cpp:10\n" &gt;455^done </code></pre> <p>Using Process Explorer, I could see that this second thread was attached to my executable (even though I don’t create threads, you can see the used code <a href="https://stackoverflow.com/questions/12186963/qt-string-builder-in-for-loop/12187166#12187166">here</a>).</p> <p>Also, all the error cases had a SIGTRAP on that second thread:</p> <pre><code>&gt;~"[Switching to Thread 7160.0x33ec]\n" &gt;*stopped,reason="signal-received",signal-name="SIGTRAP",signal-meaning="Trace/breakpoint trap",frame={addr="0x76f1000d",func="ntdll!LdrFindResource_U",args=[],from="C:\\\\Windows\\\\system32\\\\ntdll.dll"},thread-id="2",stopped-threads="all" dNOTE: INFERIOR SPONTANEOUS STOP </code></pre> <p><strong>4. Double-check GDB</strong></p> <p>To determine if this was a GDB issue, I’ve run several command-line debugging sessions, both with and without “-i mi”. There never was any reference to a 2nd thread, and I never had a debugging session terminate unexpectedly, which is why I believe the cause for this issue could be in Qt Creator.</p> <p><strong>5. Request for help</strong></p> <p>I’ve downloaded Qt Creator’s source, and I’ve looked for clues there, but I didn’t get very far.</p> <p>gdbengine.cpp mentions a “stopper thread”, but the only mention I’ve found is <a href="http://www.qtcentre.org/threads/43833-GDB-Cannot-Remove-Internal-Breakpoint" rel="nofollow noreferrer">here</a>.</p> <p>Anyone has any idea/pointer about what I should check next?</p> <p>Thanks for your time.</p> <h2>EDIT:</h2> <p>I still haven't found the cause for this, but after looking at it with Process Monitor, I've got some more data.</p> <p>The second thread is created to load my app's executable and the DLLs it requires. I've confirmed this second thread is created only when I debug my app from the Qt Creator IDE; if I run it from the IDE (i.e., use "run" instead of "debug"), or if I debug it from the command line (launch gdb from the command line), or if I run it from the command line, this second thread is never created, and the executable + DLL images are loaded by my app's main (and only) thread.</p> <p>On what I called "success cases" above, i.e., when this second thread exits, it exits immediately after loading the last DLL, which is why I believe this second thread is created only for this loading.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PTQuestion
    1. USCommunity
    1. USPCaetano
    plurals
    1. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POQt Creator/GDB - Debugging session ends unexpectedly
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POQt Creator/GDB - Debugging session ends unexpectedly
      1. USDmitry
      1. VTFavorite
    1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload