Bugzilla – Full Text Bug Listing
| Summary: | Debugger UI not conform with debugger status, unusable | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Jens Seidel <jensseidel> | ||||
| Component: | cdt-debug | Assignee: | cdt-debug-inbox <cdt-debug-inbox> | ||||
| Status: | CLOSED DUPLICATE | QA Contact: | Ken Ryall <ken.ryall> | ||||
| Severity: | major | ||||||
| Priority: | P3 | CC: | cdtdoug, marc.khouzam, pawel.1.piech | ||||
| Version: | 8.0 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Created attachment 198645 [details]
gdb traces
> MGS:(k=1) residual:*stopped,reason="end-stepping-range",frame={addr="0x000000000056f524",func="gridops::MG_Solver<gridops::EdgeOperator<double> The *stopped event is preceded by some other printout "(MGS:(k=1)" and Eclipse does not expect this, so it does not see the *stopped event. This sounds like bug 327766. Are you on Windows? (In reply to comment #2) > > MGS:(k=1) residual:*stopped,reason="end-stepping-range",frame={addr="0x000000000056f524",func="gridops::MG_Solver<gridops::EdgeOperator<double> > > The *stopped event is preceded by some other printout "(MGS:(k=1)" and Eclipse > does not expect this, so it does not see the *stopped event. OK, but it's not forbidden that the own programs create some output, is it? I never had problems with this in the past. > This sounds like bug 327766. Indeed, it looks similar. My program has a std::flush near the point where it stops, will try without it so that the output is buffered ... Nevertheless I wonder that the program output and the debugger commands influence each other ... > Are you on Windows? No, Linux only. (In reply to comment #3) > (In reply to comment #2) > > > MGS:(k=1) residual:*stopped,reason="end-stepping-range",frame={addr="0x000000000056f524",func="gridops::MG_Solver<gridops::EdgeOperator<double> > > > > The *stopped event is preceded by some other printout "(MGS:(k=1)" and Eclipse > > does not expect this, so it does not see the *stopped event. > > OK, but it's not forbidden that the own programs create some output, is it? > I never had problems with this in the past. Normally, the program I/O is kept separated from the gdb commands, except on Windows, which is bug 327766 > > Are you on Windows? > > No, Linux only. That is strange, it should never happen on Linux where we keep the program I/O in a different console. In the console view, there is a little blue TV icon where you found the 'gdb traces'. Do you have three consoles for the debug session: 1- gdb traces 2- gdb 3- <your program's I/O> (In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > Are you on Windows? > > > > No, Linux only. > > That is strange, it should never happen on Linux where we keep the program I/O > in a different console. > > In the console view, there is a little blue TV icon where you found the 'gdb > traces'. Do you have three consoles for the debug session: > 1- gdb traces > 2- gdb > 3- <your program's I/O> Yep, I have three consoles. I attached the output of gdb traces to this bug, "MGS:(k=1)residual:*stopped" occurs in <my program's I/O> and the gdb console contains also some of my programs output followed by "warning: Can not parse XML OS data; XML support was disabled at compile time". Two weeks ago I reported Bug #349420 (Cannot create pty), could this be related? I haven't seen this recently. The problem occurs in a chroot Linux session, do I have to mount something such as devpts on /chroot/dev/pts to get ptys? Seems I haven't ... (In reply to comment #5) > Two weeks ago I reported Bug #349420 (Cannot create pty), could this be > related? I haven't seen this recently. Yes, that will cause the problem. We need the pty to separate the output of the program from the one of gdb. When you were using CDI, there was a printout indicating that the PTY was not created. Now that you are using DSF, there is no printout, but I'm guessing we are having the same problem and hitting an exception at StartOrRestartProcessSequence_7_0:287 > The problem occurs in a chroot Linux session, do I have to mount something such > as devpts on /chroot/dev/pts to get ptys? Seems I haven't ... I've never had to deal with the PTY not working before, so I can't be of much help. However, you may get more info from other, now that we know what the problem is. This should be continued in bug 349420 *** This bug has been marked as a duplicate of bug 349420 *** Just for testing I changed from DSF to Standard Create Process Launcher and it fails after starting the debbuging process with Target request failed: Warning\nCannot insert breakpoint 1.\nError accessing memory address 0x845: input output error.\n (that's a dialog, there is no error log) The bahaviour (both methods: DSF and Standard) is reproducable on two different hosts. Both are Gentoo boxes. Jens (In reply to comment #7) > Just for testing I changed from DSF to Standard Create Process Launcher and it > fails after starting the debbuging process with > > Target request failed: Warning\nCannot insert breakpoint 1.\nError accessing > memory address 0x845: input output error.\n This is a GDB error that I've seen a couple of times, but it is elusive. I would try to run a similar session outside of Eclipse using GDB to see if you get the same problem. That would indicate a GDB bug and may help us find a way to work around it. (In reply to comment #8) > (In reply to comment #7) > > Just for testing I changed from DSF to Standard Create Process Launcher and it > > fails after starting the debbuging process with > > > > Target request failed: Warning\nCannot insert breakpoint 1.\nError accessing > > memory address 0x845: input output error.\n > > This is a GDB error that I've seen a couple of times, but it is elusive. > > I would try to run a similar session outside of Eclipse using GDB to see if you > get the same problem. That would indicate a GDB bug and may help us find a way > to work around it. You're right. This was also my idea and indeed, it's a gdb problem: $ gdb Debug/program GNU gdb (Gentoo 7.2 p1) 7.2 ... (gdb) b file.h:923 Note: breakpoint 1 also set at pc 0x845. Note: breakpoint 1 also set at pc 0x845. Note: breakpoint 1 also set at pc 0x845. Breakpoint 1 at 0x845: file /home/jens/src/file.h, line 923. (10 locations) (gdb) run Starting program: /home/jens/Debug/program Warning: Cannot insert breakpoint 1. Error accessing memory address 0x845: Eingabe-/Ausgabefehler. A search gives no solution so far ... (In reply to comment #9) > Warning: > Cannot insert breakpoint 1. > Error accessing memory address 0x845: Eingabe-/Ausgabefehler. > > A search gives no solution so far ... This error happens when ptrace is unable to modify the memory to set the breakpoint. I've seen it happen when the thread was running. Maybe your system has some other limitation? (In reply to comment #10) > (In reply to comment #9) > > > Warning: > > Cannot insert breakpoint 1. > > Error accessing memory address 0x845: Eingabe-/Ausgabefehler. > > > > A search gives no solution so far ... > > This error happens when ptrace is unable to modify the memory to set the > breakpoint. Don't you think that 0x845 is a wrong address? It's very small. > I've seen it happen when the thread was running. Thread, which one? I get this error after starting my program, not before. > Maybe your system has some other limitation? Of what kind? |
Build Identifier: 20110615-0604 Hi, I'm currently not very happy with the debugger, it fails to properly stop on breakpoints and leaves the trace mode automatically. Once I get debugger output on my programs output console the debugger is no longer usable: MGS:(k=1) residual:*stopped,reason="end-stepping-range",frame={addr="0x000000000056f524",func="gridops::MG_Solver<gridops::EdgeOperator<double>, linalg::Vec<double> >::do_recursive",args=[{name="this",value="0x93a620"},{name="k",value="1"},{name="rhs",value="..."},{name="x",value="..."}],file="/home/jens/src/multigrid.h",fullname="/home/jens/src/multigrid.h",line="953"},thread-id="1",stopped-threads="all",core="1" The debugger obviously stopped but the UI thinks differently: The stop and abort buttons are enabled, the resume button is disabled. So what now? This happens e.g. if I step through my program via debugger. It stps on positions where no breakpoints are set and I cannot continue ... Output of gdb console: Same output of my program (not of gdb!) followed by: warning: Can not parse XML OS data; XML support was disabled at compile time Maybe this is related to Bug #349283 or to eclipse.buildId=I20110613-1736 java.version=1.6.0_20 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US Framework arguments: -product org.eclipse.epp.package.linuxtools.product Command-line arguments: -os linux -ws gtk -arch x86_64 -product org.eclipse.epp.package.linuxtools.product Error Mon Jun 27 13:25:43 CEST 2011 Request for monitor: 'RequestMonitor (org.eclipse.cdt.dsf.concurrent.RequestMonitor@4c66eb4b): Status ERROR: org.eclipse.cdt.dsf.gdb code=10004 Interrupt failed. null' resulted in an error. eclipse.buildId=I20110613-1736 java.version=1.6.0_20 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US Framework arguments: -product org.eclipse.epp.package.linuxtools.product Command-line arguments: -os linux -ws gtk -arch x86_64 -product org.eclipse.epp.package.linuxtools.product or Error Mon Jun 27 10:55:45 CEST 2011 Request for monitor: 'RequestMonitor (org.eclipse.cdt.dsf.mi.service.MIRunControl$9@430a5f6b): Status ERROR: org.eclipse.cdt.dsf.gdb code=10001 Context cannot be suspended. null' resulted in an error. Reproducible: Always