I first came across the paper Build Systems à la Carte by Mokhov, Mitchell and Peyton Jones over an year ago. I’ve recently been re-reading it, this time working through all the details and trying to really understand it. I love that it is an extremely readable paper analyzing a practical aspect of software engineering. The twist: it uses Haskell, using its properties to impose strong proofs on certain aspects of the build.
I run the dev channel of ChromeOS. This crashes occasionally. While my chrome tabs are generally recovered, it also resets the crostini containers. Every time this happens, I’ve to launch 1Password (the android app), unlock it, search for my SSH key, copy the password and finally paste it in the terminal. This was starting to get old. A couple of days ago I spent about an hour short circuiting this.
tl;dr: Save My Tabs is a Chrome extension to save the list of open tabs to Dropbox. I’ve a weird browser usage pattern due to hardware choices. On two of my devices (work laptop, iPhone), I use Firefox. My personal laptop is a Pixelbook. While it is possible to use Firefox on ChromeOS within Crostini, the experience is pretty abysmal compared to using Chrome. This kept leading to an annoying situation where I couldn’t access tabs open in Chrome on my other devices.
A friend was complaining about this library they were trying to use that was failing to load a configuration from a file. The resulting dive into the code inspired this post about inappropriate choices made when designing how a library is configured. It isn’t my intention to pick on pyart. I appreciate the hard work the developers did to create it and open source it. It is just the example at hand.
When a debugger, profiler or crash reporter is unwinding the call stack, can it reliably retrieve the function arguments of every function in the stack? I originally intended for this to be a later part of the Sampling Profilers series, but a recent discussion with Ben Frederickson, and his subsequent py-spy implementation helped crystallize my thoughts and I figured I’d write it down separately. Retrieving function arguments is “trivial” in certain cases and pure guesswork in others.
This is part 2 of the Sampling Profilers Internals series. Introduction Suspending threads Stack unwinding Symbolication Presenting profile output Extending the profiler to managed languages As described in the introduction, a sampling profiler captures the stack of each thread every few milliseconds. To do this, it is preferable to suspend the thread 1. We don’t want the stack changing under us as we are profiling.
Sampling profilers are useful tools for performance analysis of programs. I’ve spent a lot of time over the past several months digging into various implementations of sampling profilers and reading a lot about symbolication, threads, stack unwinding and other gory operating system details. This series of posts attempts to summarize my understanding. Introduction Suspending threads Stack unwinding Symbolication Presenting profile output Extending the profiler to managed languages Background High CPU usage is a problem that comes up often in widely used software.
I gave a talk at PyGotham 2018 about how Python implements stack frames and how Dropbox leveraged that to improve crash reporting using Crashpad. I also contributed to the Dropbox Tech Blog post that goes into great detail on the crash reporting pipeline. The talk was less about Crashpad and more about Python internals. There is a video and slides. As part of preparing for the talk, I wrote the following post.
On typical days, we software engineers are usually stuck due to head scratching bugs, instead of actually writing interesting software. I had made some small changes and suddenly our end-to-end tests were timing out, with no useful clues. The harness emits a crazy number of log lines, so digging through them was difficult. Fortunately, the problem was easily reproduceable on a local VM and with some piecemeal commenting I was able to isolate it to changing the thread name of the main thread, that I had done for some debugging information.
I was futzing around with some C code a few days ago and noticed that executables generated by Clang would sometimes have an extra 4 bytes on the stack. This was just for the main function. We can verify this is Compiler Explorer. Try switching to GCC and this doesn’t happen. This was interesting, so I spent a few hours over the holiday digging into why and how this happens.