Tuesday, June 28, 2011

Best Way Of Exception Handling: SegFault

This week I worked on some list strucks. First one was backgroundIncrustStruct, that holds previous and next pointers, and the variables that composes backgroundincrust. I thought having the list and the class together complicates code too much, so I decided to split it in two. I had some concerns but everything worked out, and I decided to go on, trust the original engine developers.
After trying to do the same to cellStruct, I had a segmentation fault. Splitting a Struct this way creates a huge diff since you have to edit every line that has any use of it to get it to compile, so I had no idea what got wrong.After reading the code several times did not help, I started with running with debug on, but it gave me nothing. Then I tried gdb, to debug the code, and it showed me a line of if statement (if (si->_cell->type == -1)). At first, it seemed odd, since it did not assign anything, but after giving some though, I realise that there was a CellListNode that do not has a Cell, so any read attempt to its members causes segmentation fault. I have go over and over on the code but addNode function creates and assigns Cells for every node. I added some debug messages,that confirmed every addNode run assigning a cell. I read backtraces, that did not help a bit. The cause was so obvious, it was too hard to see.
The only node that is not created by addNode is Head. In both lists (backgroundIncrust and Cell), head created manually, and used for previous and next pointers only so it do not have a object assigned to it. In backgroundIncrustList, methods directly pass head and start working with next node, which was my concern at the first step, but in CellList, methods does not pass head, although it never passes conditional statements that causing an empty first round in the loop. Since I split the CellStruct, the conditional statement tries to read a value from a null pointer, that causing segmentation fault at start of the first loop.
I can fix this with a few lines, just assign an empty Cell to head, but changing this behaviour, and making use of the head nodes is a better solution, so instead of adding and empty object just to prevent segmentation faults, I will alter the method to add and use actual objects to head.

In this few days a lot has happened in ScummVM front. Tiqpit, the other GSoC student has stopped working on is project, and also ScummVM's co leader fingolfin has retired. I wish both of them good luck in their lives..

Tuesday, June 14, 2011

generally, you push and pull, but sometimes, git fights back!

This was my last week of finals, so I expected to speed up, but things does not always work out as you expect, are they?

The problem started when I need to merge the upstream(main ScummVM repository) changes. Updating the master branch was pretty easy since I did not do any changes, only a fast-forward was enough but when it come to rebasing my working branch, things get complicated.

I did not realize that until my mentor Johannes Schickel warned me about it. There was a merge commit that merges my working branch with itself. It took some time before I find out what got wrong, and it was indeed the rebase. I am still not sure how it happened, but when I rebased, git didn't remove the old commits, yet still added new rebased commits to history. There was double commits that were identical, except parent commits, and git merged them on the branch they are.

I used interactive rebase and manually removed old commits, also used a force push to fix history on github. I know force push is unpleasant but in the end, everything sorted out as they should.

Sunday, June 5, 2011

With The First Commit

I have pushed my first commit to github this week.Althought it seems quite big (~300 lines), it is variable rename mostly, no real coding was done. Even this commit made working easier, experimenting is fun, and it makes me feel that I am making progress.

I am going to modify some smaller files this week to speed up, and hoping this way I can clear my way of thinking about objectification a little more. Getting small parts done also can make further modifications smaller, and easier to understand when anybody wants to study them.

I am also thinking about writing down a new schedule. Since I changed my approach to project, my old timeline is useless for first 7-8 weeks at least. Having a schedule, and milestones, deadlines for that milestones helps keeping motivation high.