search

ARM-software / vscode-cmsis-csolution

Extension support for VS Code CMSIS Project Extension
https://marketplace.visualstudio.com/items?itemName=Arm.cmsis-csolution
Other
23 stars 5 forks source link

Daemon Isn't Starting #10

Closed vindicatorr closed 1 year ago

vindicatorr commented 1 year ago

Sandboxed: No Describe the bug

To Reproduce Steps to reproduce the behavior:

  1. Go to the cmsis extension
  2. Click on '+' (create a solution)
  3. See error

Expected behavior

The daemon should run. It appears not to be.

Code sample and logs

Screenshots

Additional context

Error:

Solution service failure: 14 UNAVAILABLE 14 UNAVAILABLE: No connection established GrpcServiceError: 14 UNAVAILABLE 14 UNAVAILABLE: No connection established at Object.create (/home/userName/.vscode-oss/extensions/arm.cmsis-csolution-0.8.1-linux-x64/dist/desktop/extension.js:2:1164258) at Object.parse (/home/userName/.vscode-oss/extensions/arm.cmsis-csolution-0.8.1-linux-x64/dist/desktop/extension.js:2:1164405) at a.<anonymous> (/home/userName/.vscode-oss/extensions/arm.cmsis-csolution-0.8.1-linux-x64/dist/desktop/extension.js:2:1163511) at a.emit (node:events:526:28) at Object.onReceiveStatus (/home/userName/.vscode-oss/extensions/arm.cmsis-csolution-0.8.1-linux-x64/dist/desktop/extension.js:2:336379) at Object.onReceiveStatus (/home/userName/.vscode-oss/extensions/arm.cmsis-csolution-0.8.1-linux-x64/dist/desktop/extension.js:2:329495) at /home/userName/.vscode-oss/extensions/arm.cmsis-csolution-0.8.1-linux-x64/dist/desktop/extension.js:2:289349 at process.processTicksAndRejections (node:intern...

I looked at the extension directory and saw the cmsis tool and explored that. I saw there was a "daemon" feature, which made me think it should be running. It was not. No cmsis process, nor any port 9000 being used. So I tried to start it manually, but still saw no port. Then I added verbosity and saw it say it started and how to stop it. Then I added the logging and saw mention of address 1.1.1.1. Odd. Why? I also saw --help mention the .config, but the path mentioned as default does not exist. So when I manually started the process with the address:port 127.0.0.1:9000, it ran, and the "create a solution" began with populating the device list.

mcgordonite commented 1 year ago

Hi @vindicatorr, thanks for your detailed bug report.

The daemon tries to start on hostname "localhost" by default. Is it possible your system doesn't have "localhost" configured. Is there an entry for it in /etc/hosts?

vindicatorr commented 1 year ago

Correct, my hosts file is blank.

madchutney commented 1 year ago

@vindicatorr Thanks for the bug report and for the investigation. The cmsis tool is actually a gRPC server that should indeed be running and as you worked out, it should normally be running on localhost.

I think that could be the cause of the problem, could you add 127.0.0.1 localhost and retry?

The IP address 1.1.1.1 is normally associated with Cloudflare’s DNS server, is this something you have configured to resolve your DNS?

vindicatorr commented 1 year ago

Hmm, interestingly, I expected, as you did, that adding it in would work, but it did not:

$ cat /etc/hosts
# Static table lookup for hostnames.
# See hosts(5) for details.
127.0.0.1 localhost

I also pinged localhost (-4) and got results. I also $ resolvectl query localhost:

localhost: 127.0.0.1                           -- link: lo
           ::1                                 -- link: lo

... so it looks like it should, but I still get:

Solution service failure: 14 UNAVAILABLE 14 UNAVAILABLE: No connection established GrpcServiceError: 14 UNAVAILABLE 14 UNAVAILABLE: No connection established at Object.create (/home/userName/.vscode-oss/extensions/arm.cmsis-csolution-0.8.1-linux-x64/dist/desktop/extension.js:2:1164258) at Object.parse (/home/userName/.vscode-oss/extensions/arm.cmsis-csolution-0.8.1-linux-x64/dist/desktop/extension.js:2:1164405) at a.<anonymous> (/home/userName/.vscode-oss/extensions/arm.cmsis-csolution-0.8.1-linux-x64/dist/desktop/extension.js:2:1163511) at a.emit (node:events:526:28) at Object.onReceiveStatus (/home/userName/.vscode-oss/extensions/arm.cmsis-csolution-0.8.1-linux-x64/dist/desktop/extension.js:2:336379) at Object.onReceiveStatus (/home/userName/.vscode-oss/extensions/arm.cmsis-csolution-0.8.1-linux-x64/dist/desktop/extension.js:2:329495) at /home/userName/.vscode-oss/extensions/arm.cmsis-csolution-0.8.1-linux-x64/dist/desktop/extension.js:2:289349 at process.processTicksAndRejections (node:intern...

I even cleared out cmsis-csolution.coreTools.address and just left with:

    "cmsis-csolution.experimentalFeatures": true,
    "cmsis-csolution.packCachePath": "<pathTo>/ARM/CMSIS_packs",
    "cmsis-csolution.cbuildPath": "<pathTo>/ARM/CMSIS-DSP/Source/build/wtf/cmsis-toolbox-linux-amd64/bin/cbuild",
    "cmsis-csolution.csolutionPath": "<pathTo>/ARM/CMSIS-DSP/Source/build/wtf/cmsis-toolbox-linux-amd64/bin/csolution",
    "cmsis-csolution.outputPath": "csolutionOut",
    "cmsis-csolution.coreTools.path": "<pathTo>/ARM/CMSIS_devtools/build/bin"

But when I manually start it (~/.vscode-oss/extensions/arm.cmsis-csolution-0.8.1-linux-x64/tools/cmsis-core-tools/cmsis daemon start), it ran fine and the extension work. But for whatever reason, the extension isn't starting it.

EDIT0: For what it's worth, I never ended up needing this option. I was merely trying to build the DSP for my device and kept going deeper and deeper and came across this "option". I finally managed to do what I needed to do yesterday. In other words, there's no need for me for this to get solved and it could just be a freak case, but am willing to work out with you in finding the issue if you want. EDIT1: Oh god, my editing is causing ghosted text sections.

mcgordonite commented 1 year ago

With cmsis-csolution.coreTools.address the extension won't start the daemon itself, it will assume there is one already started. If cmsis-csolution.coreTools.path is set, it looks at that path for the daemon binary.

What happens if you remove both settings and try again? You may need to restart VS Code to see the change unfortunately.

Thanks for your help investigating this.

vindicatorr commented 1 year ago

Yup, that coreTools.path was the other part of it. Just to make sure, I closed out vscode, then ran ss -pan | grep cmsis, and when it cleared out, I ran vscode again, did nothing, ran that ss command again, and the daemon had run automatically.

I was just trying everything I could with the settings, setting those to what I knew (eg csolution/cbuild), but I wasn't sure about "core tools", and just presumed it was devtools, which I just set to the build/bin.

Case closed.

EDIT0: Another thought, if cmsis-csolution.coreTools.path is expecting the daemon to be found there, then maybe alert the user the path is incorrect when the cmsis binary is not found there (or more clarity of what coreTools is (aka, the extension bin).

EDIT1: Sorry, hopefully one last edit... I neglected to mention my other thought, that instead of just relying on the existance of localhost (which could point anywhere), have a fallback to 127.0.0.x that has port 9000 available. Though that may get a little messy, trying to catch everything.

mcgordonite commented 1 year ago

Another thought, if cmsis-csolution.coreTools.path is expecting the daemon to be found there, then maybe alert the user the path is incorrect when the cmsis binary is not found there (or more clarity of what coreTools is (aka, the extension bin)

Good suggestion, I've added it to our backlog. Thanks again for investigating this.

madchutney commented 1 year ago

@vindicatorr Many thanks, your time and effort is much appreciated.