Last day until RunRevLive.14 kicks off in San Diego. Get Your Ticket >

Fixing Bugs

The in-app purchasing feature I was working on during the previous months is now finished, and is available in LC 6.7 DP1. So, in the meantime, before moving to a new project, I had the chance to do some bug-fixing. It was my first exposure to bug-fixing, and I have to admit that it was more interesting than I imagined! To begin with, I started browsing our bug database in the Quality Control Center. The steps for fixing a bug are three:  reproduce – find where it comes from – fix!

 I thought that as a beginner, I should start with something relatively easy, so I tried to sort out some crash-related bugs. I believe these are easier to fix, or at least easier to reproduce and find the exact line of code where the crash occurs. This can be done by trying to run LC in the IDE with the debugger active and see what line of code it stops on. Well, this isn’t necessarily the line that contains the bug, but you know you are close! If you step backwards, you will find where the actual bug occurs. Using this method, I fixed a couple of bugs. Not surprisingly, modifying the same single line of code, fixed three different bugs that at a first glance  seemed unrelated.

The next category of bugs I tried to fix were the “platform-specific ones”. In this kind of bug, the LC functions that were reported to misbehave, usually communicated with particular System functions that were deprecated. The fix to these bugs required more time. I had to search the web for the new up-to-date System functions, and replace the deprecated ones.

After that, I felt I was ready to face some harder bugs! I tried different categories, android orientation-related bugs, engine architecture-related bugs, engine objects-related bugs and some more. When I could not fix a bug, I tried to post a helpful comment or provide a workaround. In any case, either being successful in resolving these bugs or not, I enjoyed it because it gave me the opportunity to gain a deeper understanding on how the engine works. Moreover, I was impressed with how much attention to detail the LiveCode users that reported some bugs pay! I remember a bug where the user had reported that in a specific version of LC, the “unlock cursor” command delayed by one(!) pixel, meaning that when you unlock, the cursor had to be moved a pixel (at least) for the change to take effect. Impressive!


Tags:


Discussion

  1. Gavos

    Panagiotis apparently you ‘ve missed to mention the most widely used bug-fixing method. The act-like-it-didn’t-happen-and-let-others-do-the-digging technique. You may find it hard at the beginning but time permitting you ‘ll get to refine this technique and eventually become the ultimate bug fixer

    Hats off to anyone enjoying the painstaking procedure of bug fixing. I can’t think of no other chore comparable whatsoever.


  2. Dar

    Workarounds are important.

    If the bug fixer notices one and the next release is some time off, then a mention in the bug db is nice.

    This also goes for bug reporters or others who find it as the bug they are about to report. Except for bugs in preview software, I try to include a workaround or an idea for a workaround in my report. And I appreciate it when reporters mention a workaround. Even just a one sentence concept or hint is plenty.


Comment