Friday, July 12, 2013

Tip: enter the mindset of tracking bugs

Having a good tracking of bugs helps a lot. People can easily search for previous bugs, help other people commenting the possible causes and have a clear understanding of the support workforce needed to solve the issues.


Unfortunately, not everybody tests his/her code. Testing is fundamental to facilitate debugging and quality check of you software. No matter what is the dimension of the companies, there are simple step you should always have in your workflow:

-Precommit test: small subset of test that check the main functionalities of your software. It has to compile your code with all the possible configuration allowed to be used but the complete execution should not be longer than 30 minutes.
-Nightly test: bigger subset to run it in the night
-Weekendly test: typically an huge set of tests are run here to stress your code.

It's important also that all the main branches that are going to be released are covered by this tests.

Tip: Compare different branches

If you work in a company with a structured workflow and source control, you can really helpful to compare different branches of the same project between them. Happen to me that I spent 3-4 days working on a test issue that turn out to be solved in the main branch of development. So compare the failing code with another one, or previous revision if the failure appeared only recently, can be a good starting point.

Tip: Don't trust your assumptions

Everybody have assumptions and most of the time we think that those are satisfied. But sometimes that's not true and double-check them is always a good step if the problem seems to rely on magic (but magic doesn't exists)

Wednesday, July 3, 2013

Tip: we are not alone

This is a technical tip that can help when we join a project and something goes wrong but all the code seems clear. Happen to me ones that I was executing two print of the same variable within a distance of few lines and no line was modifing this variable. While I was expecting the print to be the same, I was continuosly get two different values. I spent a lot of time trying to find if was a memory corruption but in the end the issue was due to thread scheduling that overwrites the variable. When we debug, we can have the impression that a single thread is present, but most of the time is not. Even worse if when (as in this example), debugging the program will make the issue disappear due to changing in timing. So basically, if you suspect that multiple threads can run because you don't know perfectly the code, it's always a good idea to instrument your debugging printf with the thread id of the process. In this way you will see more clearly which thread is writing on the console making you understand better how the threads are scheduled.

Tip: Explain to others your finding

The first tip is a general tip that applies to mostly every field where you need to solve a problem. Basically sometime you really need to explain the ideas of a possible solution to someone to really understand it yourself. This can also work using writing but of course the colleague can give you also useful input and ideas. This helps mostly people that like me have a general picture of the whole system but with a not clear knowledge of the specific code we are working on due to inexperience with that code. People that like me prefer a picture rather then a text explaination tend to use more the side of the brain typically used for artistic and visual skills. Unfortunately programming is not a visual rappresentation of an algorithm but a sequence of logic steps. Forcing yourself to explain or write down what's happening in the system helps to convert the wide but opaque visual image you have in your brain to a more specific logical view where all the connection between elements gets explained. It will be like seeing a painting from the distance and discover that is actually a mosaic when we move near to it, where small pieces are connected together to form a single shape.

Tuesday, July 2, 2013

It's doing the wrong thing but everything looks fine....seems magic!!!

I'm working for 1 year for a big company in the embedded engineering field and I have faced some bugs that make me tell to colleagues: "It's doing the wrong thing but everything looks fine....seems magic!!!".
Unfortunately or not, there is no magic. Everything happens from a reason and there are few many cases where this is due to HW issues. Often the bug depends on particular time or configuration that makes it appear or disappear simply adding a safe printf. Also a stressfull day is not the best friend when facing these issues and probably it is better to have a break or simply tackle it the day after. In this way, all the "polarization" your mind has about how the things are (not) working are kind of released and a fresh mind can easily find new views of the problem. Asking for help is also a good way have a new point of view and ideas to solve the issue.
 I will publish time to time some "tip" about what to look at when facing a difficult bug and how to approach them, hoping that sharing what turned to be my solution can help someone on their debugging journey.