You Would Never Know Where The Bug Is

Screenshot from 2016-07-05 13-21-26

If you can’t reproduce the bug you would never know where the bug is!

I realized exactly the same when I have been working on a bug of Bodhi. We were pretty clueless about why the bug has arrived. After working on it for long I now believe that I am able to figure out where the bug is, Though the work is still going on. But we are pretty closer to it now. The current state is https://github.com/fedora-infra/bodhi/issues/855.

If we were not be able to reproduce to the bug we would never know why the bug had arrived and believe me it was not really identifiable this time! So before working on patch for a bug we should always try to reproduce it first.

Why Reproduce Bugs?

If you can’t reproduce the bug you would never know where the bug is. Patch doesn’t work just on guess. You are expected to be failed to create a patch if you fail to reproduce the bug.

If you don’t go through the steps when the bug is arrived it is technically impossible to create a patch. After you know why the bug has arrived it is possible for you to fix it as well. If you can’t reproduce the bug you need to create a patch just guessing the issue and you are not sure whether it is going to work or not! So it is not considered as a good practice.  Make sure you are not wasting your time on creating patch about which you are not sure.

Good Bug Reporting: Generally a good bug report contains all required info like when the bug has arrived, what was expected to happen and what has actually happened.

There are bugs about what we have no idea why they have occurred neither the users nor the developers. But the developers can always figure it out by reproducing the bug i.e, creating the same situation(In non-technical word). We will now see How Can We Reproduce Bugs.

How To Reproduce Bugs?

Unittest!

Unittest is one of the certain ways in order to reproduce bugs. I will show a simple demo.

We will write a simple program to check whether a number is odd or even.

Write the code:

Screenshot from 2016-07-05 20-57-56

Write the test:

Screenshot from 2016-07-05 20-58-08

Test is supposed to fail since 6 is an even number. Now we will see what happens:

Screenshot from 2016-07-05 20-54-52

Now we know why the error has occurred. In order to reproduce bugs we always want our test to fail.

This is just the fundamental of unitesting on reproducing bugs. You will know more when working on real world projects.

We can use Pdb also. Check this to see how you can use it.

For Bodhi I have used unittest and mock testing. Here is the testcase I wrote to reproduce the bug I mentioned above: https://paste.fedoraproject.org/386958.

Another Way To Push Package Updates To Stable In Fedora-Bodhi

Screenshot from 2016-06-16 23-00-10

Bodhi is a web application that facilates the process of publishing package updates of Fedora. Once a package is submitted to Bodhi it goes through various stages: Pending, Testing, Stable, Obsolete. The details can be found here Package States.

There exist two types of policies in Bodhi, using any of them maintainers can publish their package updates (Pushing updates to Stable from Testing). Updates Policy documentation: https://fedoraproject.org/wiki/Updates_Policy

Updates Policy in Bodhi:

  • Manually push to stable based on time :
    • Auto-karma is disabled.
    • Update spends 14 days in testing.
    • Maintainer pushes the update to stable manually.
  • Automatic push  to stable based on karma :
    • Auto-karma is enabled.
    • Stable Karma threshold is reached.
    • The update is pushed to stable automatically.

The policies above are used to update packages, pushing from testing state to stable state. We could also have one more way to push package updates that Bodhi doesn’t have yet. It could be structured like this:

Manually push to stable based on karma:

  • Auto-karma is disabled.
  • Stable Karma-threshold is reached.
  • Maintainer pushes the update to stable manually.

The maintainers have always wanted this policy to be in Bodhi. There are already two tickets for the same, https://github.com/fedora-infra/bodhi/issues/796 and https://github.com/fedora-infra/bodhi/issues/772

I decided to work on the ticket. We had to remove some major lines of code from the model that implemented the already existing policies of Bodhi. I kept my fingers crossed until the test suite runs with success 😛 And yes it showed  all the tests ran ok ;). Lmacken helped me with continually reviewing my patch and clearing my doubts. The Commit can be found here https://github.com/fedora-infra/bodhi/commit/45f288ae3992d29f3388c627554cc35286a958fb and The PR here https://github.com/fedora-infra/bodhi/pull/821.

Lmacken has always said, “Deleting huge chunks of code is way better than writing more code”. He has guided me to delete that chunks of code :).

I learned it is always good to remove lines of code from your codebase if that doesn’t break any feature. The tweet that always have inspired me 🙂

The code is already merged. Once Lmacken spins up a new release it will get in to staging for further testing. I hope that Fedora package maintainers will be happy soon :-).

 

Why is Testing important?

Why is writing tests for your code as important as writing code for your product?

We write Tests to check/test:

  • If the functionalities of the code you wrote or added are working properly.
  • If the new code you added is not breaking the old existing one.

So it’s better to catch the bugs of your code before it reaches to others 😉 .

I was working on fedora-bodhi for last few days and I chose an issue from there to work on. Though it looked simple enough but it really needed some tricks to solve the bug. The interesting thing is that it was not clearly visible that we have to apply some tricks to solve the issue. And I came to know that I had to apply some tricks after I wrote tests for the code I added.

So the solution for the issue has the following conditions:

  1. When an update of a build in bodhi is ‘pending’ and it requests for ‘testing’ and if that request is revoked, the status of that build should be set to ‘unpushed’.
  2. When an update of a build in bodhi is ‘testing’ and it requests for ‘stable’ and if that request is revoked, the status of that build should be set to ‘testing’.

I pushed a patch for it accordingly and received positive comment from threebean 🙂 . Then threebean and lmacken told me to write test for it, because “Sometimes what we see is not the truth!!” . If you look at the patch it really seemed to work. But when I wrote test for the code I added, the test was failing. As pingou suggested I tried printing some debugging statements to make sure if the test is exercising the code I added. Hence I came to know that the test is not going through the code :|. After struggling for a day I catched that my code was conflicting here which also has action ‘revoke’.

Then I modified my code to solve that conflict and received positive review from pingou 😉 .

Now I strongly feel why writing test is as important as writing code and testing makes you write better code as well 🙂 . The earlier patch was not behaving the way it was expected to behave. I wouldn’t realize that my earlier patch would fall if I didn’t write tests for it and if that patch would be merged the bug would be realized after it reached to masses. So isn’t it a smart practice to catch bug of your code by writing tests before it reaches to masses? 😉

The PR can be found here which is finally merged. Thanks to pingou for continuously reviewing my patches and thanks to threebean and lmacken for encouraging and helping me to write tests 🙂 .

 

Handling Deadlock

This post is all about handling deadlock and what I did to avoid deadlock. This is the first time I have worked on handling deadlock. I have chosen an issue from fedora-bodhi which was about handling deadlock. The error was ”Deadlock found when trying to get lock; try restarting transaction” which is usually common when it comes to database.

Deadlock is an unwanted situation that arises when a process waits for indefinite time for a resource that is held by another process. So there is some way to avoid deadlock or handle deadlock. The transaction involved with the deadlock can either be rolled back or restarted.

try:
    Perform table transaction
    break
except:
    Catch the error
    Try again to perform table transaction

Lmacken guided me with some hints to handle Bugzilla deadlock. Since it was bugzilla server side issue it was not simple for me to reproduce the bug. But it was quite easy to handle bugzilla server-side deadlock. The deadlock was arising when an user was going to add comment to a bug in Bugzilla. So it was definitely a server side issue but could be handled with some little trick in bodhiLmacken told me to catch the fault triggered by the call of adding comment and try again. It was an xmlrpclib.Fault exception. Thus the technique to handle deadlock is the same as declared above. And I was finally done with my patch. Thanks to Lmacken for helping me to solve the bug and understand the technique :).

Hence I learnt how to handle deadlock and my pull request was merged 🙂