gtg team mailing list archive

[Thibault Fevry <618146@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

[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 :/ ]

** Affects: gtg
     Importance: Undecided
         Status: New

-- 
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 :/ ]