Well it’s been about a week running Lenny and its mostly all good. But I found one program had a problem with it. Interestingly it was a program I wrote myself. It’s this C based program that opens multiple download threads … etc. My most recent version seemed to run fine on Etch … but in Lenny it had some weird bugs.

Problem one was that on maybe 80% of occasions (ie. not all the time), just after startup my program would crash with a ‘glibc double free’ error. It spat out a stack trace that wasn’t much use to me. I’d never seen these double free errors before so I assumed they are something to do with the new glibc used .. OR could be some debug stuff that is in Lenny (since technically it hasn’t gone stable yet … its just a release candidate).

So I google for ‘glibc double free’ … and well you can try yourself … but google returns a zillion results all of people having these errors…. with not a lot of solutions offered. I did work out that it means that a program tried to do a free() on a block of memory twice. I summarily checked all my free() calls and didn’t see anything bad. I then played with gdb a bit … which did’t really help. My program is multi-threaded and I’ve never really worked out how to use gdb to effectively debug such a program (I should probably learn). So then I added lots of printfs to try to narrow down where the crash occurs (and keep in mind the crash doesn’t happen all the time).

So it seemed to start one or two threads and then die shortly after the 3rd thread started. All these download threads run identical code. The bug (I think) related to some openSSL initialisation code early in the thread. My download threads can make either clear text socket connections to a server … or SSL based ones. I had some lines similar to:

connection.method=SSLv23_client_method();
connection.context = SSL_CTX_new(connection.method);

But these were being run regardless of whether an SSL connection was going to be established. I added an if statement around these to only run them for SSL connections and voila … no more glibc errors …. well none that I’ve seen.

Weird eh? I did find there is an env variable you can set to turn off all this double free checking;

export MALLOC_CHECK=0

Problem two was that the unrar program provided with Lenny is a fair bit newer than the one in Etch. My program behaves like ‘expect’ forking unrar and watching its output and prompts and responding appropriately. Of course, the text output of the newer unrar (3.80 beta I think) is slightly different to the one in Etch. Suffice to say I had to rewrite some of my ‘expect’ code and finally it works again.