Bug 861756

Summary: [abrt] evolution-3.5.92-3.fc19: memset: Process /usr/bin/evolution was killed by signal 11 (SIGSEGV)
Product: [Fedora] Fedora Reporter: Nicolas Mailhot <nicolas.mailhot>
Component: evolutionAssignee: Matthew Barnes <mbarnes>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: lucilanga, mbarnes, mcrha
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:3c96aca02f77b2f38920c571f7c9bed071eff9dc
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-10-17 07:34:12 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: core_backtrace
none
File: environ
none
File: limits
none
File: backtrace
none
File: cgroup
none
File: maps
none
File: dso_list
none
File: var_log_messages
none
File: open_fds none

Description Nicolas Mailhot 2012-09-30 13:53:46 UTC 
Description of problem:
while searching all messages on an imap account, evo tried to access a folder that existed the last time it was launched but was removed since by another imap client

Version-Release number of selected component:
evolution-3.5.92-3.fc19

Additional info:
libreport version: 2.0.14
abrt_version:   2.0.13
backtrace_rating: 4
cmdline:        evolution
crash_function: memset
kernel:         3.6.0-0.rc4.git2.1.fc18.x86_64

truncated backtrace:
:Thread no. 1 (10 frames)
: #0 memset at ../sysdeps/x86_64/memset.S:335
: #2 camel_memchunk_alloc0 at camel-memchunk.c:164
: #3 parse_term_new at camel-sexp.c:1205
: #4 parse_list at camel-sexp.c:1407
: #5 parse_value at camel-sexp.c:1309
: #6 parse_values at camel-sexp.c:1260
: #7 parse_list at camel-sexp.c:1416
: #8 parse_value at camel-sexp.c:1309
: #9 camel_sexp_parse at camel-sexp.c:1709
: #10 camel_folder_search_search at camel-folder-search.c:584
Comment 1 Nicolas Mailhot 2012-09-30 13:53:49 UTC 
Created attachment 619433 [details]
File: core_backtrace
Comment 2 Nicolas Mailhot 2012-09-30 13:53:51 UTC 
Created attachment 619434 [details]
File: environ
Comment 3 Nicolas Mailhot 2012-09-30 13:53:52 UTC 
Created attachment 619435 [details]
File: limits
Comment 4 Nicolas Mailhot 2012-09-30 13:53:55 UTC 
Created attachment 619436 [details]
File: backtrace
Comment 5 Nicolas Mailhot 2012-09-30 13:53:57 UTC 
Created attachment 619437 [details]
File: cgroup
Comment 6 Nicolas Mailhot 2012-09-30 13:54:00 UTC 
Created attachment 619438 [details]
File: maps
Comment 7 Nicolas Mailhot 2012-09-30 13:54:02 UTC 
Created attachment 619439 [details]
File: dso_list
Comment 8 Nicolas Mailhot 2012-09-30 13:54:04 UTC 
Created attachment 619440 [details]
File: var_log_messages
Comment 9 Nicolas Mailhot 2012-09-30 13:54:06 UTC 
Created attachment 619441 [details]
File: open_fds
Comment 10 Milan Crha 2012-10-16 13:29:06 UTC 
Thanks for a bug report. I see from the bakctrace that the folder you selected had set filter on itself (the one above message list, on the line with "Show:" on the left), the messages were filtered for those with 'a2bcd' in To or CC headers. This search parsing failed and caused evolution crash. I see your IMAP account is IMAPx, is it correct? Also, did the folder vanished the next start, as it should when it was removed from the server? I made some fixes regarding this for IMAP, but not for IMAPx.
Comment 11 Nicolas Mailhot 2012-10-16 15:35:00 UTC 
(In reply to comment #10)
> Thanks for a bug report. I see from the bakctrace that the folder you
> selected had set filter on itself (the one above message list, on the line
> with "Show:" on the left), the messages were filtered for those with 'a2bcd'
> in To or CC headers. This search parsing failed and caused evolution crash.
> I see your IMAP account is IMAPx, is it correct? Also, did the folder
> vanished the next start, as it should when it was removed from the server? I
> made some fixes regarding this for IMAP, but not for IMAPx.

1. evo says the account is of 'imap+' type
2. evo was used to perform a search on all messages in the account
3. it crashed trying to search a folder that existed the last time it was run, but which had been removed since with another imap client (so the bug is that evo tries to search in folders without checking if they still exist, and no I was not vicious enough to remove the fomder between evo startup and search order though that would have been a valid scenario
4. I don't remember if the forler finaly vanished by itself of if I had to force refreshes in evo to make sure it didn't crash anew
Comment 12 Milan Crha 2012-10-17 07:34:12 UTC 
Thanks for the update. Accessing "server-side removed folder" might not cause the crash, as it should be like running in offline, though the correlation with that fact is obvious. I'm moving this upstream [1] with your clarifications. Please add yourself into [1], if possible, in case upstream developers will have additional questions.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=686269