Bugzilla – Full Text Bug Listing
| Summary: | threadOSId is not extracted for non-pthread programs | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Marc Khouzam <marc.khouzam> | ||||
| Component: | cdt-debug-dsf-gdb | Assignee: | Marc Khouzam <marc.khouzam> | ||||
| Status: | RESOLVED FIXED | QA Contact: | Marc Khouzam <marc.khouzam> | ||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | cdtdoug, pawel.1.piech, WilliamRSwanson | ||||
| Version: | 8.0 | ||||||
| Target Milestone: | 8.0.2 | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 335027 | ||||||
| Attachments: |
|
||||||
I simply added the line
assertEquals("abc123", MIThread.parseOsId("process abc123"));
to MIThreadTests.testOsIdParsing()
I committed the fix to master and cdt_8_0
Note that this bug only applies to local debugging. Remote debugging (attach or not) have the same -thread-info output for pthread and non-pthread programs. *** cdt git genie on behalf of Marc Khouzam ***
Bug 369168: threadOSId is not extracted for non-pthread programs
[*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=50640df3c04fbcf0c59873e18ddedba40e610c11
*** cdt git genie on behalf of Marc Khouzam ***
Bug 369168: threadOSId is not extracted for non-pthread programs
[*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=03c9a71f0ad446078bd0847199ac6385a8809f74
|
Created attachment 209784 [details] Fix On Linux if a program is not compiled with pthread, it will still have a single thread which corresponds to the process. This thread still has an OSId but we don't extract it well. This is the same concept as a pthread program where the first thread has the same OSId as the process id. The problem is that the syntax of the -thread-info MI command is slightly different when the program is not compiled with pthread. Without pthread: target-id="process 3403" with pthread: target-id="Thread 0xb7fe7b30 (LWP 3416)" This fix should go into cdt_8_0 as well. I still have to update the JUnit test to test this new parsing.