Bug 1087312

Summary: [abrt] evolution: e_table_sort_info_sorting_set_nth(): evolution killed by SIGSEGV
Product: [Fedora] Fedora Reporter: Ulf Seltmann <ulf.seltmann>
Component: evolutionAssignee: Matthew Barnes <mbarnes>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: fabiano, lucilanga, mbarnes, mcrha, ulf.seltmann
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
URL: https://retrace.fedoraproject.org/faf/reports/bthash/672947d8fabc898a29dada0054e3b2bad922788e
Whiteboard: abrt_hash:5beb2be7b2be45b22d190eb482c18b207eac5f5c
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-06-09 14:23:35 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
File: backtrace
none
File: cgroup
none
File: core_backtrace
none
File: dso_list
none
File: environ
none
File: exploitable
none
File: limits
none
File: maps
none
File: open_fds
none
File: proc_pid_status
none
File: var_log_messages none

Description Ulf Seltmann 2014-04-14 08:35:57 UTC 
Description of problem:
changed view order by clicking date column heading

Version-Release number of selected component:
evolution-3.10.4-2.fc20

Additional info:
reporter:       libreport-2.2.1
backtrace_rating: 4
cmdline:        evolution
crash_function: e_table_sort_info_sorting_set_nth
executable:     /usr/bin/evolution
kernel:         3.13.9-200.fc20.x86_64
runlevel:       N 5
type:           CCpp
uid:            1000

Truncated backtrace:
Thread no. 1 (10 frames)
 #0 e_table_sort_info_sorting_set_nth at e-table-sort-info.c:682
 #1 e_table_sort_info_load_from_node at e-table-sort-info.c:765
 #2 e_table_state_load_from_node at e-table-state.c:544
 #3 e_table_state_load_from_file at e-table-state.c:471
 #4 gal_view_etable_attach_tree at gal-view-etable.c:253
 #5 mail_paned_display_view_cb at e-mail-paned-view.c:264
 #6 mail_paned_view_update_view_instance at e-mail-paned-view.c:954
 #10 g_signal_emit_by_name at gsignal.c:3426
 #15 mail_reader_emit_folder_loaded at e-mail-reader.c:2964
 #16 mail_reader_set_folder at e-mail-reader.c:3041
Comment 1 Ulf Seltmann 2014-04-14 08:36:02 UTC 
Created attachment 886053 [details]
File: backtrace
Comment 2 Ulf Seltmann 2014-04-14 08:36:05 UTC 
Created attachment 886054 [details]
File: cgroup
Comment 3 Ulf Seltmann 2014-04-14 08:36:07 UTC 
Created attachment 886055 [details]
File: core_backtrace
Comment 4 Ulf Seltmann 2014-04-14 08:36:10 UTC 
Created attachment 886056 [details]
File: dso_list
Comment 5 Ulf Seltmann 2014-04-14 08:36:13 UTC 
Created attachment 886057 [details]
File: environ
Comment 6 Ulf Seltmann 2014-04-14 08:36:14 UTC 
Created attachment 886058 [details]
File: exploitable
Comment 7 Ulf Seltmann 2014-04-14 08:36:16 UTC 
Created attachment 886059 [details]
File: limits
Comment 8 Ulf Seltmann 2014-04-14 08:36:18 UTC 
Created attachment 886060 [details]
File: maps
Comment 9 Ulf Seltmann 2014-04-14 08:36:20 UTC 
Created attachment 886061 [details]
File: open_fds
Comment 10 Ulf Seltmann 2014-04-14 08:36:23 UTC 
Created attachment 886062 [details]
File: proc_pid_status
Comment 11 Ulf Seltmann 2014-04-14 08:36:25 UTC 
Created attachment 886063 [details]
File: var_log_messages
Comment 12 Milan Crha 2014-04-14 12:32:04 UTC 
Thanks for a bug report. The backtrace suggests that evolution was about to move the message list from one folder to another, when the crash happened.

Can it be, that you clicked on a different folder in the folder list (on the left from the message list in the Mail view), maybe accidentally, and while the folder was loading, you managed to click the Date header header, which was supposed to be saved? Can you reproduce this consistently, maybe in a particular folder only?
Comment 13 Ulf Seltmann 2014-06-09 11:43:16 UTC 
Hi,

sorry for the delay, but i do not really know if i understood correctly. as from my point of view i can explain, that i wanted to change the sort order of all my folders in the mailbox. so it could be, that a folder was not loaded already as i clicked the header. but i can be relatively sure, that the message-list of that folder appears as soon as i click the folder. is there a cache that is responsible for the immediate showing of the message list?

i could not reproduce this issue

ciao
ulf
Comment 14 Milan Crha 2014-06-09 14:23:35 UTC 
(In reply to u.seltmann from comment #13)
> is there a cache that is responsible for the immediate showing of the message
> list?

There is a "local summary" of the folder, which acts as a cache of information necessary to build the list of messages. Its size influences speed of the list fill.

> i could not reproduce this issue

Good. Maybe it was just a one time issue, some coincidence. I'm closing this, but feel free to reopen, in case you'll find a reproducer. Thanks in advance.