Comment 1 Andreas Schik 2007-08-09 12:52:17 EDT

I can see this as well in the released versions (3.3, 4.0.0). Here it happens all the time.
After searching for a while I found the reason. It is a concurrency problem in class org.eclipse.cdt.debug.mi.core.GDBProcess. Its constructor calls (of course) super(), which is org.eclipse.debug.core.model.RuntimeProcess. This constructor calls launch.addProcess(this) which triggers creation of the debugger console and thus creation of the MiConsoleVerboseModeAction toolbar item. Unfortunately, this action needs the fTarget member of GDBProcess.
The reason why you see the problem only once in a while is, that the console creation is event triggered and sometimes the event hits before the constructor of GDBProcess is fully done and sometimes the event hits at a later point in time and everything wil be OK.
I wonder whether calling launch.addProcess(this) in the constructor of RuntimeProcess is a good idea. Shouldn't this be left to the creator of the object? At least org.eclipse.cdt.debug.mi.core.AbstractGDBCDIDebugger calls launch.addProcess again after creating GDBProcess (which does not have any effect as the process is already added to the launch). OTOH, there seem to be to many places where a RuntimeProcess is created and which needed to be changed...
Another solution might be synchronization of GDBProcess (something along those lines, don't know about side effects, though):

public GDBProcess( Target target, ILaunch launch, Process process, String name, Map attributes ) {
	super( launch, process, name, attributes );
	synchronized (this) {
		fTarget = target;
		notifyAll();
	}
}

synchronized public Target getTarget() {
	if (fTarget == null) {
		try {
			wait();
		} catch (InterruptedException e) {
		}
	}
	return fTarget;
}

Comment 2 Nobody - feel free to take it 2007-08-09 13:17:16 EDT

(In reply to comment #1)
Perhaps the better way is to implement the console actions as contributions.
RuntimeProcess belongs to the platform. If you feel it needs improvements, you should submit enhancement requests to the Platform/Debug component. 

Comment 3 Andreas Schik 2007-08-10 03:22:32 EDT

(In reply to comment #2)
> (In reply to comment #1)
> Perhaps the better way is to implement the console actions as contributions.
I actually don't care as long as we get rid of this race condition. But you are probably right on that. As I have said, I quickly drew up something, without caring for side effects. See it as starting point point for a discussion.

> RuntimeProcess belongs to the platform. If you feel it needs improvements, you
> should submit enhancement requests to the Platform/Debug component. 
OK. Thanks for the hint.

Comment 4 Anton Leherbauer 2008-01-07 05:50:42 EST

*** Bug 214407 has been marked as a duplicate of this bug. ***

Comment 5 Elena Laskavaia 2008-01-07 12:57:50 EST

Created attachment 86333 [details]
4_0 patch

Attaching proposed patch.

RuntimeProcess is done very badly, it adds itself to launch and send notification right from constructor, meaning all subclasses would have to  dial with use of uninitiated objects by launch listeners. I added fireChangeEvent at the end of GDBProvess so we can at least receive notification on when it finished initializing. 
Console buttons should have been made as contributions, but it is different bug report and it would not solve synchronization issue anyway.

Comment 6 Anton Leherbauer 2008-01-14 05:59:13 EST

(In reply to comment #5)
> RuntimeProcess is done very badly, it adds itself to launch and send
> notification right from constructor, meaning all subclasses would have to  dial
> with use of uninitiated objects by launch listeners. 

Alena, could you open a bug against Platform/Debug to improve this? Thanks.

I'll apply your patch with one modification: I removed the additional synchronization in GDBProcess. It seems superfluous to me.

Comment 7 Elena Laskavaia 2008-01-14 10:40:10 EST

If there no synchronization Java does not guarantee that two threads would see change in object immediately, meaning if listener running in different thread even it received notification from constructor after target is set getTarget can still return null for this other thread (cached by jvm).

Comment 8 Anton Leherbauer 2008-01-14 11:04:47 EST

(In reply to comment #7)
> If there no synchronization Java does not guarantee that two threads would see
> change in object immediately, meaning if listener running in different thread
> even it received notification from constructor after target is set getTarget
> can still return null for this other thread (cached by jvm).

Right. Declaring the field volatile should be sufficient.

Comment 9 Anton Leherbauer 2008-01-15 04:17:21 EST

Patch applied to 5.0 and 4.0.3.