Task with big attribute content causes huge memory uses...

[Thibault Févry]

[Using the last version of GTG, Don't remember exactly if it was from the source or daily PPA, still quite recent. Running Ubuntu 10.04. Running in debug mode won't help, it's not a crash.]

 Actually I had a bug when tryng to register a very, very big string in one task (This means ~30600 char...). I know it may seems strange to do so big copies for a task, but the problem isn't really there.
 The problem is that making this task uses 35Mb and 100% Cpu (I've a dual-core 3.16 Ghz).
 This doesn't happens if you make 12 task of 2550 (Means buffer overflow? Don't know...)

 I think they're 3 solutions:
 - Disable strings that are too long (+5000)
 - Save to file if len(Task.content) > 3000, perhaps less faster, but less bugs...
 - Same solution than 2 but add a feature when reading, display task content progressively. ( Task displays 1000 char, user clicks on some button [more], task displays next 1000 char...)

 I don't know how severe the bug is, for the user it's not very important, but if this bug can be reproduced with DBus, this would allow to crash the application from another app. (Something like print "Task" * 100000 > dbus could theoretically crash the app.)

 I'm not sure this can be considered as a security vuln, so not setting as.

[Sorry for my bad english :/ ]

[Thibault Févry (thibaultfevry)]

Also, another thing, if you succeed to delete that 30600 char task, the memory is not free directly, you must close the app...

 Perhaps manually deleting (Not using Python GC) like del Task.content would be a solution.

[Luca Invernizzi (invernizzi)]

possible solution reported in https://bugs.edge.launchpad.net/gtg/+bug/619603/comments/8

[Luca Invernizzi (invernizzi)]

If someone is willing to do this, please discuss here the implementation idea, since I have a couple of ideas on how this could be done to play well with backends.

[Thibault Févry (thibaultfevry)]

 Just sayng, we could do at how this is done by some other editors, like Tomboy (even if it's not python), that don't have this problem, in fact there you can copy 10000 char tasks and the memory doesn't raise so fast.

[Lionel Dricot (ploum-deactivatedaccount)]

I agree with Thibault : before anything, we should investigate how other editors are working.

This could be part of a big refactorization of the task editor. As the task editor is well separated from the rest of GTG, I think it could be a good objective for someone to make such a branch.

[Izidor Matušov (izidor)]

An article from hamster project can be useful when working on this bug: http://projecthamster.wordpress.com/2012/04/07/fighting-unlinked-references-that-lead-to-memory-leaks/