Description Hampus Edvardsson 2007-01-25 05:37:24 EST

Build ID: I200609270800

Steps To Reproduce:
1. Use a custom gdb debugger which can signal it's state to the debugger frontend by sending mi-messages on the form "0^running"/"0*stopped".
2. Have the debugger send an unrequested running mi-message to CDT ("0^running").
3. CDT crashes from a NullPointerException on org.eclipse.cdt.debug.mi.core.RxThread:211 (cmd is null)


More information:
I'm using CDT with a (custom) version of gdb which can start/stop running without previously being instructed by the frontend to do so. This is implemented by sending the MI-messages "0^running" or "0*stopped" to the frontend. Note that since the message is not a reply of a message sent from the frontend, we can not provide a proper MI message id, instead we fake it by sending 0.

This worked fine with CDT 2.x but broke in CDT 3.1 (and 3.1.1) because of the following addition on lines 211-212 in org.eclipse.cdt.debug.mi.core.RxThread:

211    if (cmd.isQuiet())
212        event.setPropagate(false);

A few lines earlier (line 177) cmd was defined as:

177    Command cmd = rxQueue.removeCommand(id);

In my case cmd is null since CDT has no knowledge about a command with id = 0. The result is a NullPointerException on line 211, efectively taking down the RxThread.

All other references to cmd takes into account that the varaible may be null and does the right thing if it is.

In the version of CDT that I ship I have changed line 211 to  first check that cmd is not null before referencing it:

211    if (cmd != null && cmd.isQuiet())
212        event.setPropagate(false);

It would be very helpful for me (and perhaps others) if this check could be merged into CDT 3.1.2.