I am running torizoncore bookworm.
So, I can run my program in debug. But if I try to run it in the existing container without the debugger by setting the user to root and then launching it from the commandline, CAN prints out errors that saying “No buffer space available”. I have no such message in my code.
What is the difference between debugging and other than having the debugger own the process? Is there some setup that is happening via the debugger or something else that it is not immediately obvious?
But if I try to run it in the existing container without the debugger by setting the user to root and then launching it from the commandline
How exactly are you running your container in this case?
CAN prints out errors that saying “No buffer space available”.
This sounds like an error coming from the CAN bus interface itself not your application.
What is the difference between debugging and other than having the debugger own the process? Is there some setup that is happening via the debugger or something else that it is not immediately obvious?
You can compare the debug and release Dockerfiles as well as the debug and release configuration in the compose file. That would show you the difference in how the container is both built and executed between debug and release configurations.
Does your container/application work correctly in the production/release mode configuration?
Run a source code static analysis tool, a good one, not just the first free one you find. Be absolutely certain you have -Wall turned on and are not ignoring any compilation warnings.
Works in debug but not release is 99.99% of the time uninitialized variables/buffers/etc. If you have ‘C’ type buffers:
char buff[2048];
0.01% of the time you are writing past the end of such a buffer. Most “modern” debugger compilations put padding around such buffers so under/overwrite doesn’t cause a crash.
On the outside chance none of the above is your problem (buy a $2 billion dollar lottery ticket) because when you launch your container under debug you are using the Torizon (whatever) default user ID and have authorized it to write to /tmp in your command line . . . root is not. Root inside a container is not the same as root for the host.
Let me be clear hear. I am running the exact same exe (debug) in both cases. I know the pitfals of going from debug to release, but that is a completely different issue. Because of the need to use the CAN bus, I have to run it as root. I do this by opening a shell in the container, changing to root and then executing it from there. I’ve tried both foreground and background launches. I am also using the same Docker container, set up by Visual Studio. I’ve tried running it after running the program with the debugger, then stopping the program and then running it. I get the same results either way.
I do this by opening a shell in the container, changing to root and then executing it from there. I’ve tried both foreground and background launches.
This didn’t really answer my question. I want to know exactly how you’re launching your container and how you’re getting a shell into the container as root and executing your application. I want to see exact steps, and commands you’re running.
Also I understand you need to be root to use the CAN bus inside a container. But why are you doing it like this by getting a shell in the container as root? Can’t you just set the debugging process to execute as root as described in a previous thread you created: How to enable CAN bus using C++ code - #6 by lucas_a.tx
Is there a reason you’re doing this manual execution instead of just using the default debugging process?
@jeremias.tx ,
I wanted to run it without the debugger to check for long term issues, as is. Sometimes debuggers hide issues that show up over time. This is all I am trying to do.
My steps are:
start up visual studio Code and it connects with WSL.
I turn in the dev board and wait for it to boot.
I hit F5 and wait for the VSC to start up the container, and be ready to run. My docker-compose.yml adds all the peripherals I use.
Then I stop the debugger without running it.
if I click on the Docker icon on the side of VSC, I can see the container running, that contains my app. I right click on that and select attach shell. I do this so I can manually go into the docker container and start my app from a command line without the debugger running.
I cd to the root/app directory and do su root.
I run my program by typing ./myprogram
Nothing complicated. Just trying to run it without the debugger, with everything else being the same.
How exactly are you timing this step? Hitting F5 starts a series of interconnected processes from building, deploying, running, and debugging your containerized application. I’m not sure how you’re timing this perfectly such that your application doesn’t run.
Is it possible you’re not timing this right and your application partially executes? Then when you manually execute your application it errors out because the initial partial execution already did something with the CAN bus causing a conflict.
I cd to the root/app directory and do su root.
Not sure why you do this, when I attach shell from VSCode I’m already in the container shell as root by default.
All that said I tried your process but with just a simple hello-world application since I don’t know how your system and application is setup. It worked fine for me. Though I wasn’t really able to to hit F5 then stop the debug process with perfect timing such that my container started but didn’t execute gdb on my application. So my application still partially executed via gdb. Though I didn’t have any issues then manually executing, since it’s a simple hello-world application and is therefore unlikely to conflict with the partial execution.
Just trying to run it without the debugger, with everything else being the same.
If you’re just trying to run your application without the debugger, why not just use the production configuration? Or just start your container manually without the use of VSCode and run your application that way?
I feel this method you’re doing of hitting F5 to start the debug process but somehow stopping before anything gets executed is not exactly precise. Based on the error you’re getting of No buffer space available it really seems like you’re not stopping the debug process in time and your application does some actions with the CAN bus before you can manually execute your application.
After you attach shell to your container from VSCode. Instead of manually executing your application can you use the can-utils on the command-line in the container to manipulate CAN or do you get a similar error?
I think you are overthinking this. I simply use the debug start process to get the container up. Then I STOP the debugger when it gets to my main startup point. The debugger no longer is running and neither is my program. I’m sorry that when I said I stop it, I meant that. The container is still there, although I did think that I had do attach the shell before stopping the debugging process to keep the container up, but it seems to work either way.
Anyway, so when I try to run my program manually in the container, that is what I get (described earlier). I also did a su root, thinking I came in as torizon. Since before when I tried this, I wasn’t doing a runas with the docker-compose.yaml. Thanks for pointing that out.
Before I try to run, this is all that is running in this container:
ps -aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.2 16332 8320 ? Ss 14:19 0:00 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
root 62 0.0 0.0 4476 3468 pts/0 Ss 14:20 0:00 bash
root 82 0.0 0.0 8436 3804 pts/0 R+ 15:02 0:00 ps -aux
My program stops at the first executable line in my code, and before any threads are launched when in the debugger. So stopping the debugger at this point, should be sure that no resources are in use by my program, as this shows:
ip link show | grep can
5: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT group default qlen 10
link/can
6: can1: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT group default qlen 10
link/can
I hope I have answered all your questions.
After digging around, I have discovered why I was getting this error, but I am not sure why I wasn’t seeing it in debug. It doesn’t matter though as this issue will go away with other changes in my code.
Thanks for verifying that it was some difference in whether I get this error only not running in the debugger.
