GNOME Bugzilla – Bug 544187
Crash in e_cal_menu_target_new_select at e-cal-menu.c line 144
Last modified: 2010-12-28 07:01:20 UTC
What were you doing when the application crashed? I write a task in Evolution Distribution: Debian lenny/sid Gnome Release: 2.22.3 2008-06-30 (Debian) BugBuddy Version: 2.22.0 System: Linux 2.6.25-2-vserver-amd64 #1 SMP Mon Jul 14 11:35:37 UTC 2008 x86_64 X Vendor: The X.Org Foundation X Vendor Release: 10402000 Selinux: No Accessibility: Disabled GTK+ Theme: Nuvola Icon Theme: Mist Memory status: size: 580820992 vsize: 580820992 resident: 51499008 share: 29073408 rss: 51499008 rss_rlim: 18446744073709551615 CPU usage: start_time: 1216740581 rtime: 428 utime: 387 stime: 41 cutime:3 cstime: 10 timeout: 0 it_real_value: 0 frequency: 100 Backtrace was generated from '/usr/bin/evolution' [Thread debugging using libthread_db enabled] [New Thread 0x7fc0846167a0 (LWP 6384)] [New Thread 0x45cf4950 (LWP 6426)] [New Thread 0x45cb3950 (LWP 6420)] [New Thread 0x40d40950 (LWP 6409)] 0x00007fc07feb9edf in waitpid () from /lib/libpthread.so.0
+ Trace 203506
Thread 1 (Thread 0x7fc0846167a0 (LWP 6384))
----------- .xsession-errors (9 sec old) --------------------- (npviewer.bin:6350): Gtk-CRITICAL **: gtk_widget_destroy: assertion `GTK_IS_WIDGET (widget)' failed (npviewer.bin:6350): Gtk-CRITICAL **: gtk_widget_hide: assertion `GTK_IS_WIDGET (widget)' failed (npviewer.bin:6350): Gtk-CRITICAL **: gtk_widget_destroy: assertion `GTK_IS_WIDGET (widget)' failed (npviewer.bin:6350): Gtk-CRITICAL **: gtk_widget_destroy: assertion `GTK_IS_WIDGET (widget)' failed CalDAV Eplugin starting up ... evolution-shell-Message: Killing old version of evolution-data-server... ** (evolution:6384): DEBUG: mailto URL command: evolution %s ** (evolution:6384): DEBUG: mailto URL program: evolution (evolution:6384): calendar-gui-CRITICAL **: e_cal_model_get_component_at: assertion `row >= 0 && row < priv->objects->len' failed (evolution:6384): calendar-gui-CRITICAL **: e_cal_model_copy_component_data: assertion `comp_data != NULL' failed --------------------------------------------------
possible dup of bug 335618
I'll use this bug to be the master bug for crashers in 2.22.3 and 2.23.x in this piece of code, because this trace has been caused by my change in bug #532597. The older bug is fixed (I believe). ------------------------------------------------------------- The background: In the above bug #532597, I added some pieces of code to recalculate cursor positions based on the sorter, not the model row numbers, thus when one sorts things and makes changes/deletes rows, after the patch the cursor doesn't jump "randomly" around the table. It was created for address book, but this "class" is used in calendar/ETable/... too. For the backtrace itself, I can reproduce it by these steps: a) have some items with "% Completed" filled zero and one with say 100%. b) have 10 items, sorted by "% Complete" c) select second item, double click it, make some change other than in the sorting column and save. d) item came as the last in the list of consecutive 0% completed values, only one item is below this, that with 100% complete e) double click on it one more time (on its new position) and try save changes The position of the item is crucial, because of going out of bounds (see the console warnings above). ------------------------------------------------------------- Why this happens? It's because of design of e-cal-model, namely e_cal_view_objects_modified_cb calls e_cal_view_objects_added_cb with list of modified objects, which are removed from the model first in a way that e_table_model_row_deleted is called before the actual array is shorten, thus in e_selection_model_array_delete_rows we shorten the EBitArray, but the underlying sorter has still all items, thus we end up with cursor position out of bounds (that's the reason why this reediting item should be just before the last item in the sorting). I can call e_table_model_changed after deleting, but it forgets the cursor/selection, which is not a good thing. I can delete item from the array before calling e_table_model_row_deleted, but free the ECalModelComponent object after this, which sort of works, but results in moving cursor somewhere else anyway (because if correctly choose the next item, but when inserting back, it will keep selected the next item, not that one I edited right now. It's the reason why I think the design of ECalModel is not so good). I also remember that I was playing with the ordering of these functions (g_ptr_array_remove and e_table_model_row_deleted), but it caused other issues, I do not remember exactly what, though). Any Idea? I do not think checking for bounds in the add_uid_cb would be good considered as a fix, it's rather a workaround.
*** Bug 543579 has been marked as a duplicate of this bug. ***
*** Bug 545606 has been marked as a duplicate of this bug. ***
If this is the same bug that I am dealing with, I find that the error does not occur when working with tasks within calendar mode, where tasks and notes are off at the right. Perhaps the reason for it not crashing in calendar view could fix it in the task view?
(In reply to comment #5) I guess it's just because you sort the tasks in the right panel in the different way than in the tasks view.
You have just made my day!!! All I had to do was switch my sorting view in task mode and the problem disappeared. Thank you so much!!!
*** Bug 546449 has been marked as a duplicate of this bug. ***
*** Bug 542917 has been marked as a duplicate of this bug. ***
*** Bug 546741 has been marked as a duplicate of this bug. ***
*** Bug 547286 has been marked as a duplicate of this bug. ***
lakhil: when triaging please correct the component. thanks.
*** Bug 547473 has been marked as a duplicate of this bug. ***
*** Bug 547576 has been marked as a duplicate of this bug. ***
*** Bug 548277 has been marked as a duplicate of this bug. ***
*** Bug 548242 has been marked as a duplicate of this bug. ***
*** Bug 547630 has been marked as a duplicate of this bug. ***
*** Bug 548542 has been marked as a duplicate of this bug. ***
Created attachment 117210 [details] [review] Changed the model code a bit. Tested it and seems to work fine. Will update the ChangeLog while committing. mcrha, it would be better if you also test/review this patch.
I guess you should unref all from the 'list' at the end of e_cal_view_objects_modified_cb, shouldn't you? it can be done with g_(s)list_foreach (list, (GFunc)g_object_unref, NULL); instead of traversing yourself, as you did in the redo_queries. That's the other thing, once you use GSList once GList, isn't it a bit confusing? e-cal-model.c: In function ‘e_cal_view_objects_modified_cb’: e-cal-model.c:1499: warning: ignoring return value of ‘g_list_prepend’, declared with attribute warn_unused_result e-week-view.c: In function ‘model_comps_deleted_cb’: e-week-view.c:407: warning: unused variable ‘i’ I tried with tasks and it doesn't crash, but when deleting, the cursor is positioned always on the first item entered in the model (probably). The intention of patch in mentioned bug #532597 was to keep cursor as close to the deleted position as possible. Otherwise as I tested this, the patch fixes the issue. I like that it keeps task at its position when I edit it, or resort to the right position. That's really great, thanks Chen. Just fix those things above and push it to trunk as soon as possible :)
*** Bug 549169 has been marked as a duplicate of this bug. ***
*** Bug 549616 has been marked as a duplicate of this bug. ***
The GList elements would be free'd in ECalView. Will use the gslist_foreach. I try to use GSList in the newly written code as there is no need for GList. Since the old code using GList in many ECal* API's it cant be changed completely. I tried to change the design of Model here to get this fixed. Not sure about the cursor thingy. Will change the gslist_foreach thing and commit the patch.
*** Bug 550836 has been marked as a duplicate of this bug. ***
patch hsa been committed. http://svn.gnome.org/viewvc/evolution?view=revision&revision=36276
*** Bug 552325 has been marked as a duplicate of this bug. ***
*** Bug 552313 has been marked as a duplicate of this bug. ***
*** Bug 552693 has been marked as a duplicate of this bug. ***
*** Bug 552787 has been marked as a duplicate of this bug. ***
*** Bug 552962 has been marked as a duplicate of this bug. ***
*** Bug 553026 has been marked as a duplicate of this bug. ***
*** Bug 553310 has been marked as a duplicate of this bug. ***
*** Bug 554436 has been marked as a duplicate of this bug. ***
*** Bug 554439 has been marked as a duplicate of this bug. ***
*** Bug 554719 has been marked as a duplicate of this bug. ***
*** Bug 554717 has been marked as a duplicate of this bug. ***
*** Bug 554751 has been marked as a duplicate of this bug. ***
*** Bug 556106 has been marked as a duplicate of this bug. ***
*** Bug 555822 has been marked as a duplicate of this bug. ***
*** Bug 556880 has been marked as a duplicate of this bug. ***
(Coming from bug 556880...) Indeed, this is fixed in Evolution 2.24, but I can't use Evolution 2.24 because it breaks the "Include threads" setting of search folders. Thus, I built a custom version of Evolution 2.22.3.1 with just the patch for this bug in the form of RPMs for Fedora 9. I have posted the RPMs at http://mattmccutchen.net/rpm/ for the benefit of anyone else in the same situation.
Never mind my RPMs, they are broken: duplicate copies of calendar events appear.
*** Bug 558682 has been marked as a duplicate of this bug. ***
*** Bug 558698 has been marked as a duplicate of this bug. ***
*** Bug 558707 has been marked as a duplicate of this bug. ***
*** Bug 558708 has been marked as a duplicate of this bug. ***
*** Bug 559234 has been marked as a duplicate of this bug. ***
*** Bug 560129 has been marked as a duplicate of this bug. ***
*** Bug 561552 has been marked as a duplicate of this bug. ***
*** Bug 561517 has been marked as a duplicate of this bug. ***
*** Bug 561814 has been marked as a duplicate of this bug. ***
*** Bug 562021 has been marked as a duplicate of this bug. ***
*** Bug 562599 has been marked as a duplicate of this bug. ***
*** Bug 564088 has been marked as a duplicate of this bug. ***
*** Bug 561551 has been marked as a duplicate of this bug. ***
*** Bug 571055 has been marked as a duplicate of this bug. ***
*** Bug 574219 has been marked as a duplicate of this bug. ***
*** Bug 576996 has been marked as a duplicate of this bug. ***
*** Bug 582289 has been marked as a duplicate of this bug. ***
bug 598037 against 2.28.x with similar traces
*** Bug 567959 has been marked as a duplicate of this bug. ***
Just had another one of those crashes with (evolution:6585): calendar-gui-CRITICAL **: ecmt_value_at: assertion `row >= 0 && row < e_table_model_row_count (etm)' failed total_rows is 0 in evolution/widgets/table/e-table-sorting-utils.c
Created attachment 152053 [details] [review] Check if total_rows > 0
Created attachment 157230 [details] [review] More careful approach, just check for non-NULL-ness of closure.vals before accessing it!
Created attachment 157236 [details] [review] Even better. Check that the index is within range!!
Created attachment 157239 [details] [review] e_table_sorting_utils_sort patch Now got crashes. So why not extend the ETableSortClosure struct to contain the maximal number of vals, so that user of the struct can check ranges.
may be we can take this patch under bug 598037 so that we don't have to reopen bug 544187
*** Bug 557703 has been marked as a duplicate of this bug. ***