Bugzilla – Full Text Bug Listing
| Summary: | Toggle breakpoint suspends program | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Axel Mueller <aegges> | ||||||||||||
| Component: | cdt-debug-dsf-gdb | Assignee: | Marc Khouzam <marc.khouzam> | ||||||||||||
| Status: | RESOLVED NOT_ECLIPSE | QA Contact: | Marc Khouzam <marc.khouzam> | ||||||||||||
| Severity: | normal | ||||||||||||||
| Priority: | P3 | CC: | cdtdoug, marc.khouzam, pawel.1.piech | ||||||||||||
| Version: | 8.0 | ||||||||||||||
| Target Milestone: | --- | ||||||||||||||
| Hardware: | PC | ||||||||||||||
| OS: | Linux | ||||||||||||||
| Whiteboard: | |||||||||||||||
| Attachments: |
|
||||||||||||||
|
Description
Axel Mueller
Created attachment 202655 [details] gdb traces Here is a snapshot of the gdb traces when I set a new breakpoint. There is something wrong with the parameter --thread-group 491,994 15-exec-continue --thread-group i1 491,994 15^error,msg="Cannot execute this command without a live selected thread." Bug #352748 has a similar error in gdb traces. I don't know if it is related. Created attachment 202662 [details]
gdb traces: breakpoint causes no suspend
Here are the gdb traces when setting the breakpoint works flawless.
Marc, could you have a look at this bug? Do you need any further info? This is surely related to the changes of bug 337893. Can you come up with a way to easily reproduce it? Have you tried with GDB 7.3? I fixed a couple of multi-process issues in GDB 7.2... (In reply to comment #0) > I have several single-threaded applications that are debugged with gdb 7.2 in > one session. Most of the time I can set/unset a breakpoint w/o any problems. > However, after upgrading from Helios to Indigo I encounter sometimes problems. I'm confused. There was no support for multi-process in Helios, so how can you be seeing a difference between Helios and Indigo? (In reply to comment #5) >Can you come up with a way to easily reproduce it? Unfortunately not. Even for the application I am working most of the time with this bug does not occur for every breakpoint that I set. I haven't observed any pattern yet. >Have you tried with GDB 7.3? I fixed a couple of multi-process issues in GDB >7.2... I am not sure if I can get gdb 7.3 working for my Linux installation. > I'm confused. There was no support for multi-process in Helios, so how can you > be seeing a difference between Helios and Indigo? Perhaps my description was not clear. I have a server and a client application. Usually I launch the client without debugger (from within Eclipse) and the server application is started with gdb (from within the same Eclipse instance; the two applications are part of one makefile project). I had the same scenario with my Helios installation. But after the upgrade to Indigo this bug started to occur. Can you post the entire gdb traces for the failing case? Created attachment 202982 [details]
gdb traces: breakpoint causes suspend
(In reply to comment #4) > Have you tried with GDB 7.3? I fixed a couple of multi-process issues in GDB > 7.2... I have upgraded to gdb 7.4. However, the bug still occurs. When I have several applications running in a debug session and set or delete a breakpoint then very often all applications get suspended (see my previous comments). Do you need to run in 'all-stop' mode? Things may work better if you select 'non-stop'.
I'm noticing this:
905,531 =thread-created,id="2",group-id="i1"
...
905,533 =thread-exited,id="2",group-id="i1"
==> Thread 2 started and died immediately.
982,862 *stopped,reason="signal-received",signal-name="SIGINT",signal-meaning="Interrupt",frame={addr="0xf7fdf430",func="__kernel_vsyscall",args=[]},thread-id="1",stopped-threads="all",core="2"
982,863 15-break-insert --thread-group i1 -f /home/amueller/sources/HEAD/procitec/src/common/modules/demodlib/IQDemod.cpp:1862
==> You create a breakpoint, so we interrupt the running process to set it.
982,948 15^done,bkpt={number="1",type="breakpoint",...,original-location="/home/amueller/sources/HEAD/procitec/src/common/modules/demodlib/IQDemod.cpp:1862"}
==> bp is set properly. Now we need to resume the process.
982,948 =thread-selected,id="2"
==> what is this? Why is GDB telling us that thread 2 is selected, when thread 2 does not exist? I didn't see any request to select thread 2 in the logs.
982,951 16-exec-continue --thread-group i1
982,951 16^error,msg="Cannot execute this command without a live selected thread."
==> Yeah... thread 2 is invalid.
What happens if you select thread 1 in the debug view and then set the breakpoint? Does it somehow force a thread 1 selection?
(In reply to comment #10) > Do you need to run in 'all-stop' mode? Things may work better if you select > 'non-stop'. No it is worse then. Sometimes a thread is suspended and I cannot resume it. To be precise: the thread is listed as running but the program does nothing anymore. When I try to suspend it I don't get a backtrace. I have to kill the program then. > > I'm noticing this: > 905,531 =thread-created,id="2",group-id="i1" > ... > 905,533 =thread-exited,id="2",group-id="i1" > > ==> Thread 2 started and died immediately. This thread is created by the network communication module. > What happens if you select thread 1 in the debug view and then set the > breakpoint? Does it somehow force a thread 1 selection? Did not help. I'm not sure what else to do now. Without being able to reproduce the problem, it is hard to know where to look. Any chance you can find a way to reproduce, even in some rare cases? Created attachment 214251 [details]
sample project
I finally managed to create a simple project that demonstrates the misbehavior. Start the program with the debugger and then insert a breakpoint in line 21 or 22.
(In reply to comment #13) > Created attachment 214251 [details] > sample project > > I finally managed to create a simple project that demonstrates the misbehavior. > Start the program with the debugger and then insert a breakpoint in line 21 or > 22. Can you give more details on what to do? I'm not seeing the problem the way I try: 1- debug as local app => program stops automatically at line 15 (pthread_create) 2- resume program 3- set a breakpoint at line 21 => the program stops at line 21 (In reply to comment #14) > Can you give more details on what to do? I'm not seeing the problem the way I > try: > > 1- debug as local app => program stops automatically at line 15 > (pthread_create) > 2- resume program > 3- set a breakpoint at line 21 > => the program stops at line 21 1 - debug as local app but do remove breakpoint at main before starting 2 - set breakpoint at line 21 3 - program stops at line 20 and you see the above mentioned errors in gdb traces Note: application was build on Linux with gcc 4.6 (64bit), gdb is v7.4 (In reply to comment #15) Ok, I can see this now. But only with all-stop mode. 1 - debug as local app in all-stop, without stopping at main 2 - set breakpoint at line 22 3 - program stops at whatever line it was executing when we tried to set the breakpoint you see the following errors in the development console 329,049 [MI] 31^done,bkpt={number="12",type="breakpoint",disp="keep",enabled="n",addr="0x08048642",\ func="main(int, char**)",file="../src/hello.cpp",fullname="/home/lmckhou/runtime-TestDSF/hello/src/h\ ello.cpp",line="22",times="0",original-location="/home/lmckhou/runtime-TestDSF/hello/src/hello.cpp:2\ 2"} 329,050 [MI] =thread-selected,id="2" 329,050 [MI] (gdb) 329,073 [MI] 32-exec-continue --thread-group i1 329,074 [MI] 32^error,msg="Cannot execute this command without a live selected thread." 329,081 [MI] (gdb) 329,085 [MI] 33-exec-continue --thread-group i1 329,086 [MI] 33^error,msg="Cannot execute this command without a live selected thread." 329,086 [MI] (gdb) !ENTRY org.eclipse.cdt.dsf 4 10005 2012-04-20 10:32:09.089 !MESSAGE Request for monitor: 'RequestMonitor (org.eclipse.cdt.dsf.mi.service.MIRunControl$9@15bfc0a): Status ERROR: org.eclipse.cdt.dsf code=10004 Sequence "" failed while rolling back. null children=[Status ERROR: org.eclipse.cdt.dsf.gdb code=10004 Failed to execute MI command: -exec-continue Error message from debugger back end: Cannot execute this command without a live selected thread. java.lang.Exception: Cannot execute this command without a live selected thread. Status ERROR: org.eclipse.cdt.dsf.gdb code=10004 Failed to execute MI command: -exec-continue Error message from debugger back end: Cannot execute this command without a live selected thread. java.lang.Exception: Cannot execute this command without a live selected thread.]' resulted in an error. !SUBENTRY 1 org.eclipse.cdt.dsf.gdb 4 10004 2012-04-20 10:32:09.089 !MESSAGE Failed to execute MI command: -exec-continue Error message from debugger back end: Cannot execute this command without a live selected thread. !STACK 0 java.lang.Exception: Cannot execute this command without a live selected thread. at org.eclipse.cdt.dsf.mi.service.command.AbstractMIControl$RxThread.processMIOutput(AbstractMIControl.java:917) at org.eclipse.cdt.dsf.mi.service.command.AbstractMIControl$RxThread.run(AbstractMIControl.java:746) !SUBENTRY 1 org.eclipse.cdt.dsf.gdb 4 10004 2012-04-20 10:32:09.090 !MESSAGE Failed to execute MI command: -exec-continue Error message from debugger back end: Cannot execute this command without a live selected thread. !STACK 0 java.lang.Exception: Cannot execute this command without a live selected thread. at org.eclipse.cdt.dsf.mi.service.command.AbstractMIControl$RxThread.processMIOutput(AbstractMIControl.java:917) at org.eclipse.cdt.dsf.mi.service.command.AbstractMIControl$RxThread.run(AbstractMIControl.java:746) Seems to be a GDB problem. I'll keep digging.
> gdb runtime-TestDSF/hello/Debug/hello
GNU gdb (GDB) 7.4
Reading symbols from /home/lmckhou/runtime-TestDSF/hello/Debug/hello...done.
(gdb) r
Starting program: /home/lmckhou/runtime-TestDSF/hello/Debug/hello
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
[New Thread 0xb7fe5b70 (LWP 3998)]
[Thread 0xb7fe5b70 (LWP 3998) exited]
^C
Program received signal SIGINT, Interrupt.
main (argc=1, argv=0xbffff774) at ../src/hello.cpp:19
19 while(1)
(gdb) interpreter-exec mi "-exec-continue --thread-group i1"
^error,msg="Cannot execute this command without a live selected thread."
Created attachment 214316 [details]
Prototype workaround
Here is a prototype workaround. It is not final as it needs some cleanup (handling of failure cases and more comments).
Axel, are you able to try it with master?
Another important point: this is only an all-stop solution, the way I understand the bug, I don't see how it could happen with non-stop. Axel, can you try non-stop again?
I proposed a fix for GDB on the gdb mailing list: http://sourceware.org/ml/gdb-patches/2012-04/msg00698.html (In reply to comment #18) > Axel, are you able to try it with master? Marc, I am not sure I will be able to test the patch. I am using the application that causes gdb a headache at my workplace. I will try my best. (In reply to comment #19) > I proposed a fix for GDB on the gdb mailing list: > http://sourceware.org/ml/gdb-patches/2012-04/msg00698.html GDB fix has been accepted: http://sourceware.org/ml/gdb-patches/2012-04/msg00778.html Also accepted for GDB 7.4.1 http://sourceware.org/ml/gdb-patches/2012-04/msg00779.html which could actually be release tomorrow, Wednesday the 25th: http://sourceware.org/ml/gdb/2012-04/msg00189.html Axel, what are your thoughts on have a fix in Eclipse for older GDBs? How annoying and how common is this problem? It would be less risky to keep the CDT code as is and rely on GDB 7.4.1. (In reply to comment #21) > GDB fix has been accepted: > http://sourceware.org/ml/gdb-patches/2012-04/msg00778.html Cool. > Axel, what are your thoughts on have a fix in Eclipse for older GDBs? How > annoying and how common is this problem? It would be less risky to keep the > CDT code as is and rely on GDB 7.4.1. For me it would be OK to use gdb 7.4.1 and not to fix Eclipse. The bug is annoying but does not occur regularly (that is why I had problems to get a simple test case). I will leave this bug open until gdb 7.4.1 is released and I have verified that the problem is indeed gone. (In reply to comment #22) > I will leave this bug open until gdb 7.4.1 is released and I have verified that > the problem is indeed gone. Good. Thanks! I installed gdb 7.4.1 and I can confirm that the problem disappears for the sample project as well as for my own application. Therefore I will close this bug. I also tested the non-stop mode. However, here I get another problem. After some time gdb hangs and emits the message "Cannot get thread event message: debugger service failed" This seems to be another bug in gdb http://sourceware.org/bugzilla/show_bug.cgi?id=13869 I also found an older bug entry http://sourceware.org/bugzilla/show_bug.cgi?id=10838 where the same error message was produced. But this one was fixed (I tried the attached test case). |