[Windows] Unable to capture stderr output from spawned st-util process

[john5f35]

There seems to be a issue on Windows that the stderr output from spawned st-util.exe is not captured. Thus the promise returned byGDBServer.init() never gets resolved. This eventually leads the st-util.exe process being sent a SIGTERM signal due to timeout, and the debugging on Windows using st-util fails to launch.

I'm looking into this problem at the moment. This issue tracker will track my findings and relevant discussions.

[john5f35]

This seems to be a st-util issue. It has nothing to do with NodeJS. I'ved logged it on Taxane's issue tracker.

[Marus]

Yeah, I’ve been reading up a bit and have come across people sometimes having strange behaviour for certain programs on Windows and capturing stdout/stderr (not specifically st-util, but it seems to exhibit the symptom).

For now, until either st-util is fixed or I can find a better workaround, I will probably just force a resolve after a short delay on Windows when using the st-util server - that way it will likely work in the typical case, without creating a race condition in other cases.

[john5f35]

Yeah, okay. It’s probably a good idea also to document this hack in the code.

…

Sent from my iPhone

On 9 Feb 2018, at 11:03, Marcel Ball ***@***.***> wrote: Yeah, I’ve been reading up a bit and have come across people sometimes having strange behaviour for certain programs on Windows and capturing stdout/stderr (not specifically st-util, but it seems to exhibit the symptom). For now, until either st-util is fixed or I can find a better workaround, I will probably just force a resolve after a short delay on Windows when using the st-util server - that way it will likely work in the typical case, without creating a race condition in other cases. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or mute the thread.

[Marus]

I don't have st-util working on my Windows environment yet (Just get an error that it can't find the device - don't know if it is because it is a virtualized Windows environment or just something else not setup correctly) - so this one is hard for me to test.

I've put a V0.1.14-pre release up on GitHub that I think should work as a workaround (just makes the assumption for st-util that it will have launched properly after half a second) - if you have a moment to test it on your setup that would be good. (Also has the value formatting in the core/peripheral register views - right click on a node and select the "Set Value Format" option).

[Marus]

Ok - I was actually able to get it working on my Windows test environment (Hadn't realized that st-util on Windows still requires you to have the official ST-Link drivers installed as well; don't use Windows much). The workaround does seem to work in my case - but would still be good to have a test of it on your setup before release if possible.

[zarakay]

Heya, Just tested the extension prerelease version. Can confirm it works, Not sure if this will helpful at all in making the code cleaner but I found this: https://gist.github.com/cowboy/3427148

[Marus]

Thanks for letting me know about the testing on Windows. That solution you linked too won’t help in this case, but at least for now there is a workaround in place so that it is usable (even if it is an ugly hack at the moment).

[john5f35]

Thanks Marus. My colleague confirmed that it works on Windows.

[Marus]

Ok - Assuming I don't find any unexpected issues tomorrow I'll be releasing the update then. At least it's a work around for now - and maybe at some point I can determine a better fix

[john5f35]

Sounds good.