FORUM CTRLX AUTOMATION
ctrlX World Partner Apps for ctrlX AUTOMATION
- About gknap
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
About gknap
since
12-08-2020
03-02-2022
gknap
Member
3
Posts
0
Likes
1
Solution
08-27-2021
06:26 PM
Thanks. It's now working for me. The important point is to ensure that all breakpoints are deleted before pressing F5 (continue). The "Remove All Breakpoints" step ensures that you only need to manually remove one breakpoint. The "Run and Debug" item is found here: When the debugger initially connects, the "snap" program is running -- not your application. I don't think Visual Studio Code expects this, and perhaps that's why you have to remove all breakpoints now? The first three times I press F5, execution stops again inside "snap". The fourth time I press F5, it starts my program. (It says "dash" initially because snap uses wrapper scripts; but a few lines further down, the program starts.) ... and stops on the line that calls "raise(SIGSTOP)". As expected, the Terminal window now displays the "waiting for debugger" message that precedes the "raise(SIGSTOP)" call. As the documentation states, it's now possible to add breakpoints and continue or step as needed.
... View more
08-06-2021
09:27 PM
I have observed a similar problem. I'll try to include complete details, so that hopefully someone can reproduce this problem, and/or tell me what I've done wrong. For this example, I am starting with a clean copy of "samples-cpp/hello.world" from SDK 1.10. I have already configured and tested SSH key-based authentication. The configuration settings below were borrowed/adapted from other SDK examples. Modify "tasks.json" as follows: // add to "tasks":
{
"label": "Launch GDB Server",
"type": "shell",
"problemMatcher": "$gcc",
"command": "ssh ${input:Root-User}@${input:Target-IP} \"sudo snap run --experimental-gdbserver=:12345 helloworld.HelloWorld\" ",
},
// add to "inputs":
{
"id": "Target-IP",
"type": "promptString",
"description": "Remote IP address",
"default": "192.168.1.1"
},
{
"id": "Root-User",
"type": "promptString",
"description": "Remote user name",
"default": "myroot"
}, Modify "launch.json" as follows: // add to "configurations":
{
"name": "Remote Debug arm64",
"type": "cppdbg",
"request": "launch",
"program": "${workspaceFolder}/generated/linux-gcc-aarch64/Debug/HelloWorld",
"cwd": "${workspaceFolder}",
"miDebuggerPath": "/usr/bin/gdb-multiarch",
"miDebuggerServerAddress": "${input:Target-IP}:12345",
"stopAtEntry": true,
"targetArchitecture": "arm64",
"externalConsole": false,
"MIMode": "gdb",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
]
},
{
"name": "Remote Debug x64",
"type": "cppdbg",
"request": "launch",
"program": "${workspaceFolder}/generated/linux-gcc-x64/Debug/HelloWorld",
"cwd": "${workspaceFolder}",
"miDebuggerPath": "/usr/bin/gdb",
"miDebuggerServerAddress": "${input:Target-IP}:12345",
"stopAtEntry": true,
"targetArchitecture": "x64",
"externalConsole": false,
"MIMode": "gdb",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
]
},
// add to "inputs":
{
"id": "Target-IP",
"type": "promptString",
"description": "Remote IP address",
"default": "192.168.1.1"
}, Change the input defaults to match your development environment if you like. Build the debug snap, and install it on the ctrlX CORE. In VS Code, open the "Terminal" menu, and select "Run Task". Select "Launch GDB Server". Confirm your remote root user name and remote IP address. You should now see the following in your VS Code Terminal window: Welcome to "snap run --gdbserver". You are right before your application is run. That is followed by instructions for starting GDB manually. Try it, from the WSL command prompt: $ gdb-multiarch -ex="target remote 192.168.0.123:12345" At the gdb prompt, type "cont". Doing that repeatedly causes the program to run to completion; you should see the "Hello World" message in the VS Code terminal window. Type "q" to exit GDB. Launch the GDB server again; but this time, connect to it with VS Code: open the Command Palette, select "Debug: Select and Start Debugging", choose "Remote Debug: arm64", and confirm the remote IP address. It will stop on a "raise" call, just as it did previously. However, at least for me, attempting to continue with the F5 key or "-exec cont" repeatedly produces the error: ERROR: Command aborted. See the output window for additional details. I can't find anything relevant in the output window. I'm not sure of what to do next. Any advice would be appreciated.
... View more
08-06-2021
07:14 PM
The SDK example "datalayer.register.node" contains the following code: (line breaks added by me) auto bfbsPath = getenv("SNAP") != nullptr
? strcat(getenv("SNAP"), "/sampleSchema.bfbs")
: "bfbs/sampleSchema.bfbs"; This seems incorrect to me: strcat() modifies the buffer pointed to by its first argument, but the man page for getenv() states: ... getenv() returns a pointer to a string within the environment list. The caller must take care not to modify this string ... Instead, I think the sample code should do something like: const char * snapPath = getenv("SNAP");
char bfbsPath[256];
strcpy(bfbsPath, (snapPath == nullptr) ? "bfbs" : snapPath);
strcat(bfbsPath, "/sampleSchema.fbs"); Of course, it would be even better to replace strcpy/strcat with functions that check the destination buffer size.
... View more
Latest Tags
No tags yet
OK
OK