Bug 707713

Summary: [abrt] evolution-2.32.2-1.fc14: e_book_query_to_string: Process /usr/bin/evolution was killed by signal 11 (SIGSEGV)
Product: [Fedora] Fedora Reporter: info <info>
Component: evolutionAssignee: Matthew Barnes <mbarnes>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 14CC: lucilanga, mbarnes, mcrha
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Unspecified   
Whiteboard: abrt_hash:1dd55a7649185cb9ace0adcfb1629092233fccdf
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-05-26 11:03:41 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
File: backtrace
none
Searches file with crash-causing saved search none

Description info@kobaltwit.be 2011-05-25 18:34:52 UTC 
abrt version: 1.1.18
architecture: i686
Attached file: backtrace, 56162 bytes
cmdline: /usr/bin/evolution
component: evolution
Attached file: coredump, 130433024 bytes
crash_function: e_book_query_to_string
executable: /usr/bin/evolution
kernel: 2.6.35.13-91.fc14.i686.PAE
package: evolution-2.32.2-1.fc14
rating: 4
reason: Process /usr/bin/evolution was killed by signal 11 (SIGSEGV)
release: Fedora release 14 (Laughlin)
time: 1306348131
uid: 500

How to reproduce
-----
1. I have Evolution Contacts configured to connect to an LDAP server
2. I have a saved search that limits the list based on Business Category in LDAP
3. I had selected one LDAP contact and edited the "File As" property
4. Saving this contact back to LDAP (by clicking OK) seemed to time out although checking afterwards in LDAP suggests the change was made after all.
5. Because of the time out, I switched to another saved search and back to be sure I got the most recent data from LDAP

While switching back, Evolution crashed.
Comment 1 info@kobaltwit.be 2011-05-25 18:34:55 UTC 
Created attachment 500911 [details]
File: backtrace
Comment 2 info@kobaltwit.be 2011-05-25 18:54:31 UTC 
Sorry, it turns out this has nothing to do with the LDAP time out.

Instead, the saved search I wanted to switch to is empty, or more precise, it has one condition:
Expression:

But there is no expression filled in.
The same happens if you try to create a new Advanced search with one condition, being an empty expression and then try to save that search.

This situation should either be prevented or at least not crash.
Comment 3 Milan Crha 2011-05-26 05:56:21 UTC 
Thanks for a bug report. Could you attach here your 
   ~/.config/evolution/addressbook/searches.xml
please? Feel free to strip any private information from it. I would like to see whether the "Expression" is really stored in the rule or any other bug happened which prevented it from correct rule reading. Thanks in advance.
Comment 4 info@kobaltwit.be 2011-05-26 07:59:53 UTC 
Created attachment 501005 [details]
Searches file with crash-causing saved search

Here it is.

The saved search causing the crash is the first one ("Adres").
Comment 5 Milan Crha 2011-05-26 11:03:41 UTC 
Thanks for the update. I see that the rule is stored as an expression with an empty value, thus this is not caused by broken save.

I tried and I can reproduce it too with my git master (before 3.1.2).
I moved this upstream as [1], please see it for any further updates.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=651135
Comment 6 Milan Crha 2011-05-26 11:04:49 UTC 
I forgot to mention, please edit the saved search and set it to something more useful.
Comment 7 info@kobaltwit.be 2011-05-31 18:05:15 UTC 
(In reply to comment #6)
> I forgot to mention, please edit the saved search and set it to something more
> useful.

Yes, that is obviously the way to avoid the crash. Additionally I hope upstream will improve on the core problem by either preventing an empty search or by at least not crashing in that case.
Comment 8 info@kobaltwit.be 2011-05-31 18:07:19 UTC 
Oops, I should have looked at upstream first. I see you already committed a patch. That's fast ! Thanks.
Comment 9 Milan Crha 2011-06-01 11:41:38 UTC 
Yup, I did a commit to upstream, even not so clever as you suggested. My note in comment #6 was only about a workaround for the current stable, till version with a fix will be officially released.