GNOME Bugzilla – Bug 554282
advanced search -> expression makes evolution permanently crashing
Last modified: 2008-10-14 19:01:07 UTC
I have entered Advanced Search and entered advanced search for expression "list-post.*zypp-devel". It is no more possible to use evolution, as it crashes a second after every start. ... folders table successfully created Error in SQL SELECT statement: SELECT COUNT (*) FROM 'Outbox' [no such table: Outbox] Error in SQL SELECT statement: SELECT COUNT (*) FROM 'Outbox' WHERE junk = 1 [no such table: Outbox] Error in SQL SELECT statement: SELECT COUNT (*) FROM 'Outbox' WHERE deleted = 1 [no such table: Outbox] Error in SQL SELECT statement: SELECT COUNT (*) FROM 'Outbox' WHERE read = 0 [no such table: Outbox] Error in SQL SELECT statement: SELECT COUNT (*) FROM 'Outbox' WHERE junk = 0 AND deleted = 0 [no such table: Outbox] Error in SQL SELECT statement: SELECT COUNT (*) FROM 'Outbox' WHERE junk = 1 AND deleted = 0 [no such table: Outbox] ... store_db_path ... ... (evolution:26293): e-data-server-WARNING **: Error in parsing: Unknown identifier: list-post (evolution:26293): e-data-server-CRITICAL **: e_sexp_eval: assertion `f->tree != NULL' failed Program received signal SIGSEGV, Segmentation fault.
+ Trace 207523
Thread 140736846227792 (LWP 26308)
What exact version is this? Can you create an empty file named ~/.evolution/.running and start Evo without crashing?
Evolution 2.23.92 from openSUSE 11.1 beta 1. File ~/.evolution/.running already exists and evolution is still crashing. Removing this file does not help as well. But removing of ~/.evolution/mail/imap/.../folders/INBOX/cmeta stops repeated crashing.
Stanislav, I'm on this tomorrow morning. Basically, the search expression crashes while being converted to a sql query on the sexp parser. Removing the cmeta file, erases the last search, so it may be still fine. Anyways, the original bug is that the search crashes. This is due to new disk summary version.
I haven't used this field before. What does this expression supposed to do. Even on 2.22, it doesn't work. Well, it doesn't crash also. Andre/Others: Wasn't this expression supposed to be an s-expression ? I thought so.
I have no idea about developer intention, but I was thinking that it is a generic header match search for headers that are not listed elsewhere. I don't know, whether it is true and whether it was intended to use regular or globbing expressions.
I tried the same exp on 2.22 it didn't crash, but didn't work also. Same behaviour on 2.24.1 (stable/trunk: Fixed.)