[Pkg-amule-devel] Bug#760434: Bug#760434: amule: unusable GUI

[Olly Betts]

On Wed, Oct 15, 2014 at 11:01:39AM +0100, Sandro Tosi wrote:
> On Sat, Sep 13, 2014 at 5:10 PM, Olly Betts <olly at survex.com> wrote:
> > There are two big changes between 2.3.1-11 and 2.3.1+git1a369e47-1 - one
> > of them is indeed the switch to wx3.0, but the other is a switch to an
> > upstream git snapshot of amule.
> 
> the switch to the git snapshot was done because it seemed to include
> supports to wx3.0 in the unreleased code.

Sure - I just wanted to distinguish which change the apparent memory
leaks were due to.

> Is there any chance you can give us a hand in fixing amule to support
> wx3.0? Upstream has only partially ported the code to it, and they are
> not actively working on it atm.

I'm happy to try, but I'm not an amule user and couldn't reproduce the
large increases in memory usage when I tried before, which makes it hard
to do much.
 
> IT would be a shame to ship Jessie without amule, but i dont have the
> resources to port amule to wx. I can consider getting back to 2.3.1-11
> instead of the git snapshot if that makes the effort easier.

I think the git snapshot is a reasonable base, since Dmitry said that
the git snapshot with 2.8 didn't reproduce these issues.

I just tried installing amule and amule-dbg and running amule under
valgrind to see if there are leaks, and there are loads of small ones
- it seems plausible that some of these are causing the problem if they
happen more when you're using amule more actively:

valgrind --leak-check=full --num-callers=20 amule

I picked an arbitrary one which was actually directly from amule code:

==11410== 9,150 (144 direct, 9,006 indirect) bytes in 1 blocks are definitely lost in loss record 11,950 of 11,997
==11410==    at 0x4C29180: operator new(unsigned long) (vg_replace_malloc.c:324)
==11410==    by 0x486A99: CClientCreditsList::CreateKeyPair() (ClientCreditsList.cpp:259)
==11410==    by 0x486F9D: CClientCreditsList::InitalizeCrypting() (ClientCreditsList.cpp:306)
==11410==    by 0x488873: CClientCreditsList::CClientCreditsList() (ClientCreditsList.cpp:54)
==11410==    by 0x46EA0D: CamuleApp::OnInit() (amule.cpp:508)
==11410==    by 0x53A1D6: CamuleGuiApp::OnInit() (amule-gui.cpp:287)
==11410==    by 0x7030C41: wxEntry(int&, wchar_t**) (in /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0.2.0)
==11410==    by 0x4420C1: main (amule-gui.cpp:93)

Looking at the code, that's the allocation of privkeysink here:

        CryptoPP::FileSink *fileSink = new CryptoPP::FileSink(filename);
        CryptoPP::Base64Encoder *privkeysink = new CryptoPP::Base64Encoder(fileSink);
        privkey.DEREncode(*privkeysink);
        privkeysink->MessageEnd();

        // Do not delete these pointers or it will blow in your face.
        // cryptopp semantics is giving ownership of these objects.
        //
        // delete privkeysink;
        // delete fileSink;

Seems the comment about not deleting privkeysink is wrong, but I don't
know anything about CryptoPP's semantics.  But if this is only called
from the app's OnInit() this may only actually get called once per run,
so probably isn't going to make much difference.

I'd suggest that someone who's seeing the memory usage issues should run
under valgrind as above, and pick out the larger definite leaks to look
into.

Cheers,
    Olly