Community
Participate
Working Groups
Build Identifier: Build id: 20110615-0604 I'm trying to debug a C++ application which is running on an embedded device using (my own) GDB stub. About every 2nd time when I launch a new debugging session CDT ends up by not showing any threads. I started debugging this issue and finally figured out what the problem is: It's an outdated cache entry of a GDB/MI command. This issue could probably be a bug which is not just related to my GDB stub (and hardware) but may be a generic one. That's why I post my findings here. The details: In my case, sometimes it happens that the very first GDB/MI command issued by CDT is a '-list-thread-groups'. Unfortunately, at that time, GDB does not have any thread groups and returns a '1^done,groups=[{id="i1",type="process"}]'. Obviously, this value get's stored in the GDB/MI command cache. Sometime later, GDB reports a '=thread-group-started,id="i1",pid="1"'. However, this updated information doesn't make it into the cache (why?). Instead, the cache still return the 'empty' thread group information. With my limited knowledge about CDT, it seems to me that a cache-update (or cache flush) needs to be done when a '=thread-group-started' is received, am I wrong? However, I couldn't find such piece of code. Did I miss something? My 'hot fix' is to flush the whole cache whenever a '=thread-group-started' is received (flushCache(null)). This fixes the issue for me. I guess that this patch could be improved by not flushing the whole cache, but only the specific GDB/MI command - but I was not able to figure out what's the best way to do that (at least not within 5 minutes :-)). Maybe someone could point me to such a solution? Finally, it would be great to have this issue fixed in CDT. Btw: I'm using GDB version 7.2 (+ some minor patches). Reproducible: Sometimes Steps to Reproduce: Reproducibility may depend on 3rd party software and hardware... thus I can't provide any instruction on how to reproduce.
Created attachment 199876 [details] patch (hot fix)
Created attachment 199877 [details] GDB command cache traces (good case) The cache returns thread group information that contain a valid pid. The cached MI command was number ^11.
Created attachment 199878 [details] GDB MI commands (good case)
Created attachment 199879 [details] GDB command cache traces (bad case) The cache returns thread group information that contain NO pid. The cached MI command was number ^1.
Created attachment 199880 [details] GDB MI commands (bad case)
Created attachment 199881 [details] Screenshot of the debug view (bad case)
(In reply to comment #0) > The details: In my case, sometimes it happens that the very first GDB/MI > command issued by CDT is a '-list-thread-groups'. Unfortunately, at that time, > GDB does not have any thread groups and returns a > '1^done,groups=[{id="i1",type="process"}]'. Obviously, this value get's stored > in the GDB/MI command cache. Sometime later, GDB reports a > '=thread-group-started,id="i1",pid="1"'. However, this updated information > doesn't make it into the cache (why?). The CommandCache, only stores commands, not events. Event should clear the cache so that the next command can be triggered eventually and be stored in the cache. > Instead, the cache still return the > 'empty' thread group information. With my limited knowledge about CDT, it seems > to me that a cache-update (or cache flush) needs to be done when a > '=thread-group-started' is received, am I wrong? However, I couldn't find such > piece of code. Did I miss something? In MIRunControlEventProcessor_7_0.eventReceived(), when getting '=thread-group-started', we should be sending an MIThreadGroupCreatedEvent. This event is received in GDBProcesses_7_0.eventDispatched(MIThreadGroupCreatedEvent e), which then sends a ContainerStartedDMEvent, which is processed in GDBProcesses_7_0.eventDispatched(IStartedDMEvent e), which clears the cache. Can you check that this code is not being called for you? Are you seeing the MIThreadGroupCreatedEvent?
(In reply to comment #7) > In MIRunControlEventProcessor_7_0.eventReceived(), when getting > '=thread-group-started', we should be sending an MIThreadGroupCreatedEvent. > This event is received in > GDBProcesses_7_0.eventDispatched(MIThreadGroupCreatedEvent e), which then sends > a ContainerStartedDMEvent, which is processed in > GDBProcesses_7_0.eventDispatched(IStartedDMEvent e), which clears the cache. > > Can you check that this code is not being called for you? Are you seeing the > MIThreadGroupCreatedEvent? Thanks for your fast response! No, it's not called - but thanks to your explanation, I was able to easily find the mistake (which was in my code): My class derived from GDBControl (instead of GDBControl_7_2). After I changed to GDBControl_7_2, it behaves exactly as you described it above. I'm very sorry to have disturbed you...
(In reply to comment #8) > I'm very sorry to have disturbed you... No problem. A quick resolution like that is always good news :-)
