libpurple crashing since 18 months

[Felipe Contreras]

On Wed, Mar 25, 2009 at 5:39 AM, Thorsten <sendmail at gmx.net> wrote:
> I am tired and frustrated. I am using libpurple since 18 months for a
> chatbot - which is a fun-project - and since 18 months libpurple is
> constantly crashing. And with every new version it becomes more worse.
> And I am tired of filing bug reports to the bug tracker and nothing is
> happening.
>
> Except AIM, all protocols do crash. The MSN protocol is the worst: it
> crashes immediately when connecting. I looked at the sources and they
> are ugly. It seems some people have never heard that pointers can become
> NULL or that there might be side-effects in the code and that functions
> can return bad values, in addition it looks like there are also memory
> leaks. Of course my chatbot stresses libpurple by having many
> conversations at the same time and thousands of chats per day. But in
> fact it just reveals the bad quality of the libpurple code.

Completely agree.

The MSN prpl is for the most part my fault, at least msnp9. However,
that was many years ago. I have increased my coding foo, and now I
realize how many stupid design mistakes I made.

I tried to improve the code but the Pidgin developers didn't allow me,
so I made a fork, msn-pecan[1].

I've made a lot of progress reorganizing the code, but there's still a
long way to go, and in the process I've introduced some nasty
regressions. Fortunately I've started some unit tests, and soon I'm
going to start some system-wide tests that I hope will help me track
those issues.

As an example I point 'msn_session_find_swboard' which in libpurple is
implemented with linked lists, which is error-prone, unintuitive, and
hard to maintain. In msn-pecan I re-factored the code to use hash
tables, which is nice, clean, easy to understand, maintain and debug.
Well, actually it's a separate branch as I'm not done testing it.

You can read in my blog how it has progressed[2], but for a quick
comparison on the *before* and *after* mess of the code look at these
diagrams:
http://felipec.wordpress.com/2008/01/27/msn-pecan-006-released/

> I am willing to assist as much as I can, but I have no interest in
> wasting my time by filing reports to the bug tracker and no one cares or
> cares after 4 months without any progress. Since my bot stresses
> libpurple, this is also a chance to reveal all weaknesses of libpurple
> and to make it bug-free. Every responsible programmer is welcome to
> contact me and to discuss bugs, backtraces and the values of parameters
> and variables with me in-depth, so the bugs can be fixed as quickly as
> possible.

The problem with Pidgin's tracker is that there is no visibility, you
can't see how many bugs have been actually fixed, which are crashes,
there's not even a priority field.

On the other hand in msn-pecan's issue list you can clearly see there
are only 36 active bugs, you can see which are marked as critical
(crashes and other really important stuff), or high priority, and
people can even vote on them.
http://code.google.com/p/msn-pecan/issues/list

You can also see that 47 have been marked as fixed, 14 as verified. On
the other hand Pidgin's tracker doesn't have a concept of 'verified',
in fact, bugs marked as pending go to 'closed' state after two weeks,
not even 'invalid', and so does duplicates, so good luck finding their
bug-fixing performance.

If you report bugs on msn-pecan, they *will* be fixed eventually, and
the more information you provide, the faster they'll be fixed.

[1] http://code.google.com/p/msn-pecan/
[2] http://felipec.wordpress.com/tag/msn-pecan

-- 
Felipe Contreras