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. -- Task with big attribute content causes a huge memory use... https://bugs.launchpad.net/bugs/618146 You received this bug notification because you are a member of Gtg contributors, which is subscribed to Getting Things GNOME!. Status in Getting Things GNOME!: New 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 :/ ] _______________________________________________ Mailing list: https://launchpad.net/~gtg Post to : [email protected] Unsubscribe : https://launchpad.net/~gtg More help : https://help.launchpad.net/ListHelp
