Bugzilla – Full Text Bug Listing
| Summary: | [cdi][launch] Attach does not work with MinGW gdb 7.0 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | John Cortell <john.cortell> | ||||||
| Component: | cdt-debug-dsf-gdb | Assignee: | John Cortell <john.cortell> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | Marc Khouzam <marc.khouzam> | ||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | nobody, pawel.1.piech | ||||||
| Version: | 7.0 | Flags: | marc.khouzam:
review+
|
||||||
| Target Milestone: | 7.0 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
This works with CDI, so making this a parity issue. Created attachment 166632 [details]
Fix courtesy of Marc.
Fix courtesy of Marc. Committed to HEAD. Marc, please review :-) OK :-) *** cdt cvs genie on behalf of jcortell *** Bug 311118: Attach does not work with MinGW gdb 7.0 [*] MIRunControlEventProcessor_7_0.java 1.8 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/mi/service/command/MIRunControlEventProcessor_7_0.java?root=Tools_Project&r1=1.7&r2=1.8 |
Created attachment 166573 [details] gdb log Steps to reproduce: 1. Create a simple C project that doesn't just run to completion (give it a long sleep call) 2. Build the project 3. run the executable from a Windows command prompt 4. Create a dsf-gdb attach launch configuration and make sure to specify a 7.0 MinGW gdb 5. Launch the session and pick your program from the list of running processes The debug view populates but it shows the process to be running. It is in fact suspended. You can confirm this by typing 'info threads' in the Eclipse gdb console The problem is that MinGW gdb sends an empty stopped event (see attached gdb log). dsf-gdb doesn't know what to do with it, as the event provides no process or thread context. Search for "Badly formatted event" in MIRunControlEventProcessor_7_0 to see where it gives up on the event. But the target truly is suspended, so we really shouldn't be giving up so easily and throwing the event under the rug. BTW, running an mi gdb session at the command line shows the same exact behavior. It receives an empty stopped event.