Community
Participate
Working Groups
1- set the global command timeout to 2 seconds (not too wait too long) 2- debug a local app that has a continuous loop - all-stop mode - don't stop at main => Command timeout will be triggered In all-stop mode, commands sent to GDB when the inferior is running, will not get an answer until the inferior is interrupted. Most of our MI commands are not sent to when the inferior is running thanks to the CommandCache.isTargetAvailable() call. However, not all MI commands use the CommandCache. In this case, we send "-list-thread-groups --available" after the -exec-run that starts the inferior. "-list-thread-groups --available" does not use the CommandCache. Also, I believe it must be sent after -exec-run, so that the process is created before we look for its name (although I haven't looked deep into it). This bug is related to Bug 241403. It could be solved if we go for Bug 304721. It is not yet clear to me what to do in the short term. Of course, the workaround is to disable the timeout if the user hits this case, but I think we should eventually have a solution. Some traces: 467,703 [MI] 29-exec-run --thread-group i1 467,706 [MI] =thread-group-started,id="i1",pid="3702" 467,706 [MI] =thread-created,id="1",group-id="i1" 467,707 [MI] 30-list-thread-groups --available ==> Above command won't get an answer and will timeout. 467,709 [MI] 29^running 467,709 [MI] *running,thread-id="all"
