Community
Participate
Working Groups
Created attachment 262686 [details] gdb-log.txt It would appear that Eclipse CDT DSF GDB framework encounters an error condition from which it does not recover while debugging. I've experienced this both debugging native applications and also while hardware debugging over JTAG with an arm cross toolchain / gdb. In the former case, debugging was virtually impossible at certain points in the code where this would happen (reproducible: always), and I had to resort to test-driven-design via Google Test Framework. I still encounter the same issue when debugging. In the latter case, it made debugging virtually impossible without the use of a serial port for spitting out debug messages. In both cases, my build machine is x86_64, Intel Core i5, Mac OS X (El Capitan), 10.11.5. My version of GDB is contained within the attachment called gdb-log.txt, which is just copied from the view in Eclipse. Should be about 7.7, iirc. My exact version for all CDT components is 8.8.1.201602051005 . My Eclipse version is Version: Mars.2 Release (4.5.2) Build id: 20160218-0600 My additional observations are as follows: I can use the gdb console to continue to communicate with GDB after this happens; e.g. I can type help, or 'print <var>'. So it would appear that the process is still debuggable and that GDB is still functioning correctly. Indeed, if I switch to gdb via the CLI, I do not encounter this issue whatsoever. What I *believe* is happening, is that Eclipse queries GDB for data (i.e. register values, stack trace, thread status?) immediately after a breakpoint is hit. That data is not yet available from GDB, for some reason or another, and GDB responds with an error that says "Can not fetch data now". Eclipse CDT DSF for GDB does not know what do do if this situation occurs, and "gives up", which results in the Variables view and the Debug view to "hang" (i.e. become unresponsive). My only suggestion right now would be to retry fetching data a few times, and prolong the "giving up" until after some matter of time has passed; e.g. 10 seconds. Chances are the data would become available well within that time limit while debugging a "fast" platform, and most likely within that time limit while debugging a "slow" platform.
Created attachment 262687 [details] eclipse.stdout.and.stderr.txt
I also thought that this bug sounded similar to #213508, since I have also experienced something similar when the stack is smashed while hardware debugging embedded applications.
It looks as though this has been reported elsewhere too. https://github.com/RustDT/RustDT/issues/44
(In reply to Christopher Friedt from comment #4) > It looks as though this has been reported elsewhere too. > > https://github.com/RustDT/RustDT/issues/44 Hi, The example above is using the rust language, would you be able to provide a simple c/c++ program with the steps to reproduce it ? I am not able to reproduce this one, although my work station is in Ubuntu.
