Community
Participate
Working Groups
The different services need some work to be ready for multi-process. This bug is meant to track the changes necessary for this support in the services.
Created attachment 107227 [details] Multi-process support for ExpressionService This first patch makes minor changes to the Expression Service to support multi-process. These changes should have been done from the start and are backwards compatible.
(In reply to comment #1) > Created an attachment (id=107227) [details] > Multi-process support for ExpressionService (+committed) > > This first patch makes minor changes to the Expression Service to support > multi-process. These changes should have been done from the start and are > backwards compatible. > This was a mistake. I added the ability to build an expression with a process as a parent, or any other ExecutionContext, but it does not make sense to have an expression refer to a processor or a core. I may make sense to have an expression refer to a process and not a thread, but currently, the Expression Service does not handle this properly even at the thread level (vs frame level). Therefore, I'm removing this patch and will open a new bug about the Expression Service.
Created attachment 109298 [details] GDBMultiProcesses service This patch adds a GDBMultiProcesses service which uses the new GDB -list-thread-group commands. Also adds some support for =thread-group-created/exited events. All this is API compatible. Will commit.
This is very cool. It looks like you pretty much re-implemented this service. Does this mean that MIProcesses will be used for pre-gdb7.0 and MIMultiPorcesses for gdb7.0+?
(In reply to comment #4) > This is very cool. It looks like you pretty much re-implemented this service. > Does this mean that MIProcesses will be used for pre-gdb7.0 and > MIMultiPorcesses for gdb7.0+? Yes, that was my plan. GDBMultiProcesses works for all-stop and non-stop, so it could be used with the newest GDB, assuming this becomes available in time. The naming of the classes is not final so they are a bit confusing right now. One thing I did not do is split GDBMultiProcesses into MIMultiProcesses. That should be done eventually, maybe once GDBMultliProc is more finalized.
Created attachment 109613 [details] Cache logic fixed and threadInfo improvements This patch fixes the cache for the GDBMultiProcesses service. It also cleans up the use of thread-info Committed.
I have one concern. Unlike other services, the ICommandControlService, can only deal with a single context. This means that we'll need multiple instances of that service, one per commandControl. I'm a little worried about registering with OSGI and service tracking for such multiple instances. I won't mark as verified until you confirm that was indeed your intention. Some minor comments: o In the constructor of GDBControlInitializedDMEvent and GDBControlShutdownDMEvent, it may be better to have the type of the parameter to be ICommandControlDMContext instead of GDBControlDMContext. This would give more flexibility in case someone wants to create a new context, without having to change those constructors. o Should we @Deprecate AbstractMIControl.getControlDMContext() and GDBControl.getControlDMContext()? o In GDBControl.RegisterStep, should we register as an ICommandControlService also? o In MIControlDMContext, do we accept the commandControlId to be null? If so, we'll get an exception in equals() and hashCode().
It seems that somewhere along these changes the handling of terminating of process broke. If I terminate GDB during active debug session, nothing happens in the Debug view. I debugged this for a little while and traced the bug to this exception: java.lang.ArrayStoreException: org.eclipse.dd.gdb.internal.provisional.service.command.GDBControlDMContext at java.util.AbstractCollection.toArray(AbstractCollection.java:171) at org.eclipse.dd.mi.service.MIBreakpointsManager.terminated(MIBreakpointsManager.java:1243) at org.eclipse.dd.mi.service.MIBreakpointsManager.eventDispatched(MIBreakpointsManager.java:1239) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.dd.dsf.service.DsfSession.doDispatchEvent(DsfSession.java:381) at org.eclipse.dd.dsf.service.DsfSession.access$2(DsfSession.java:334) at org.eclipse.dd.dsf.service.DsfSession$3.run(DsfSession.java:282) at org.eclipse.dd.dsf.concurrent.DefaultDsfExecutor$TracingWrapperRunnable.run(DefaultDsfExecutor.java:276) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:619)
As Pawel figured out, comment #7 was meant for Bug 243611.
(In reply to comment #8) > It seems that somewhere along these changes the handling of terminating of > process broke. If I terminate GDB during active debug session, nothing happens > in the Debug view. I debugged this for a little while and traced the bug to > this exception: > > java.lang.ArrayStoreException: > org.eclipse.dd.gdb.internal.provisional.service.command.GDBControlDMContext > at java.util.AbstractCollection.toArray(AbstractCollection.java:171) > at > org.eclipse.dd.mi.service.MIBreakpointsManager.terminated(MIBreakpointsManager.java:1243) I was not able to reproduce the problem. However, this is code that never ran before. Perviously, the MIBreakpointsManager.terminated() method was called when receiving MIGDBExitEvent, which was never received. With Bug 243216 (and Bug 243611) being fixed, the terminated() method is called for the first time. Now, looking at that method, it calls toArray() from a Set<IBreakpointsTargetDMContext> to a ICBreakpoint array, which is not a supertype of IBreakpointsTargetDMContext, and causes the ArrayStoreException. I'm not familiar with this code so I won't dive in just yet. We could simply comment out the call toe terminated() for now...
(In reply to comment #10) > (In reply to comment #8) > I'm not familiar with this code so I won't dive in just yet. We could simply > comment out the call toe terminated() for now... That's fine with me, I commented out this call and created bug 243899 to track the issue.
Is there a list of tasks that still needs to be done to complete this feature? I was under the impression that it's already implemneted.
(In reply to comment #12) > Is there a list of tasks that still needs to be done to complete this feature? > I was under the impression that it's already implemneted. Yes, your are right. I'm marking as fixed. Pawel, can you verify?
Verified.
DD 1.1 reelased!
