![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
A step-by-step guide to debugging.
1. Do some simple checks and see if it was something obvious.
2. Make a list of everywhere the problem could conceivably be.
3. The bug will be somewhere in the difference between that list and reality.
OK, that's an exaggeration, sometimes the bug is where it should be, but sometimes it really is a matter of "what unexamined assumptions have I made, and which is most likely to be wrong?"
1. Do some simple checks and see if it was something obvious.
2. Make a list of everywhere the problem could conceivably be.
3. The bug will be somewhere in the difference between that list and reality.
OK, that's an exaggeration, sometimes the bug is where it should be, but sometimes it really is a matter of "what unexamined assumptions have I made, and which is most likely to be wrong?"
no subject
Date: 2013-01-10 10:54 am (UTC)no subject
Date: 2013-01-10 10:56 am (UTC)no subject
Date: 2013-01-10 01:51 pm (UTC)no subject
Date: 2013-01-10 02:04 pm (UTC)no subject
Date: 2013-01-10 02:15 pm (UTC)no subject
Date: 2013-01-11 01:48 pm (UTC)no subject
Date: 2013-01-10 08:52 pm (UTC)D
no subject
Date: 2013-01-13 01:29 pm (UTC)no subject
Date: 2013-01-13 01:33 pm (UTC)In fact, it happened twice. The first time, because the flag we used to toggle the code on and off was being used by something else, which made the whole program not work whenever the flag was turned on. And the second time, because the make system was set up so the #defines worked in the simulator but not on the real code. Afterwards, I resolved again to ALWAYS make sure that the code you wrote is happening, however certain you are... :)