| Failed to execute MI command [message #683459] |
Mon, 13 June 2011 15:47  |
Eclipse User |
|
|
|
I'm running Helios SR2 on RHEL6 32b with CDT 7.02, GDB common 7.0, IBM J9 VM 1.5.0.
I'm trying to debug a C++ module across JNI from a JUnit.
1. I launch my "JUnit" debug config and successfully breakpoint immediately after my System.loadLibrary(mysharedlib).
2. I then launch my "C/C++ Attach to Application" debug config, which is defined as:
- Application=Debug/libmysharedlib.so
- Build config=debug
- Debugger=gdb
- Non-stop mode=off (although this setting makes no difference)
This Attach to Application launches, I then attach it to javaw properly, and I see 13 suspended threads.
3. I then attempt to resume C++ thread #1 (state=suspended: user request) to no avail.
- Entering "info break" from the gdb console correctly shows my breakpoint in the C++ code. Further, I can successfully display code in my C++ module, so I know I have debug info present.
- Entering "c" from the gdb console gives: Warning: Cannot insert breakpoint 1. Error accessing memory address 0x2da6: Input/output error.
4. When I then attempt to resume the JUnit thread, I get the expected "org.eclipse.jdi.TimeoutException: Timeout occurred while waiting for packet 622. occurred resuming thread." as it appears all C++ threads are still suspended.
The workspace/.metadata/.log yields messages like:
!ENTRY org.eclipse.cdt.dsf 4 10005 2011-06-13 12:06:55.727
!MESSAGE Request for monitor: 'RequestMonitor (org.eclipse.cdt.dsf.concurrent.RequestMonitor@68446844): Status ERROR: org.eclipse.cdt.dsf.gdb code=10004 Failed to execute MI command:
-exec-continue
Error message from debugger back end:
Warning:
Cannot insert breakpoint 1.
Error accessing memory address 0x2da6: Input/output error.
java.lang.Exception: Warning:
Cannot insert breakpoint 1.
Error accessing memory address 0x2da6: Input/output error.
' resulted in an error.
!SUBENTRY 1 org.eclipse.cdt.dsf.gdb 4 10004 2011-06-13 12:06:55.727
!MESSAGE Failed to execute MI command:
-exec-continue
Error message from debugger back end:
Warning:
Cannot insert breakpoint 1.
Error accessing memory address 0x2da6: Input/output error.
!STACK 0
java.lang.Exception: Warning:
Cannot insert breakpoint 1.
Error accessing memory address 0x2da6: Input/output error.
at org.eclipse.cdt.dsf.mi.service.command.AbstractMIControl$RxThread.processMIOutput(AbstractMIControl.java:824)
at org.eclipse.cdt.dsf.mi.service.command.AbstractMIControl$RxThread.run(AbstractMIControl.java:662)
I have a single Eclipse Java project with a C++ nature.
The Java build stuff is routine with a 1.5-level compliance setting.
The C++ code is:
- Compiled with options: -I/opt/ibm/java2-i386-50/include -I/usr/local/gcc32-i386-linux/i386-linux/include -O0 -g3 -gdwarf-2 -Wall -c -fmessage-length=0
- Linked with options: -L/usr/local/gcc32-i386-linux/i386-linux/lib -shared -Wl,-soname=libmysharedlib.so.0
I'm really stuck. It appears to me that CDT is not properly interfacing with GDB/MI. What can I do here?
Thanks in advance for any help..
Tom
|
|
|
|
|
| Re: Failed to execute MI command [message #683823 is a reply to message #683753] |
Tue, 14 June 2011 09:28  |
| Eclipse User |
|
|
|
> The real issue is that I am unable to resume (F8 or 'c') any of the initially suspended gdb threads when the gdb debug session starts.
> These threads are NOT stopped at any of my breakpoints. Rather, this initial suspension seems mandated by the Eclipse/CDT environment
> as part of "C/C++ Attach to Application" debug config processing.
When attaching to a process, GDB automatically stops all the threads. In the next eclipse release (coming June 22nd), if you choose
non-stop mode, then CDT will tell GDB not to stop all the threads on an attach; but for Helios, GDB does stop them.
> My guess is that resume processing is blocked/precluded because of
> the "Warning: Cannot insert breakpoint 1. Error accessing memory address 0x2da6: Input/output error." condition..but I can not tell.
Yes, this is the problem. GDB needs to insert the breakpoints before continuing the execution, but for some reason it cannot access
the memory. You will need to figure out why. How about removing your breakpoint and then doing the resume? Does that help?
Then try to set you breakpoint again...
You can also try to reproduce this in a GDB session outside of Eclipse to figure out what is going on.
You can see all the GDB commands sent by Eclipse in the 'gdb traces' console. See:
http://wiki.eclipse.org/CDT/User/FAQ#I.27ve_been_asked_for_.27gdb_traces.27.2C_where_can_I_find_them.3F
Marc
|
|
|
Powered by
FUDForum. Page generated in 0.04683 seconds
Home