Koodihommia

The previous blog post about the memory structure left me thinking about where the memory is allocated. Why did one of the variables stay in the stack and one go to the heap?  I stumbled upon this wonderful presentation on the very subject. Turns out that the go compiler can tell me where the variables are allocated. You just need to give it a couple of GC flags. Let's take another look at the example program I used in the blog post. Looks like everything escapes to the heap when building with my mac! It most likely has something to do with the println() debug command taking a interface as its argument instead of a known type. Source: https://www.youtube.com/watch?v=ZMZpH4yT7M0

In a previous blog post, I took a look at how to enumerate all the syscalls and even their arguments using tools such as  eBPF . That left me pondering and craving to learn more about how memory is mapped and what do simple variables look like in the memory. What is behind all those memory addresses you can see in the stack traces? I do have an intuitive sense of that. Sure, I have seen blog posts and talks about the topic, taken a look at heap dumps in a hunt for memory leaks but I wonder does it make any sense to look at the memory in a language/runtime agnostic manner. Probably not, but hey, could be exciting. To find out, I created a simple program that simply prints out the contents of a few variables  I try to make the outputs depend on the runtime environment to avoid any unexpected compiler optimizations. I want to make sure the memory will be allocated at runtime. I run the code in my trusty Digitalocean VM with "no hang-up" and attach the GNU Project debugger (GDB) ...

I describe how I build the Zynthian Raspberry Pi OS synthesizer from a kit in a previous blog post . It sits mostly idle connected to my sound card, so I decided to make it a bit more useful while it is idling. The first goal was to make it play Radio Helsinki, one of my most played online radio stations. That's simple enough; I just created a systemd service which connects to the stream using mplayer. Note that I'm using jackaudio as an audio "sink." The synthesizer is thus perfectly playable, even if I am listening to something else meanwhile. I get soon bored listening to only one channel. The next step is then to add Spotify. There is a pre-made debian package called raspotify , but alas, the bundled librespot Spotify client does not work with the jackaudio backend. I decided that the most comfortable choice is to compile librespot in the Raspberry Pi and then create a systemd service (after all, that is pretty much all raspotify does). The Spotify client service...

In my ongoing quest to understand more how GNU Linux works under the hood, I took upon myself a courageous assignment to figure out what a simple go program does from a kernel's point of view - which syscalls are called and what data is passed down there Here is the program So a simple hello world, which prints out the famous words and creates an empty file. To figure out which syscalls are triggered, I decided to use trace-cmd package. It is a frontend to ftrace which helps for example in filtering out the syscalls related to a single binary or a PID. After some intense googling, watching a couple of youtube videos , and fiddling around, I ran this command. sudo trace-cmd record -p function_graph --max-graph-depth 3 -e syscalls -g do_syscall_64 -F ./gohello It records a list of kernel functions practically in the order they are called with max depth and some filtering. It shows only syscalls and not, for example, system interrupts that clutter the output and are not in this exer...

Every so often, I get fooled by the scary-looking rising memory graphs on my puny minimum sized VM running on Digital Ocean. The same thing seems to happen to my colleagues and I have to go into this discussion on memory usage on virtual machines and on work laptops. I'm not an expert on the topic but I have gathered here a couple of things to demystify the issue. The first question I ask myself or a fellow developer is: what do you mean by running out of memory? You are most likely talking about memory pressure, right? What are the symptoms? Is it just a gut feeling or is there some verifiable performance degradation? After that, we could talk about a few seemingly counter-intuitive topics The "raw" memory usage should be high. Especially on a busy VM, it is good that frequently used files are mapped to memory. The OS does not know when it is out of memory. The Linux kernel allocates memory until it can't. You probably should have swap on Before one goes digging into...