Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] 'continue' executed via gdb.post_event() breaks run control inside Eclipse

Hi Adrian,

This is an interesting use case. Thanks for posting it. The first step to understand why CDT goes wrong is to examine the MI log in this case. Can you share the MI log? 


On Thu., Apr. 23, 2020, 11:55 Adrian Oltean, <adrian.oltean@xxxxxxx> wrote:

Hi everyone,


I’m currently experiencing some problems with regards to how CDT behaves

in the use case described in detail below. Looks like a 'continue' executed

via GDB's python API (see gdb.post_event(event)) somehow confuses Eclipse.


How to easily reproduce the problem:

1. Use an Ubuntu/Windows host;

2. Install Eclipse C/C++ 2019.12;

3. Create a C 'hello world' app for testing; add an infinite loop in 'main';

4. Build the app;

5. Create a python script (e.g. and paste the following code.

Make sure to properly indent it if it gets messed-up in this email;

import gdb


class CustomEvent(object):

    def __init__(self, command):

        self.command = command


    def __call__(self):

        print("Executing <%s>" % self.command)

        gdb.execute(self.command, False, False)


counter = 0

def suspend_handler(event):

    global counter

    if counter % 2 == 0:


    counter = counter + 1


# This is not part of the suspend_handler...


6. Start local debug; use GDB 8+ in all-stop mode;

7. Run the py script using the Debugger Console - 'source';

8. Resume the app from 'main'

9. Suspend execution - note that a 'continue' will (eventually) be executed

from the script. We have two behaviors, depending on the host OS:

  a. On Linux ('enhanced' console supported), Eclipse ends-up in a weird

state, Debug view showing the app suspended (with empty stack frames) whilst

the actual app is running. Suspend button is now disabled. If I try to resume,

I obviously get an error - 'selected thread is running';

  b. On Windows (no 'enhanced' debugger console support, thus no mi-async,

nor target-sync enabled), suspend operation fails with 'operation timeout'. Things

get really messy if trying other operations afterwards.

10. Repeat steps 8 and 9 if problem not reproduced after the first attempt. Seems

to be more reliable on Linux hosts but consistently failing on Windows;


I'm mentioning the 'enhanced' console support because problems seem to be related

to how app/target is interrupted - '-exec-interrupt' vs. kill(SIGINT).


From my experiments, if I switch to non-stop mode GDB, behavior on Linux does not

change, whereas on Windows I no longer see any issues. But on Windows, my setup

involves an ARM-based target, a custom GDB server and JTAG debugging. On my

Ubuntu 18.04 I simply debug a host Linux app.


Anyone else seeing this? Any hints on how to make CDT properly deal with

'continue' executed from a gdb.post_event()?


Thank you,



cdt-dev mailing list
To unsubscribe from this list, visit

Back to the top