sigmoid.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
A social space for people researching, working with, or just interested in AI!

Server stats:

594
active users

#debug

0 posts0 participants0 posts today

Wrote a blog post on how to use strace to better debug programs:
rrampage.github.io/2025/06/13/

A Random Walk · strace tips for better debuggingRecently, I have been building software without libc to better understand Linux syscalls and internals better. So far, I have built a minimal shell, terminal Snake game, pure ARM64 assembly HTTP server and threads implementation. I have been using strace extensively while debugging. Useful options and flags I use a version of the following command: strace -fintrCDTYyy -o strace.log -v -s128 ./binary This looks like an alphabet soup of options! Here’s what they do and how they are useful: -f: Follow child processes/threads. This is especially useful when dealing with spawning processes or threads as otherwise, strace will only trace the parent process. -v: Print unabbreviated versions of environment, stat, termios and other structs in syscalls. I found this invaluable in conjunction with -s when doing assembly programming to check if the structs were being initialized correctly and if certain arguments were being sent in little/big endian format -s NUM: Specify the maximum string size to print. Useful for large structs -o: Save strace output to a log file. It is always better to do this to investigate the output of the original process and strace separately without each cluttering the other -yy: Print all available information associated with file descriptors. This is great for expanding the file descriptor to either its full path in case of a file or TCP address in case of sockets -Y: Print command names for PIDs. I found this useful when building the shell to check if the correct program is being executed -t: Print current timestamp in log -T: Show time spent in syscalls. Useful for some basic profiling although strace heavily slows down the process. -r: Print a relative timestamp upon entry to each system call -n: Print syscall number. Great to quickly find out syscall numbers on new architectures. -i: Print instruction pointer at the time of syscall. Found this useful when debugging assembly code to check rough location of errors. -C: Print summary of syscall count, time, errors at the end of regular output Print stack traces The -k or --stack-trace prints the stacktrace along with the syscall. This is useful if your program is compiled with with -g. This post is a good read on using strace to show backtraces for a Golang program compiled with GODEBUG.

Les règles de débogage à appliquer dans l'ordre en embarqué :
1. Le montage est il sous tension et sorti du reset ?
2. Le port uart est il : branché, dans le bon sens et à la bonne vitesse ?
3. Ai-je chargé le bon firmware ! ?

Allez disons que 90% des problèmes viennent de là.

Wow.. So I was trying to some Rust code that would take six hours to run.

My goal was to get that down to 3.5 hours (something I'd achieved previously with lost code). Some tweaking got it down to 5 hours estimated runtime.

Then I thought to do:

"cargo build --release" instead of just "cargo build" for the first time.

And we're down to 3 minutes.... not 3.5 hours... 3 minutes.

Ok.. Good to know. Debug adds just a tiny bit of overhead on some code ;-).

Trying to #debug a playback issue on my #Roku and it is annoying the hell out of me. I have a #tvheadend #server (CPU only) feeding a live #MPEG2 video #stream to a #Jellyfin server with a #Nvidia #Quadro #K2200 for #hardware acceleration. When hardware #encoding is turned on, the Roku can play transcoded rendered movie files but not the live stream. When hardware encoding is turned off (decoding still on), the Roku can play transcoded movie files and the stream. #WTF why one and not the other?