title: C++ thread not stopping in gdb async mode using user-defined or python command sequence
body: <p>I'm using gdb 7.4.1 on embedded powerpc target to perform some analysis on my multi-threaded C++ program that uses pthreads. My end goal is to script gdb with python to automate some common analysis functions. The problem is that I am finding some discrepancy in behavior when I run commands individually vs. in a gdb user-defined command (or invoking the same commands via python script).</p>
  
  <p>edit: I found <a href="http://sourceware.org/ml/gdb/2009-01/msg00154.html" rel="noreferrer">this</a> reference to a very similar problem on the main gdb mailing list. Although I don't completely follow Pedro's response about the limitation of async mode, I think he's implying that in async mode, the relative timing of user-defined command sequences cannot be trusted. This is what I found empirically.</p>
  
  <p>In both scenarios, I perform the following start-up steps, loading my program, setting its args, and turning on asynchronous and non-stop debugging modes, then running the program in the background:</p>
  
  <pre><code>(gdb) file myprogram
  (gdb) set args --interface=eth0 --try-count=0
  (gdb) set target-async on
  (gdb) set pagination off
  (gdb) set non-stop on
  (gdb) run &amp;
  </code></pre>
  
  <p>At this point, if I manually issue <code>interrupt</code> and then <code>info threads</code> commands, I see the list of all threads running except one that got stopped. Then I can <code>continue &amp;</code> and repeat to my hearts content, it works consistently. When stopped, I can inspect that thread's stack frames and all is well. </p>
  
  <p>However, if instead I put these commands into a user-defined gdb command:</p>
  
  <pre><code>(gdb) define foo
  (gdb) interrupt
  (gdb) info threads
  (gdb) continue &amp;
  (gdb) end
  (gdb) foo
  Cannot execute this command while the selected thread is running.
  </code></pre>
  
  <p>Then the thread list printed by foo indicates no threads were stopped, and so the <code>continue &amp;</code> command returns <code>Cannot execute this command while the selected thread is running.</code>. I thought this was a problem inherent to the asynchronous gdb commanding, so I inserted an absurdly long wait after the interrupt command and got the same behavior:</p>
  
  <pre><code>(gdb) define foo
  (gdb) interrupt
  (gdb) shell sleep 5
  (gdb) info threads
  (gdb) continue &amp;
  (gdb) end
  (gdb) foo
  Cannot execute this command while the selected thread is running.
  </code></pre>
  
  <p>With or without the sleep command, I can always issue the manual CLI commands and the threads get stopped correctly. </p>
  
  <p>Similarly, I get the same results sourcing a python script to do the thread perusal:</p>
  
  <pre><code>import gdb, time
  
  gdb.execute("file myprogram")
  gdb.execute("set args --interface=eth0 --try-count=0")
  gdb.execute("set target-async on")
  gdb.execute("set pagination off") 
  gdb.execute("set non-stop on")
  gdb.execute("run &amp;")
  time.sleep(5)
  gdb.execute("interrupt")
  
  # here, I inspect threads via gdb module interface
  # in practice, they're always all running bc the program neven got interrupted
  for thread in gdb.selected_inferior().threads():
      print thread.is_running(),
  
  gdb.execute("continue &amp;")
  </code></pre>
  
  <p>I get the same result even if I specify <code>from_tty=True</code> in the <code>gdb.execute</code> calls. Also, if I use <code>continue -a</code> it suppresses the error string but does not help otherwise bc the interrupt call still doesn't work.</p>
  
  <p>So... is this:</p>
  
  <ul>
  <li>cockpit error? Is there something that I'm omitting or doing incorrectly, given what I'm trying to accomplish? Should this work, or do I have to use GDB/MI to asynchronously "drive" gdb like this?</li>
  <li>a timing problem? Maybe invoking <code>shell sleep</code> (or <code>python time.sleep()</code>) doesn't do what I assume it would, in this context.</li>
  <li>problem with my usage of pthreads? I have assumed that since using manual gdb commands always works correctly this is not the case.</li>
  <li>a gdb problem?</li>
  </ul>
  
  <p>Thanks.</p>