I was talking to a friend 3 days back and I was telling her how important it is for us to keep on learning new things. In fact it is one of my worse fears that I’ll be out-of-date someday and will not be compatible with the modern day world.
While advising her to start learning some thing new, I thought I can start acting on the same advice as well. So here’s my new year resolution, even though it’s coming a little late. I am going to learn new things this year. And this space is going to keep a diary of those smaller or bigger learnings.
It involved a crash with 32 bit optimized build of an executable which was running fine with 32 bit or 64 bit debug build and even with 64 bit optimized build. No crash with debug build, hence no debug symbols! I started printing out logs “inside this function : All looking good”. This exercise led me to the culprit function. Nothing outrageous was happening inside this function. A few more printf’s led me to the line where the crash occurred.
my_list *pList = NULL;
my_container->list = pList;
std::cout << "Size of list " << size ; // And here it crashed
Points to be noted here -
1. Valgrind didn’t show any memory error in this area of code.
my_container->list. In fact they didn’t make any change at all to
3. At the point of crash, the value of
my_container->list was different. While
my_container->list had the same value it was assigned, the memory address pointed to by
pList was showing some junk value. Conclusion –
pList got corrupt somewhere. But how could it be possible?
Initially, my guess was that the compiler optimized away the local variable pList. If that is the cause, then why didn’t 64 bit optimized build fail? Or how can such a trivial bug happen in gcc? Therefore it was an utterly wrong guess.
Anyway, I made a temporary fix by replacing the crashing line with -
std::cout << "Size of list " << list->size ; // And here it stopped crashing.
Only it was not a fix exactly. Some memory address got corrupt and I avoided accessing it by accessing some other memory address containing the same value.
So how did I find out the problem?
I attached to gdb an optimized build which was not stripped off symbols. gdb has a handy command
disassemble which I used to ‘diassemble’
The native code displayed by the
disassemble command showed that the compiler inlined
call_some_func(). I could get the memory location at which variable
pList‘s value was stored. You can locate it in the native code by looking for nearby function calls which the compiler didn’t optimize. And then try to correspond the native code with actual C/C++ code. There is no formula to do this but only comparing the C/C++ code and the native code and trying to figure out which lines of native code correspond to which line in C/C++ code are the only ways.
But this didn’t tell me how the variable pList got corrupt. What I needed was a watch on the memory location that stored the pointer
pList. I ran the executable in gdb and around the line
initialize_list (&pList); I started printing the native code.
The command I used -
x /10i $pc <-- This prints next 10 instructions.
To clarify things,
pList is a pointer to an address where the list is stored.
my_container->list points to the memory location where the field list of the struct my_container is stored.
For the line
"my_container->list = pList;", there would be instructions to move the value from one register to another. One of those registers would contain the memory address at which the list pointed to by the pointer pList is stored.
Once I got the memory address that stored the pointer pList, a
watch on that memory address revealed that a static buffer overflow caused the corruption. It was done by an
The bottom line is if you get a spooky crash and do not have a debug build or can not reproduce it in a debug build, do not panic. I was lucky to get some pointers on debugging assembly code from this guy. What the whole experience taught me was – make use of gdb as much as possible. Here's a list of a few handy gdb commands.
The Indian Express published an article on women who are passionate about technology, gaming among other such things. Focus on this topic is rare in India and I was happily surprised when Shobha contacted me and asked for my views to be included in the article. Here’s the link to the epaper. Enjoy!
Gnome 3.10 is released and it has some cool features. It feels good that Geolocation and Maps application are part of it.
I wrote the client and server for GeoIP based GeoLocation when I was doing my OPW internship with Gnome Foundation. Initially the libraries were part of geocode-glib, but the code for GeoIP has been moved to GeoClue.
And that reminds me (quite shamefully) I have been sitting on the Wi-Fi code for a long time. It’s time to get that code out.
A couple of firsts! My first time at GUADEC and my first trip abroad as well. And guess what! It was also a first time for GUADEC where it saw 18% women participants! All thanks to wonderful programs like Outreach Program for Women and GSoC internship.
Overall, it’s been a nice experience at the conference. For people like me who are new contributors to Free and Open Source Projects, the talks opened up new avenues. Anish Patils’ talk on Predictive Input Methods, Jeff Fortin’s talk on PiTiVi, Srinivasa Raghavan’s talk on Evolution, Juan Pablo Ugarte’s talk on Glade were some of the many that I enjoyed.
The lightning talks were wonderful too. Imagine within a span of an hour and a half you get to hear about a lot of interesting stuffs. The interns talked about their projects (where I too presented about my internship project). In another session there were presentations on topics like typeface designs, Terms of Conditions Didn’t Read project among others. I almost felt like standing at an icecream parlour and having difficulty in choosing what to eat since there are so many lovely flavours! You can check out the videos from here if you are interested.
And not only the talks, the conference gives one a chance to meet people whom one has never met before. And even though internet has helped us bridge the physical distances, face-to-face interactions do help to build up rapport with the person with whom you are collaborating or about to collaborate.
Photo courtesy: Ana Rey
Reached late on 1st August. Brno came out to be hotter than expected. (Why did I even think of bringing a pullover!)
Liked yesterday’s session on sandboxing application for Gnome by Lenhart Poettering.
Now ebassi’s talk on GTK scene graph is going on .
Oh Uh! Started volunteering for the GUADEC from today. And Aruna brought good news that we will get a few minutes at the AGM of Gnome Foundation today to speak about WFS!
Life is good except for one thing. D.C – are you listening?