For those who are wondering: I have started my new job. I am a visions systems engineer in the robotics and automation divison ofÂ Scott Technology. Specifically I’m dealing with the automation of freezing works. This means my job involves:
- Robots with spinning blades.
- Interfering with sheep.
Two of these are actually mentioned in my job description.
Just on the 2.24 code freeze a memory leak in the trash applet was pointed out to me. The proposed patch was simple:
} g_object_unref (icon); + g_object_unref (info); } static void
It came from a trusted contributor. I checked that the the info variable really did need unrefing. I ran it past the release team to get their approval for a freeze-break. So I applied the patch and sent 2.24.0 out the door.
The one thing I didn’t do was test the applet thoroughly with the patch applied. If you run the trash applet from 2.24.0 and empty the trash from the context menu then it will crash a few seconds later. Fortunately for me, by the time I woke up and got the bug report in my morning email, the team of Pedro Villavicencio, Sebastien Bacher and Matthias Clasen had identified the root cause of the problem and the fix was tested and committed to SVN by lunchtime. (Vincent Untz rolled a 18.104.22.168 just in time for the official GNOME 2.24 release.)
So what went wrong with such a simple patch? The fix for the memory leak looks correct – and it is. The problem is the line above it: g_object_unref (icon);, icon is an object that should not be unrefed. The leaked info object was somehow protecting it from being overwritten once freed and the other code relying on it would go on quite happily. With the fix applied, the icon object was being overwritten and a segfault occurred the next time it was accessed.
There are two morals to this story: The first is that there is no such thing as a trivial patch. The second is that testing is essential: either by doing it in an automated way or by farming it out to all the people prepared to run beta versions. There are various stupid reasons why applets are hard to test, something I intend addressing in the coming release cycle, but my most immediate resolution is to respect the code freeze for everything that isn’t actually causing a crash (I fully expect to have forgotten this in six months time).
For my family, more photos. The photos are now in two sections, the first part is the same as the photo-set that was previously there, the new photos are all in part II.
For my family, the first four days of Anya’s life in photos. Its one big page with all the photos, so be warned if you’re on a slow connection.
My daughter. Born at 5.13am, weighing 1.9 kg and 6 weeks premature. Mother and baby are doing well.
Rage! – Anya at 30 minutes old.
The labour was fast (four hours – this is a first child) and went well despite Anya coming bum first. At six weeks premature, Anya’s in the newborn intensive care unit, but she’s breathing unaided and is suffering no problems other than the normal ones for her age.
Thanks to the superb work of Matteo Zandi the invest applet has undergone some major improvements. If you ever worried about the strange grey square, then the next gnome-applets release if for you.
- The stock-health indicator has been integrated with the main icon, it now looks better and takes less space.
- Spark-lines show recent activity.
- Non-US stocks have better support.
- Column headings are now printed: you don’t have to guess what the numbers mean.
- You don’t have to right-click in exactly the right place to get the menu.
Matteo has more improvements in the pipeline, but for now here are the before and after shots.
This pram was the first serious thing we purchased in anticipation of Anya’s arrival. Since I’ve finally downloaded the photo off the camera I thought I’d better let my mother see it.
The first thing of any sort we purchased for Anya was a strange woolen clown that everyone thinks is an octopus. The arms and legs are crocheted spirals that look suspiciously like tentacles. I don’t have a photo yet.
Just over three weeks ago, World45′s sole investor decided to cut his losses and close the company. From his perspective I suppose this made a lot of sense, but it was rather sudden. The ironic bit is that I think we’d finally figured out how to get the company to the break even point. Unfortunately, the mistakes up until that point hadn’t given him a lot of confidence. At the end of the day it was his company and his choice.
There is hope for a World45 Mk II. Mariusz and Lipi are going to pick up the contracts we had lined up and World45 (2008) ltd. looks like it will rise from the ashes. It will be leaner and won’t have a lot of money behind it, but we’ve got a good source of contracts to form a base to our work. If you’re looking for experts in multi-core programming and optimisation: see www.world45.com (that bit about “we’re hiring” on the front page – probably a lie, but we might be able to find work for the right person).
Personally, I’m back in employment next week – working as a research associate in the local physics department. Back to lasers, atoms and PhD students. It will be a fun, but temporary, diversion. In the meantime I’ve been painting the house, preparing for the baby and doing all the odd-jobs that I’ve put off. Unemployment is hard work.
Do you fancy a bit of a challenge writing low-level C code to go as fast as possible on multi-core machines in a bare-metal sparc environment? Or do you like kernel hacking (Solaris and Linux)? Then we have the job for you at World45. Details can be found at www.world45.com. The catch? We want you to start soon, and we’d like you to work in Dunedin, New Zealand. If you can’t handle either of these conditions feel free to send in a CV anyway; we’re often looking for people for contract work.