CodeSOD: A Forgotten Memory

Starting in 1985, a tiny little language called Clipper briefly conquered the world. It was a dBase-derivative, with the bonus that its programs could be compiled and run as stand-alone software on MS-DOS. That meant small programs which couldn't justify getting time on a mainframe or a minicomputer could be whipped up to run on a desktop. It was popular, and for about a decade, it was everywhere. Then Windows 95 came out, and Clipper refused to pivot to Windows and became a footnote in history.

It mostly worked pretty great, or at least as great as one of those tiny business-focused languages ever got. Unfortunately for Drake, he encountered some issues in the latter days of Clipper in the early 90s.

Drake's team wrote an image display library for Clipper programs. An end-user of their library complained that it crashed when displaying images. They supplied a sample program that replicated the issue, and Drake and his colleagues were able to repeat the issue.

The core pattern was: allocate memory for an image, display the image, release the memory. Repeat that a few times, and eventually it crashed. There were a few other memory allocations along the way, and they all went through Clipper's memory manager.

So Drake and his team started stripping back their code, commenting out operations until they had a bare minimum program which could replicate the crash. By the time they were finished, the only code left was the code which allocated memory and released it. The simple test case program simply performed a series of memory allocations and releases, and repeated that, printing out the iteration number.

On some machines, the program crashed after 22 iterations. On others, it crashed after 151. It was consistent, always crashing on the same iteration on the same machine. Machines with otherwise identical hardware could end up being in either the 22 or the 151 group. A consistent program to reproduce the bug meant that Drake had something to send Nantucket, the company making Clipper.

Drake explains what happens next:

The interesting part was some of the feedback we got. Our customer service contact told us that our test program had kind of blown up on their internal message board. We were told that some of the developers were complaining that our program was silly, because it didn't do anything with the memory we were allocating.

Doing anything or not, the program triggered its crash consistently. Tempers were flaring on the Nantucket side, and after some increasingly heated back and forth, the customer service contact gently ended the conversation: "We'll get back to you in a few days."

A few days later, there was a solution: the current memory manager in Clipper would be deprecated, and Drake's software should just start using the new one that would become the standard in a future release. This did fix the crash, and so that's what Drake's team did.

We never did get an explanation of why simple memory allocations were hosing their memory manager, nor if they ever fixed it.

Well, arguably, they did fix it, simply by completely replacing their approach to memory management. The actual source of the bug may be lost to time, though I'd love to find out what really happened on the other side of that customer service rep.

For now, though, it needs to remain an interesting historical mystery...

[Advertisement] Otter - Provision your servers automatically without ever needing to log-in to a command prompt. Get started today!