| Summary: | korganizer crashes when filtering involves sub-to-dos | ||
|---|---|---|---|
| Product: | [Applications] korganizer | Reporter: | Vitor M. Pereira <vmpereir> |
| Component: | general | Assignee: | kdepim bugs <kdepim-bugs> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | crash | CC: | smartins |
| Priority: | NOR | ||
| Version: | 4.2.2 | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Vitor M. Pereira
2009-04-30 00:31:21 UTC
1. Which resource are you using? (Akonadi, local ics file, remote, etc) 2. Can you install debug symbols and get a new backtrace? http://techbase.kde.org/Development/Tutorials/Debugging/How_to_create_useful_crash_reports > 1. Which resource are you using? (Akonadi, local ics file, remote, etc) Sorry for forgetting to mention. I'm using a local ics file and standalone korganizer (not from kontact). > 2. Can you install debug symbols and get a new backtrace? I'll take a look on how to do that in fedora and report back. >> 2. Can you install debug symbols and get a new backtrace? >I'll take a look on how to do that in fedora and report back. OK. I see that in fedora here I need to install ~600MB in debuginfo packages to get debug symbols for kdepim. At the moment this is prohibitive for me since I've got KDE 4 only on my laptop, which is already slightly constrained in HD space. Could perhaps someone with debuginfo already set up try to reproduce the crash from the steps above? What view did you use in step 5? Do you have the mini-to-do view in the side bar? Is the sub-todo visible or hidden (parent expanded)) For example: - I disable all sidebars; - I follow the steps above to create the sub-todo, and assign the category to the sub-todo only. - I select view -> day, and, just to make sure, go to one day where there is nothing listed (no events, no to-dos, nothing); - I apply the filter for the category of the sub-todo just created. - Since the day I have selected to see has nothing, nothing visibly happens. - Afterwards, I apply any other filter and korganizer crashes. So, this example shows that it does not seem related to whether the item is visible or not. In addition, it doesn't matter whether I am in the day, week, to-do, what's next or any other view. Nor whether I have sidebars on or off. The above sequence of filtering that particular category and then selecting another filter always crashes korganizer. As soon as I delete the sub-todo. All works as expected in any view and side views. I can filter, un-filter, re-filter endlessly and korganizer responds as expected. NOTE: The crash only happens when the sub-todo has a category, but the parent todo doesn't. If I assign the category to the parent todo, and then create the sub-todo (which inherits the category), there is no crash and korganizer seems to behave as expected. So it seems something related to the fact that the parent has no category. Incidence::relatedTo() crashes were fixed in 4.6 with the use of shared pointers. |