Once upon a time there was an obscure bug in theme switching. Sometimes when you changed the theme only the desktop (task navigator, statusbar and home) kept using the old theme – every other (running) application did change the theme properly. Now, the fun starts from realizing the same mechanism was used (update gtkrc file and send a “reread rc files” message to all applications) so it should’ve failed consistently or not at all.
First hints of the bug were seen many months ago, but no one could figure out how to reproduce it. It seemed to come and go at random. After fixing other bugs in theme switching people stopped seeing (or at least complaining about) this particular bug also so we thought it was killed in the process. Turns out it was just on a break.
Recently the bug came back. A manager was able to reproduce it consistently. And still developers were unable to reproduce it with other devices outside the manager’s office.
More time passes and finally the bug was reproduced on another device in a bathroom (don’t ask, I don’t know, I don’t think I want to know) – but once back at the desk where one is equipped to actually debug the issue, the bug can no longer be reproduced.
Eventually it was figured out the bug is triggered when booting up the device for the very first time. Why first boot wizards and whatnot would have any effect on themes made no sense whatsoever, but at least we were narrowing down the problem. While discussing the problem once more, we noted that one of the things first boot wizard does is set the date and time. Right that moment I could already see the problem. And right there it was, so clear in intention, so wrong in implementation. Once tracked down fixing the bug was trivial:
- (statbuf.st_mtime > rc_file->mtime)) + (statbuf.st_mtime != rc_file->mtime))
It was fun, in a slightly twisted sense. Now I just need to figure out what the step 2) is…
- Fix bugs
- ???
- Profit!
View Tommi Komulainen's profile