Developers fix thousands of defects in their careers. However, there are always a memorable few. I thought of listing down some of the interesting bugs I came across so far.
One from the early years of my career. I was working on SMS/MMS protocols during the time, After sending out a few lakhs of messages from one handled to another kept beside each other it was seen that even before the message is sent completely from mobile A it reaches mobile B and the user gets the notification.
It was late night but a challenge interesting enough to keep you awake. After a few hours of debugging it was found that the implementation was using a linked list to which it was appending each new message information at the end before sending it out to the lower telephony layer which would confirm asynchronously once the message was successfully sent. However, on receiving the confirmation, it does some bookkeeping and it was searching the list from the head for the matching message.
Searching through a list of a few lakhs of messages does take time!
This issue was encountered when recovering a device from power-loss. In case of a power loss the device retains all the data in it runtime memory in a persistent memory and restores it. After such a power-loss, there was an assertion because a particular value was seemingly garbage. The value was indirectly derived from a polynomial formula the variables in which were stored in the persistent data after power loss. There was no clue to solve the problem because there was no way to deduce how the value was calculated from the logs of the relevant operation during the last boot.
I sat down with pen and paper and spent hours trying to match the number with the parameters but nothing worked. Then I took a blind shot at deriving the result of the equation with all the variable stored in the persistent memory set to 0. It matched!!!
This revelation uncovered a critical issue where the memory was not restored and the DDR was all filled with zeroes (fresh after cold boot).
This bug was reported in terminal file manager nnn. According to the report nnn was using 100% CPU after it was closed. The original reporter hinted that it was still running in the background. I was unable to reproduce it. later there was another update from another user that the issue occurs when the terminal is closed without quitting nnn. I was unable to reproduce the issue with this procedure either. It was only after some kind user reported the following steps that I could see the issue:
- start nnn in the terminal
- spawn a shell inside nnn
- start another instance of nnn
- close the terminal
These steps helped us reproduce the issue 100% and eventually fix it.
I wasn't directly involved in this defect but came to know about it from a colleague in another department. A hardware developer found that a particular chip works expected if he stands and runs the test. However, the same test would fail if the sits down and runs it.
After a spooky investigation it turned out this had to do with the material his chair was made of!
After 7 days of loud music in a sound-proof room it was found that the music cracks. Multimedia engineers figured after a long investigation that this happens only when playing a particular audio format. The decoder hardware unit had a specific issue that gets uncovered only on wear and tear.
Don't forget to share your buggy experience in comments!