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

Bug #618146 reported by Thibault Févry on 2010-08-15
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Getting Things GNOME!

Bug Description

[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) wrote :

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.

summary: - Task with big attribute content causes a huge memory use...
+ Task with big attribute content causes huge memory uses...
Luca Invernizzi (invernizzi) wrote :
tags: added: leak
Changed in gtg:
status: New → Triaged
importance: Undecided → High
milestone: none → 0.3
Luca Invernizzi (invernizzi) wrote :

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.

Changed in gtg:
status: Triaged → Confirmed
Thibault Févry (thibaultfevry) wrote :

 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) wrote :

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.

tags: added: taskeditor
Izidor Matušov (izidor) on 2011-08-12
tags: added: editor
Izidor Matušov (izidor) wrote :

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/

Izidor Matušov (izidor) on 2012-06-07
Changed in gtg:
milestone: 0.3 → 0.4
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers