-
Notifications
You must be signed in to change notification settings - Fork 237
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Windows] Unable to capture stderr output from spawned st-util process #18
Comments
This seems to be a |
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. |
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.
|
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). |
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. |
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 |
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). |
Thanks Marus. My colleague confirmed that it works on Windows. |
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 |
Sounds good. |
There seems to be a issue on Windows that the
stderr
output from spawnedst-util.exe
is not captured. Thus the promise returned byGDBServer.init()
never gets resolved. This eventually leads thest-util.exe
process being sent aSIGTERM
signal due to timeout, and the debugging on Windows usingst-util
fails to launch.I'm looking into this problem at the moment. This issue tracker will track my findings and relevant discussions.
The text was updated successfully, but these errors were encountered: