Lots of tasks in tasklist cause crash on startup: Creating pipes for GWakeup #294
Comments
That's a lot of tasks - you must be really busy! 😄 To track this down, the following information would be usefull:
In addition, can you post the output of the following commands (of course without sensitive information if there's any)? export G_MESSAGES_DEBUG=all
io.elementary.tasks |
|
Thank you for your reply. That debug log is helpful. I won't upload it here as it contains too much sensitive information, but it appears that Tasks already crashes on trying to load the first task list/calendar (my task inbox "Eingang") which contains 6 active and 1165 completed tasks. It seems to me the main problem is that Tasks tries to apply those watches even to the completed tasks: Counting all of the lists I'v got about 35 task lists and 17 regular calendars in addition (which seem to be displayed as task lists as well). In all of the task lists I've got about 133 active items and some thousand completed tasks, but I've got no app that counts them. ;-) I think it would be of great use if Tasks would detect which CalDAV containers only contain calendar entries/appointments and won't process them, because those would add some thousand items more im my case. And yes, I'm unable to get my work done without these task list and calendar helpers, so I've very high interest to help make them work very well. ;-) Thank you for your work! |
Yeah, I hear you - same for me. That's why I initially started working on the elementary Tasks app 😄 I remember having troubles with a lot of completed tasks back then on Apple's Reminder app as well. The solution was simply to get rid of the completed tasks. So, if you don't care too much about keeping the completed tasks around you can delete them from the Nextcloud web interface: There is a button at the bottom of each task list, which initially says "Load completed tasks" - and once it is finished loading, the button changes to "Delete completed tasks". |
|
Thank you. Yes, I thought about deleting them, but I also keep these tasks as a log of activities and notes to search through. So I'd rather prefer an app that works with keeping them. ;-) |
|
Understandable. Was going to work on this regardless - but will need a way to create dummy data first. So this might take a litte bit of time ;) |
|
Great, thank you! Do you know at which point these watches are applied? I think those are the reason for the crash and probably limited to the 1024 or something open files per binary? |
|
That's probably happening somewhere here: tasks/src/Widgets/TaskListGrid.vala Line 290 in facab89 |
|
@marbetschar I would consider making some of this static rather than creating a new tasks/src/Widgets/TaskRow.vala Lines 138 to 139 in 2caa228 That would at the very least reduce the watch/unwatch spam as seen in the log above. |
|
@davidmhewitt tried to make h24_settings static and even only created one |
|
Hm, I guess it's the act of getting the setting rather than creating the object. Tbh, we shouldn't really be getting the setting for every task either as it's very unlikely to change. |
|
@davidmhewitt I agree - but thats what I already do in the linked commit: I only read the setting once per list and then pass its value to each task. But I still got a lot of those watch/unwatch messages - despite the fact that lists are only initialized once: Lines 187 to 191 in 6153822 Also I'm doing quite the same thing now in elementary Mail for messages - not sure if it has any detrimental effects there though. How would the ideal handling of this setting look like, if we don't want to restart the app every time this changes? ... or should we simply not care, because it does not change that often anyways? |
|
Thanks for investigating!
|
|
I was able to track those watch/unwatch messages down. There are basically generated at two places and @davidmhewitt was right, it all happens due to the 24h clock format setting being watched. The two places this happens is:
I agree that both of this is not really necessary. However, the fact that the second one is part of Granite leads me to the issue I opened about having Granite handle this better: elementary/granite#525 |
|
In terms of performance, I don't think just getting rid of those noisy messages is enough: I generated quite a lot of tasks for test purposes (around 2'500) and even though they load on my end successfully, working with Tasks gets unbearably slow. I suspect this is due to simply using an unoptimized tasks/src/Widgets/TaskListGrid.vala Line 27 in 6153822 I'm now wondering if Gtk.ListBox supports some sort of virtual scrolling which would allow us to only render the visible area and still keeping all data in memory. But as we are using a custom implementation of such a thing in Mail ( |
|
There's no out of box efficient listbox in GTK3, hence the custom one. But I believe there is in GTK4 |
|
Yeah, if I understand it correctly then GTK4's ListView provides such functionality. To use GTK4 in Tasks, we need to Flatpak it - and this is blocked by elementary/switchboard-plug-onlineaccounts#209 for now. |
Thank you for figuring this out! Regarding that one for me it would be a sufficient workaround to have only the active tasks be displayed. The completed tasks could be loaded and rendered on demand only. That way Tasks would not have to handle more than about 150 tasks (at least for me now). |
|
I confirm that since the last release Tasks runs like a roasted rocket! Nice!! Thank you! |
|
Oh, hm. What a pity. I enabled to load completed tasks for one list (which I thought was a smaller one). And now I'm stuck again in a crash loop. ;-) Is there a way to reset that setting? |
|
@Letterus sorry for beeing unresponsive. I think uninstalling and reinstalling elementary Tasks should mitigate your issue - because this way Tasks's settings should be resetted. |
|
Since the last release (6.1.0) Tasks is able to load and show my whole bunch of a lots of tasks, even when selecting the option to show completed tasks. So we may consider this issue resolved? I'd like to say a big "thank you" for your work! |
|
Interesting 🤔 Seems like an unintended (but positive) side effect of the previous changes :) Unfortunately the root cause has not been adressed yet and we need GTK 4 to fix this for good (virtualized rows in Gtk.ListView to be specific). Therefore, I'd like to keep this issue open till we ported Task to GTK4. But in any case: Happy it works for you now! 🥳 |
marbetschar
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What Happened
Tasks crashes on startup. The list of calendars is shown correctly, but the tasks most times are not shown. It seems Tasks crashes while loading them.
I tried to set the inode number very high, but
df -ialways shows way enough free inodes, so I don't really know if this is the problem.Expected Behavior
I'd expect my tasks to appear and the UI to react to my input.
Steps to Reproduce
Logs
Platform Information
elementary OS 6 Odin, all updates installed.
The text was updated successfully, but these errors were encountered: