Something I found incredibly frustrating when I started programming was that I could not spend more time building projects and instead had to fight with errors that seemed like a distraction. These major time sinks didn’t seem more than an inconvenience that were preventing me from making progress and focus on the fun stuff.
Sampling profilers periodically fetch the stacktrace of the application under observation. Historically, this has been from within the process, in-band, using signals. In fact, there’s a signal dedicated for this sole purpose, SIGPROF. We can register a signal handler for it that would retrieve the current stack. This stack could then be added to some data structure and eventually, the generated…
Most software writes to disk at some point but in some cases nothing cleans up the stale data that won’t ever be read again. Engineers working with large scale infrastructure might be familiar with the situation where an engineer, by pure chance, finds out they had several petabytes of old logs that were not deleted.
GDB has an amazing feature that allows to run arbitrary functions on a target process. This is really useful to access information at runtime that was not enabled ahead of time.
Working on some eBPF / BCC script that fetches the stacktraces of processes that receive deadly signals I saw dozens of segfaulting Java processes. Despite core dumping was enabled, none was generated. [1]: # trace.py -U 'p::complete_signal(int sig, struct task_struct *p, int group) (sig==11) "%d", sig'
This summer, while working on my internship project, I realised that an internal CLI tool was taking too long to run. The tool purpose is not very relevant here, but my understanding was that it should finish in way less than a second, however, it was taking several seconds perform its work.
Some weeks ago I started doing a side project in C. It didn’t do really complex stuff, but still, I was struggling with some “core” C stuff, namely pointers!