Community
Participate
Working Groups
Using 8.4.0.201406271819 gdb 7.7.1 compiled from source Sample code: #include <unistd.h> int main() { while (1) { sleep(5); } return 0; } 1. Run the above program (don't debug) 2. Attach with GDB 3. Make sure gdb console doesn't have the "Show console when standard output changes" enabled same for "Show console when standard output changes". 4. Select the process's console (it has no output). 5. Insert a breakpoint on the sleep() line 6. When the breakpoint hits, the gdb console is shown.
Happens on Windows as well.
Interesting use-case. The reason this happens is that on an attach session, there is no process console as part of that session. Normally, the process output is on the console where that process was started, which, in your case, is also Eclipse. When the breakpoint hits, a stack frame is selected and since the only console this session is aware of is the gdb console, the selection brings that console to the front. So it is not they output that causes it to come to the front but the selection. I believe we have two options: 1- leave it as is, as this is a rare use case 2- don't associate the gdb console with a stack frame/thread/process selection and therefore don't bring it to the front when those elements are selected At first glance I'd be ok with #2. When we select the 'gdb' node, that gdb console would still be shown, and when selecting other nodes, nothing would change. I originally chose to show the gdb console as there was no other console of interest, or so I thought :) All this is done in ConsolePageParticipant#getCurrentProcess() which selects the process for which the console should be shown.
(In reply to Marc Khouzam from comment #2) > When the breakpoint hits, a stack frame is selected and since the only > console this session is aware of is the gdb console, the selection brings > that console to the front. So it is not they output that causes it to come > to the front but the selection. I'm seeing this now but not just when breakpoint hits. It seems that it always happens as long as the selection in the Debug view is anywhere in the subtree of the attach session. When there is output in the GDB console, then it changes. In my case, GDB console gets some thread output: [New Thread 0x7f6d2dedd700 (LWP 5682)] [Thread 0x7f6d2dedd700 (LWP 5682) exited] etc
(In reply to Marc-Andre Laperle from comment #3) > (In reply to Marc Khouzam from comment #2) > > When the breakpoint hits, a stack frame is selected and since the only > > console this session is aware of is the gdb console, the selection brings > > that console to the front. So it is not they output that causes it to come > > to the front but the selection. > > I'm seeing this now but not just when breakpoint hits. It seems that it > always happens as long as the selection in the Debug view is anywhere in the > subtree of the attach session. When there is output in the GDB console, then > it changes. In my case, GDB console gets some thread output: > [New Thread 0x7f6d2dedd700 (LWP 5682)] > [Thread 0x7f6d2dedd700 (LWP 5682) exited] > etc I see the opposite problem too. If I select the inferior in the Debug view, open the GDB console, it switches back by itself to the process console (I assume whenever there is output in the GDB console). This time I did not attach, just Local debug.
Here's an updated test program to help illustrate the issue(s). #include <unistd.h> #include <pthread.h> void* foo(void *) { } int main() { while (1) { sleep(5); pthread_attr_t att; pthread_attr_init(&att); pthread_t thread; pthread_create(&thread, &att, foo, NULL); } return 0; } There are two issues: 1) The fact that the console changes without a context change (selection, breakpoint hit) This is because when there is a new thread created, a DebugContextEvent/ACTIVATED is sent and then the console changes based on the current selection (or GDB console fallback in case of attach). If the selection is the inferior, it changes to the inferior console. To reproduce: 1. Start debugging the test program, let it run 2. Make sure the selection is on the inferior in the Debug view. 3. Open the GDB process console 4. Wait a few seconds (5 sec max) for a thread to be created. The console view should switch to the inferior console. I added a field that keeps track of the last context. We only consider displaying another console if the context changed (cur != last). This fixes this issue. 2) The original problem I described. It changes to GDB console when breakpoint hits (the context changes for real). This is because of the fallback mentioned in comment 2. To reproduce: 1. Run the test program (don't debug) 2. Attach with GDB 3. Select the inferior's console (it has no output). 4. Insert a breakpoint on the sleep() line 5. When the breakpoint hits, the gdb console is shown. I removed both fallbacks to the GDB console. ProcessConsolePageParticipant handles when we select the GDB process in the Debug view correctly. One of the two fallbacks is when the context is not an ILaunch, this is the case when the breakpoint hits and the thread context is selected. I think for sure this should not change to the GDB console. The second fallback is when an ILaunch conext is selected. I removed it as well because it felt strange to go from the thread context after hitting a breakpoint then clicking on the launch context and have it switch to the GDB console. So with those changes: -the console does not change "unexpectedly" to the GDB console when a breakpoint hits, in an attach session -the console does not change unexpectedly to the inferior when a new thread is created -the GDB console is still shown when the GDB process is selected in the Debug view -the inferior console is still shown when the inferior process is selected in the Debug view -the GDB console is still shown first when starting an attach session Marc, did you want to split this into two bugs?
New Gerrit change created: https://git.eclipse.org/r/46011
