Doesn't support threads (async mode) #11

Closed
exclipy opened this Issue Feb 3, 2012 · 8 comments

Projects

None yet

2 participants

@exclipy

Here's some sample code I tried it with:

#include <boost/thread.hpp>

void f()
{
    int x = 1;
    int y = x;
    std::cout << x << y << std::endl;
}

int main()
{
    int a = 2;
    int b = a;
    boost::thread t(&f);
    t.join();
    std::cout << a << b << std::endl;
}

Putting a breakpoint in f() doesn't work (it seems to pause the program, but there's no visual feedback and subsequent commands don't work). Putting a breakpoint in the last two lines of main() also don't work. Stepping through from the start of main(), the feedback/controls are also lost when the thread starts.

@quarnster
Owner

Yes, multithreading isn't working yet. Don't know when I'll get to it, it's currently not high on my priority list. Pull requests to make this work are more than welcome.

@quarnster
Owner

@exclipy, Actually, this example worked fine for me on OSX with gdb 6.3.50-20050815.

Which OS and what version of gdb are you using?

Would you mind providing the GDB Session output?

Is there anything printed in the console?

Thanks

@quarnster
Owner

Ok, I've been able to reproduce on Linux GDB 7.2.

Debugging threads works if I delete the line:

run_cmd("-gdb-set non-stop on")

However, with that deleted if I have some code like:

int i = 1;
while (i)
{
    sleep(1);
}

then I can't set a breakpoint inside of the while loop once the program is running. Sending a sigint from python didn't seem to help. If anyone have any ideas how to fix this I'm all ears.

@quarnster
Owner

Well, my X session on my ubuntu 11.10 x64 installation just restarts (why???) when I try to insert a breakpoint in the above example when non-stop mode isn't set to on, so I'm unlikely to spend more time investigating this. Community help would be appreciated.

@exclipy

GDB 6.3 on OS X doesn't support non-stop mode, which is why it just seems to work. I've got GDB 7.3 on Ubuntu 11.10 x64 and turning non-stop mode off as you suggested makes it work, and as you described, and setting a breakpoint while the thread is running does kill Sublime. My X didn't die in the process though.

If I keep non-stop on, here are the last few lines:

=thread-created,id="2",group-id="i1"
~"[New Thread 0x7ffff781f700 (LWP 4282)]\n"
*running,thread-id="2"
*stopped,reason="breakpoint-hit",disp="keep",bkptno="1",frame={addr="0x0000000000400650",func="f",args=[{name="a",value="0x0"}],file="test.c",fullname="/home/distcc/Code/threadtest/test.c",line="6"},thread-id="2",stopped-threads=["2"],core="0"
15-stack-info-frame
15^error,msg="Target is executing."

And typing "thread 2" makes it resume properly. So I think the plugin just needs to read the "thread-id" field and switch to that thread.

@quarnster
Owner

Thanks for the pull request. There's still an issue with stepping though. Set a breakpoint before the thread is created and then keep stepping and you'll see that it won't switch back to thread 1 again.

I also tried setting a breakpoint on the first line in "f" and then on t.join(), the output is

=thread-created,id="2",group-id="i1"
~"[New Thread 0x7ffff6c60700 (LWP 5710)]\n"
*running,thread-id="2"
*stopped,reason="breakpoint-hit",disp="keep",bkptno="3",frame={addr="0x0000000000401c56",func="main",args=[],file="test.cpp",fullname="/home/quarn/test.cpp",line="47"},thread-id="1",stopped-threads=["1"],core="0"
169-thread-select 1
*stopped,reason="breakpoint-hit",disp="keep",bkptno="1",frame={addr="0x0000000000401be3",func="f",args=[],file="test.cpp",fullname="/home/quarn/test.cpp",line="37"},thread-id="2",stopped-threads=["2"],core="1"
170-stack-info-frame
171-thread-select 2
169^done,new-thread-id="1",frame={level="0",addr="0x0000000000401c56",func="main",args=[],file="test.cpp",fullname="/home/quarn/test.cpp",line="47"}
(gdb)
170^done,frame={level="0",addr="0x0000000000401c56",func="main",file="test.cpp",fullname="/home/quarn/test.cpp",line="47"}
(gdb)
171^done,new-thread-id="2",frame={level="0",addr="0x0000000000401be3",func="f",args=[],file="test.cpp",fullname="/home/quarn/test.cpp",line="37"}
(gdb)

So both threads are stopped but since 1 is stopped before 2 it doesn't switch back to 1 again. I think a new "threads" view is needed to let the user switch threads manually and gdb_run_status needs to be per thread.

Or getting "non-stop off" to work :)

@quarnster quarnster added a commit that referenced this issue Mar 18, 2012
@quarnster Issue #11, added a threads view.
There's still some issue on Linux with async mode though, but
jumping between threads seems to be working fine on OSX and
Android from my testing.
fda571e
@quarnster
Owner

There's now a threads view implemented, but there are still issues with async mode.

@quarnster
Owner

Closing issue as there's no pending action from my side. Pull requests fixing whatever needs to be fixed would be appreciated.

@quarnster quarnster closed this Nov 19, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment