Software at the Toddler Stage

By Jakob Engblom

Developing software is an adventure where you explore the unknown, one line of code at a time.  At some point, the program reaches the stage where you can actually run it and try it - and that's where the real fun begins.  The software will sometimes behave as expected, but more often than not it will not. It will do something else, or crash, or generally do the wrong thing.  It is very much like a toddler - you can rely on it to some extent, but you never know when it will decide to do something unexpected, funny, or just throw a fit over something that would have seemed inconsequential.

I have spent quite a bit of time recently with toddler stage of Simics 4.6 (prereleases and betas).  The end result is really good and qualifies as an adult specimen (as discussed previously on this blog), but there was a lot of entertaining (and frustrating) things that went by as Simics 4.6 was a toddler. All software developers have stories like these to tell, but I just wanted to share a few of the funnier ones and give a glimpse of just how much work it is to get something like Simics running.

My favorite issue was the strange memory allocation happening in Eclipse on 64-bit Windows host.   When I opened the Simics timeline view, the Eclipse process grew by exactly 4 GB plus 4 bytes.  When I closed it, the memory was deallocated, all nice and tidy.  It worked perfectly well on all other hosts.  It turns out that the reason was that our magnification slider (see picture) used a Windows widget that when running in 64-bit mode allocated exactly 4 bytes for each step of
the slider.  Since we wanted a slider that could handle a very large data set as the worst case, we had set it to allow 1 billion as maximum value.  Reducing this to a few hundred thousand allows
for sufficient resolution and causes no memory issues.  One still wonders why Microsoft made the widget behave that way.  I guess it just wasn't tested for anything but a volume control with 11 steps or something.  Once again, users violate the assumptions of software designers.

In another case, the debugger got a bit confused about endianness, and managed to display some variables as BE and others as LE. In the same view, for the same target program, at the same time.  Gave me a good laugh seeing it and diagnosing why some variables with the value "1" were shown as 16777216. I am a nerd at heart, I admit.  A bit like a child writing letters backwards as they learn to write.

The Simics toddler also was confused about directions sometimes. Pressing the "reverse" button instead made it go forward.  Pressing "stop" when it was stopped also made it run forward, which was a bit more surprising. All was easily sorted by wiring the right buttons to the right functions.

All software developers have many stories like these to tell, and it underscores the continued importance of creative and intensive testing.  Many issues do not show up until you start to put all the pieces together, and that aspect of integration testing is one of the main uses of Simics itself.

 

Comments

[qwerty]

Nice story.
The nice thing about software is that it does the same thing over and over again without problems. That is if it programmed well in the first place.
When validating a ready to ship solution all advertised functions should be extensively tested.

Simics seems to be a nice solution validating tool that was long overdue in software development.
P.S.
If I am on an hospital bed I would rather see the monitoring devices malfunction and break than myself :D