Show GDB server stderr/stdout output when startup times out

[SnowyTulip]

Issue: #630

Comparing with the develop branch:

• Changed the original local variable definitions of outBuffer and errBuffer to member variables fStartupErrBuffer and fStartupOutBuffer.
• Added getStartupOutput() method: This method combines and returns the strings from fStartupErrBuffer and fStartupOutBuffer.
• Modified the status setting line to:

rm.setStatus(new Status(IStatus.ERROR, Activator.PLUGIN_ID, DebugException.TARGET_REQUEST_FAILED, getStartingServerJobName() + " timed out.", null)); //$NON-NLS-1$

In the timeout check task, rm now outputs them.

Tested with: Eclipse Embedded CDT (2024-12) and Java 11 SE.

[laomaolaile]

I have considered similar approaches, but the best solution would be to display these error messages directly in the Console. This approach would align well with the overall design and user experience of Embedded CDT (embed-cdt).

[ilg-ul]

the best solution would be to display these error messages directly in the Console.

Can we do both? I mean always display these messages in the console in that peculiar condition, and also show them in the message box when the Details button is pressed?

It might look redundant, but the OpenOCD console might not be on top to be easily visible and some users might have difficulties to open it, therefore the graphical solution is pretty convenient.

[fanghuaqi]

Both will be great, if it is possible.

[SnowyTulip]

Hello everyone,
I actually considered this point as well. The reason I didn’t opt to send the message to the console has to do with how the console output logic originally works. It’s worth noting that in the case of a timeout exception, no output is currently generated — following is the reason. O_O

The above describes the startup process of GdbServer.
step 1 : the launch sequence for GdbServer (OpenOCD) is obtained.
step 2 : This sequence is then executed, which includes starting the OpenOCD process, launching the timeout detection process, and more.
step 3: When the timeout detection process is triggered, it sets the status of the rm (RequestMonitor) to ERROR. This in turn causes an ExecutionException to be thrown, leading to the entire launch process being cleaned up and terminated, resulting in the well-known timeout error.

This is because the OpenOCD process (actually the pushback process) is only submitted to DSF and its output is bound to the console during step 4, when ((Launch) launch).initializeServerConsole(monitor); is executed. Therefore, if a timeout exception occurs, the entire debugging session terminates immediately, and step 4 is never reached. As a result, neither the console nor the process actually exists at that point, which explains why no error message is displayed.

[SnowyTulip]

Regarding displaying the error in the console:

Below is how ((Launch) launch).initializeServerConsole(monitor); is used to attach a console.

However, in the OpenOCD timeout detection task, using DebugPlugin.newProcess() as a way to output to the console is not appropriate — because we don’t intend to keep this process alive (in fact, it will be killed immediately by the timeout detection task 😂).

Therefore, I think we should consider using Eclipse’s console-related APIs to create a temporary console and display the final message to the user. The downside is that creating a temporary console would introduce some code that looks somewhat redundant, and it would require importing the org.eclipse.console package, which feels quite out of place.

[SnowyTulip]

Creating a temporary console and displaying the output would look something like this:

[ilg-ul]

I have difficulties to follow the details, things seem to get very complicated. :-(

[SnowyTulip]

@ilg-ul
Sorry, I might have gone into too much detail. In short, I just wanted to explain why no output is shown on the console in the case of a timeout. You can think of it this way: when a timeout occurs, the entire debugging session is immediately terminated. At that point, the OpenOCD console hasn’t even been initialized yet, so there is no console or output — only the error message is triggered. 😊

[ilg-ul]

At that point, the OpenOCD console hasn’t even been initialized yet, so there is no console or output

Can we initialize the console earlier, and, when the exception is identified, retrieve the console output and print it?

[SnowyTulip]

Hi, @ilg-ul
Thank you for your suggestion. I have seriously considered how to implement the idea of initializing the console earlier.
Your idea makes sense, but it comes with the following challenges:

• When the launch is terminated after a timeout is triggered, the timeout detection task destroys the GDBServer process object. However, the console output for the launch still requires access to this very process.
• In the case of a timeout, the GnuMcuLaunch DSF service has not been initialized successfully (due to the timeout), and the launch’s console initialization depends on the GnuMcuLaunch DSF service (by serverServicesLaunchSequence). Without it, we cannot retrieve the GDBServer process object.

Solutions:

• Problem 1 is relatively straightforward to address — we can simply delay the destruction of the GDBServer process object until after the launch has finished using it. The launch itself can then safely destroy it afterward.
• As for Problem 2, I’m not yet sure how to resolve it. At the very least, we can’t rely on the original launch console init logic, since initializing the console depends on the successful execution of the DSF service initialization sequence (serverServicesLaunchSequence).
  However, the serverServicesLaunchSequence fails due to the timeout and remains null.

So far, I’m not sure how to resolve this issue. I’ll spend some time later thinking about whether there’s a more elegant solution.