Community
Participate
Working Groups
CDT 9.0.0.201604211004 !ENTRY org.eclipse.cdt.dsf.gdb 4 5012 2016-05-18 15:39:17.891 !MESSAGE Error in services launch sequence !STACK 1 org.eclipse.core.runtime.CoreException: Unhandled exception when executing Sequence org.eclipse.cdt.dsf.gdb.launching.ServicesLaunchSequence@484051d2, step #1 at org.eclipse.cdt.dsf.concurrent.Sequence.abortExecution(Sequence.java:582) at org.eclipse.cdt.dsf.concurrent.Sequence.executeStep(Sequence.java:469) at org.eclipse.cdt.dsf.concurrent.Sequence.access$2(Sequence.java:373) at org.eclipse.cdt.dsf.concurrent.Sequence$2.handleSuccess(Sequence.java:420) at org.eclipse.cdt.dsf.concurrent.RequestMonitor.handleCompleted(RequestMonitor.java:385) at org.eclipse.cdt.dsf.concurrent.RequestMonitor$2.run(RequestMonitor.java:312) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:295) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.NullPointerException at org.eclipse.cdt.dsf.gdb.service.command.GDBControl.getId(GDBControl.java:274) at org.eclipse.cdt.dsf.gdb.service.command.GDBControl_7_4.createComandControlContext(GDBControl_7_4.java:49) at org.eclipse.cdt.dsf.gdb.service.command.GDBControl.doInitialize(GDBControl.java:256) at org.eclipse.cdt.dsf.gdb.service.command.GDBControl.access$16(GDBControl.java:250) at org.eclipse.cdt.dsf.gdb.service.command.GDBControl$1.handleSuccess(GDBControl.java:245) at org.eclipse.cdt.dsf.concurrent.RequestMonitor.handleCompleted(RequestMonitor.java:385) at org.eclipse.cdt.dsf.concurrent.RequestMonitor$2.run(RequestMonitor.java:312) at org.eclipse.cdt.dsf.concurrent.ImmediateExecutor.execute(ImmediateExecutor.java:63) at org.eclipse.cdt.dsf.concurrent.RequestMonitor.done(RequestMonitor.java:309) at org.eclipse.cdt.dsf.service.AbstractDsfService.initialize(AbstractDsfService.java:93) at org.eclipse.cdt.dsf.gdb.service.command.GDBControl.initialize(GDBControl.java:242) at org.eclipse.cdt.dsf.gdb.launching.ServicesLaunchSequence$2.execute(ServicesLaunchSequence.java:57) at org.eclipse.cdt.dsf.concurrent.Sequence.executeStep(Sequence.java:459) ... 11 more
Here are the errors that preceded the NPE: !ENTRY org.eclipse.cdt.dsf 4 10005 2016-05-18 15:36:45.938 !MESSAGE Request for monitor: 'RequestMonitor (org.eclipse.cdt.dsf.gdb.service.GDBRunControl_7_0_NS$12@6eab055a): Status ERROR: org.eclipse.cdt.dsf code=10001 null children=[Status ERROR: org.eclipse.cdt.dsf.gdb code=10001 Connection is shut down null]' resulted in an error. !SUBENTRY 1 org.eclipse.cdt.dsf.gdb 4 10001 2016-05-18 15:36:45.938 !MESSAGE Connection is shut down !ENTRY com.google.eclipse.cc.ui 4 0 2016-05-18 15:36:45.947 !MESSAGE Error in final launch sequence !STACK 1 org.eclipse.debug.core.DebugException: Error in final launch sequence at org.eclipse.cdt.dsf.gdb.launching.GdbLaunchDelegate.launchDebugSession(GdbLaunchDelegate.java:233) at org.eclipse.cdt.dsf.gdb.launching.GdbLaunchDelegate.launchDebugger(GdbLaunchDelegate.java:101) at org.eclipse.cdt.dsf.gdb.launching.GdbLaunchDelegate.launch(GdbLaunchDelegate.java:90) at com.google.eclipse.cc.ui.launch.binary.GoogleCppLaunchDelegate.launch(GoogleCppLaunchDelegate.java:127) at com.google.eclipse.cc.ui.launch.test.GUnitLaunchDelegate.launch(GUnitLaunchDelegate.java:30) at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:885) at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:739) at org.eclipse.debug.internal.ui.DebugUIPlugin.buildAndLaunch(DebugUIPlugin.java:1039) at org.eclipse.debug.internal.ui.DebugUIPlugin$8.run(DebugUIPlugin.java:1256) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) Caused by: org.eclipse.core.runtime.CoreException: Failed to execute MI command: -exec-run Error message from debugger back end: Warning:\nCannot insert breakpoint 1.\nCannot access memory at address 0x7fffe7fc1190\n at org.eclipse.cdt.dsf.concurrent.Query.get(Query.java:111) at org.eclipse.cdt.dsf.gdb.launching.GdbLaunchDelegate.launchDebugSession(GdbLaunchDelegate.java:228) ... 9 more Caused by: java.lang.Exception: Warning:\nCannot insert breakpoint 1.\nCannot access memory at address 0x7fffe7fc1190\n at org.eclipse.cdt.dsf.mi.service.command.AbstractMIControl$RxThread.processMIOutput(AbstractMIControl.java:940) at org.eclipse.cdt.dsf.mi.service.command.AbstractMIControl$RxThread.run(AbstractMIControl.java:769) !SUBENTRY 1 org.eclipse.cdt.dsf.gdb 4 5012 2016-05-18 15:36:45.947 !MESSAGE Error in final launch sequence !STACK 1 org.eclipse.core.runtime.CoreException: Failed to execute MI command: -exec-run Error message from debugger back end: Warning:\nCannot insert breakpoint 1.\nCannot access memory at address 0x7fffe7fc1190\n at org.eclipse.cdt.dsf.concurrent.Query.get(Query.java:111) at org.eclipse.cdt.dsf.gdb.launching.GdbLaunchDelegate.launchDebugSession(GdbLaunchDelegate.java:228) at org.eclipse.cdt.dsf.gdb.launching.GdbLaunchDelegate.launchDebugger(GdbLaunchDelegate.java:101) at org.eclipse.cdt.dsf.gdb.launching.GdbLaunchDelegate.launch(GdbLaunchDelegate.java:90) at com.google.eclipse.cc.ui.launch.binary.GoogleCppLaunchDelegate.launch(GoogleCppLaunchDelegate.java:127) at com.google.eclipse.cc.ui.launch.test.GUnitLaunchDelegate.launch(GUnitLaunchDelegate.java:30) at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:885) at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:739) at org.eclipse.debug.internal.ui.DebugUIPlugin.buildAndLaunch(DebugUIPlugin.java:1039) at org.eclipse.debug.internal.ui.DebugUIPlugin$8.run(DebugUIPlugin.java:1256) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) Caused by: java.lang.Exception: Warning:\nCannot insert breakpoint 1.\nCannot access memory at address 0x7fffe7fc1190\n at org.eclipse.cdt.dsf.mi.service.command.AbstractMIControl$RxThread.processMIOutput(AbstractMIControl.java:940) at org.eclipse.cdt.dsf.mi.service.command.AbstractMIControl$RxThread.run(AbstractMIControl.java:769) !SUBENTRY 2 org.eclipse.cdt.dsf.gdb 4 10004 2016-05-18 15:36:45.947 !MESSAGE Failed to execute MI command: -exec-run Error message from debugger back end: Warning:\nCannot insert breakpoint 1.\nCannot access memory at address 0x7fffe7fc1190\n !STACK 0 java.lang.Exception: Warning:\nCannot insert breakpoint 1.\nCannot access memory at address 0x7fffe7fc1190\n at org.eclipse.cdt.dsf.mi.service.command.AbstractMIControl$RxThread.processMIOutput(AbstractMIControl.java:940) at org.eclipse.cdt.dsf.mi.service.command.AbstractMIControl$RxThread.run(AbstractMIControl.java:769)
Hi Sergey, Is it possible that you have an address breakpoint set in a previous session, which address is not longer valid in a new session? For example, on Linux, I think that consecutive executions of a given program, are not guaranteed to be loaded at the same address. If that happens, the breakpoint's address may fall outside the program's memory space, and be in a zone where gdb has no permission to write.
(In reply to Marc Dumais from comment #2) This is quite possible, but not a legitimate excuse to throw an NPE.
(In reply to Sergey Prigogin from comment #3) > (In reply to Marc Dumais from comment #2) > > This is quite possible, but not a legitimate excuse to throw an NPE. Is it reproducible for you? I have been trying, but so far my program stubbornly seems to always load at the same address.
Sergey, could you please attach the gdb trace?
Created attachment 261871 [details] Slightly redacted gdb traces.
Marc is right, there is a problem caused by the address breakpoint that is set in the previous debug session. DSF/GDB doesn't handle this case properly, there has been attempts to fix it, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=367256. I'll try to reproduce the NPE by starting a session, setting an address breakpoint at 0x0, terminating the session and then starting it again.
(In reply to Mikhail Khodjaiants from comment #7) > I'll try to reproduce the NPE by starting a session, setting an address > breakpoint at 0x0, terminating the session and then starting it again. Hi Mikhail, Good idea setting the bp at 0x0. It can be easily done in CDT's gdb console: "b *0" I have been able to reproduce the issue in CDT and also using just gdb on the command-line. It seems that inserting the breakpoint at a wrong address, by itself, is ok, but as soon as the execution starts, we see the "can't access memory" error message and the gdb session is borked. So I think it's not just a matter of catching the exception, but maybe rather to prevent trying to install breakpoints at a wrong address (installing disabled seems to be ok, as long as they stay disabled - as soon as I re-enable it, the gdb session is borked). I tried with multiple gdb versions, from 7.11 down to 7.7, and the behavior seems identical. Here is one example, using just gdb: ~$ /var/tmp/gdb/bin/gdb.7.11 /opt/ericsson/oomph-mars/cdt-master/runtime-New_configuration/testRandomLoadAddress/Debug/testRandomLoadAddress GNU gdb (GDB) 7.11 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /opt/ericsson/oomph-mars/cdt-master/runtime-New_configuration/testRandomLoadAddress/Debug/testRandomLoadAddress...done. (gdb) b main Breakpoint 1 at 0x7e2: file ../src/testRandomLoadAddress.cpp, line 19. (gdb) c The program is not being run. (gdb) r Starting program: /opt/ericsson/oomph-mars/cdt-master/runtime-New_configuration/testRandomLoadAddress/Debug/testRandomLoadAddress Breakpoint 1, main (argc=1, argv=0x7fffffffdd78) at ../src/testRandomLoadAddress.cpp:19 19 printf("EBP located at: %p\n",getEIP()); (gdb) b *0 Breakpoint 2 at 0x0 (gdb) c Continuing. Warning: Cannot insert breakpoint 2. Cannot access memory at address 0x0 Command aborted. (gdb) s Warning: Cannot insert breakpoint 2. Cannot access memory at address 0x0 Command aborted. (gdb) info thread Id Target Id Frame * 1 process 30501 "testRandomLoadA" main (argc=1, argv=0x7fffffffdd78) at ../src/testRandomLoadAddress.cpp:19 (gdb) c Continuing. Warning: Cannot insert breakpoint 2. Cannot access memory at address 0x0 Command aborted. (gdb) P.S. I wonder why gdb is so sensitive to this scenario? Bug?
(In reply to Marc Dumais from comment #8) update: the gdb session is not really borked. It's still possible to delete or disable the faulty breakpoint, and then runcontrol works again.
(In reply to Marc Dumais from comment #9) > (In reply to Marc Dumais from comment #8) > > update: the gdb session is not really borked. It's still possible to delete > or disable the faulty breakpoint, and then runcontrol works again. This is a known issue but according to our gdb experts is not a bug. As you can see, the CLI reports the problem and displays the "command aborted" message. Of course, it would be helpful to inform the user that the breakpoint has to be deleted or disabled to proceed. The CDI implementation handled this case by showing an error in the Debug view. Unfortunately, DSF/GDB simply ignores the error and it's run control service becomes out of sync with the underlying gdb session. All this is covered by https://bugs.eclipse.org/bugs/show_bug.cgi?id=367256. I may have time to fix this issue for the next release. Regardless of that fix we also need to check why we get NPE. It is probably caused by the breakpoint issue but we still need to ensure that it will not happen in the future. Did you manage to reproduce it?
Created attachment 261908 [details] Error dialog I get when reproducing the issue
(In reply to Mikhail Khodjaiants from comment #10) > Regardless of that fix we also need to check why we get NPE. It is probably > caused by the breakpoint issue but we still need to ensure that it will not > happen in the future. Did you manage to reproduce it? I will have a look to see if I can track the cause of the exception.
It's pretty obvious from the stack that GDBControl.fMIBackend is null.
(In reply to Sergey Prigogin from comment #13) > It's pretty obvious from the stack that GDBControl.fMIBackend is null. Sergey, it is obvious and the fix is obvious too :) I seems the backend service is not initialized yet or maybe something else is wrong. Just want to make sure the abort procedure works properly.
(In reply to Mikhail Khodjaiants from comment #10) > Regardless of that fix we also need to check why we get NPE. It is probably > caused by the breakpoint issue but we still need to ensure that it will not > happen in the future. Did you manage to reproduce it? Mikhail, I can reproduce the general scenario (367256), but not the NPE, at least not yet.
Bug 505746 describes a way to reliably reproduce the NPE.
(In reply to Sergey Prigogin from comment #16) > Bug 505746 describes a way to reliably reproduce the NPE. I am able to reproduce the issue of the doubling column character (i.e. "foo:bar" becoming "foo::bar"), leading to the path not resolving to the expected directory, but I do not get the NPE. Here's what I get : !ENTRY org.eclipse.cdt.dsf.gdb 4 5012 2016-10-12 12:52:26.582 !MESSAGE Error in final launch sequence !STACK 1 org.eclipse.core.runtime.CoreException: Failed to execute MI command: -environment-cd /opt/ericsson/oomph-neon/cdt-master/runtime-New_configuration/foo::bar Error message from debugger back end: /opt/ericsson/oomph-neon/cdt-master/runtime-New_configuration/foo::bar: No such file or directory. at org.eclipse.cdt.dsf.concurrent.Query.get(Query.java:111) at org.eclipse.cdt.dsf.gdb.launching.GdbLaunchDelegate.launchDebugSession(GdbLaunchDelegate.java:228) at org.eclipse.cdt.dsf.gdb.launching.GdbLaunchDelegate.launchDebugger(GdbLaunchDelegate.java:101) at org.eclipse.cdt.dsf.gdb.launching.GdbLaunchDelegate.launch(GdbLaunchDelegate.java:90) at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:885) at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:739) at org.eclipse.debug.internal.ui.DebugUIPlugin.buildAndLaunch(DebugUIPlugin.java:1039) at org.eclipse.debug.internal.ui.DebugUIPlugin$8.run(DebugUIPlugin.java:1256) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) Caused by: java.lang.Exception: /opt/ericsson/oomph-neon/cdt-master/runtime-New_configuration/foo::bar: No such file or directory. at org.eclipse.cdt.dsf.mi.service.command.AbstractMIControl$RxThread.processMIOutput(AbstractMIControl.java:941) at org.eclipse.cdt.dsf.mi.service.command.AbstractMIControl$RxThread.run(AbstractMIControl.java:770) !SUBENTRY 1 org.eclipse.cdt.dsf.gdb 4 10004 2016-10-12 12:52:26.585 !MESSAGE Failed to execute MI command: -environment-cd /opt/ericsson/oomph-neon/cdt-master/runtime-New_configuration/foo::bar Error message from debugger back end: /opt/ericsson/oomph-neon/cdt-master/runtime-New_configuration/foo::bar: No such file or directory. !STACK 0 java.lang.Exception: /opt/ericsson/oomph-neon/cdt-master/runtime-New_configuration/foo::bar: No such file or directory. at org.eclipse.cdt.dsf.mi.service.command.AbstractMIControl$RxThread.processMIOutput(AbstractMIControl.java:941) at org.eclipse.cdt.dsf.mi.service.command.AbstractMIControl$RxThread.run(AbstractMIControl.java:770)
