Check kmess 2 for memory leaks

[diederik]

To make sure it's not forgotten: we need to test KMess 2 for memory leaks using valgrind.

Try every dialog, pressing ok, or cancel, chat, etc.. and see where the leaks are coming from.

[valerio]

I've received the report that KMess2 SVN (r3430+) eats a lot of RAM while doing file transfers.

[sjors]

I've been doing a lot of checking with valgrind and fixed a lot of memleaks. I can't check every situation, but did a basic chat with custom emoticons etc. (Setting to major because I fixed many of them, only some checks are still needed.)

The file transfer high memory footprint is probably because of the networking window, I need to look into not logging every normal file transfer packet or so. That'll probably fix most of the huge memory increase. Also, in the webcam transfer I took care in not letting the buffer grow indefinitely throughout the session; I'm not sure if this happens like that in P2P file transfers too. Diederik? ;)

There are a *lot* of memory leaks in Qt, fontconfig (13 mb?!), libICE, et cetera. I don't think we can do anything about those except for bugreporting them if the bugreport is anything useful... :)

[sjors]

Fixed a few more in r4528 (previous ones were r4511 and r4512).

[diederik]

Reporting memory leaks seams like a good idea to me :-)

As for file transfers, I never really cared about the network window, since it's for debugging only. However, applying some limits would be useful.

Idea's: - after 10 continuous packets with a "file data" flag, stop logging until something interesting happens, or the transfer is at the last 10 fragments of the file. - Have a checkbox in the network window to explicitly enable capturing, - together with a command line switch to enable it at startup directly

[sjors]

I think any work we can do about this now will be rendered useless by the new P2P stack in 2.1. The memory leaks in p2p code are, in my opinion, not important enough to delay 2.0 any longer. I'm moving this bug to 2.1... please move it back if you disagree :)

[sjors]

As soon as the new network library works, it will be much easier to test it for memory leaks. Also, it will be easier to test *only* the GUI for leaks, with a fake library attached to it. :)