Bug 558472 – evolution crashed when reiterating a search after a few minutes delay

After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.

Bug 558472 - evolution crashed when reiterating a search after a few minutes delay


Summary:	evolution crashed when reiterating a search after a few minutes delay


Status:	RESOLVED FIXED

Product:	evolution
Classification:	Applications
Component:	Mailer
Version:	2.24.x (obsolete)
Hardware:	Other All

Importance:	Normal critical
Target Milestone:	---
Assigned To:	evolution-mail-maintainers
QA Contact:	Evolution QA team

URL:
Whiteboard:	evolution[disk-summary]

Depends on:
Blocks:	543389

Reported:	2008-10-29 23:37 UTC by Thomas
Modified:	2009-01-29 16:38 UTC

See Also:
GNOME target:	---
GNOME version:	2.21/2.22

Description Thomas 2008-10-29 23:37:51 UTC

Steps to reproduce:
1. 
2. 
3. 


Stack trace:
Program terminated with signal 11, Segmentation fault.
[New process 20687]
[New process 20686]
[New process 20685]
[New process 20684]
[New process 20503]

+ Trace 208896

#0 summary_reloaded
at ../../../evolution-data-server/camel/camel-vee-folder.c line 2010
#0 summary_reloaded
at ../../../evolution-data-server/camel/camel-vee-folder.c line 2010
#1 camel_object_trigger_event
at ../../../evolution-data-server/camel/camel-object.c line 1494
#2 camel_folder_summary_reload_from_db
at ../../../evolution-data-server/camel/camel-folder-summary.c line 920
#3 search_match_all
at ../../../evolution-data-server/camel/camel-folder-search.c line 800
#4 e_sexp_term_eval
at ../../../evolution-data-server/libedataserver/e-sexp.c line 710
#5 term_eval_and
at ../../../evolution-data-server/libedataserver/e-sexp.c line 259
#6 e_sexp_term_eval
at ../../../evolution-data-server/libedataserver/e-sexp.c line 710
#7 e_sexp_eval
at ../../../evolution-data-server/libedataserver/e-sexp.c line 1324
#8 camel_folder_search_search
#9 local_search_by_expression
#10 camel_folder_search_by_expression
#11 vee_search_by_expression
#12 camel_folder_search_by_expression
#13 regen_list_exec
at ../../../evolution/mail/message-list.c line 4035
#14 mail_msg_proxy
at ../../../evolution/mail/mail-mt.c line 520
#15 ??
from /usr/lib/libglib-2.0.so.0
#16 ??
from /usr/lib/libglib-2.0.so.0
#17 start_thread
from /lib/tls/i686/cmov/libpthread.so.0
#0 summary_reloaded
at ../../../evolution-data-server/camel/camel-vee-folder.c line 2010

2005	{
2006		CamelFolderSummary *summary = event_data;
2007		CamelVeeFolder *vf = (CamelVeeFolder *)data;
2008		struct _CamelVeeFolderPrivate *p = _PRIVATE(vf);	
2009		struct _folder_flags_msg *m;
2010		CamelSession *session = ((CamelService *)((CamelFolder *)vf)->parent_store)->session;
2011	
2012		if (p->destroyed)
2013			return; 
2014	
(gdb) p vf
$1 = (CamelVeeFolder *) 0x859ed60
(gdb) p ((CamelFolder *)vf)->parent_store)
Junk after end of expression.
(gdb) p ((CamelFolder *)vf)->parent_store
$2 = (CamelStore *) 0x0
(gdb) 


Other information:
Changed the code to
	CamelSession *session;
	CamelStore *store;

	store = ((CamelFolder *)vf)->parent_store;
	if (!store) {
		return;
	}
	
	session = ((CamelService *)store)->session;

Comment 1 Thomas 2008-11-02 14:15:41 UTC

Just occurred again.

(gdb) bt

+ Trace 209096

#0 summary_reloaded
at ../../../evolution-data-server/camel/camel-vee-folder.c line 2018
#1 camel_object_trigger_event
at ../../../evolution-data-server/camel/camel-object.c line 1494
#2 camel_folder_summary_reload_from_db
at ../../../evolution-data-server/camel/camel-folder-summary.c line 920
#3 search_match_all
at ../../../evolution-data-server/camel/camel-folder-search.c line 800
#4 e_sexp_term_eval
at ../../../evolution-data-server/libedataserver/e-sexp.c line 710
#5 term_eval_and
at ../../../evolution-data-server/libedataserver/e-sexp.c line 259
#6 e_sexp_term_eval
at ../../../evolution-data-server/libedataserver/e-sexp.c line 710
#7 e_sexp_eval
at ../../../evolution-data-server/libedataserver/e-sexp.c line 1324
#8 camel_folder_search_search
#9 local_search_by_expression
#10 camel_folder_search_by_expression
#11 vee_search_by_expression
#12 camel_folder_search_by_expression
#13 regen_list_exec
at ../../../evolution/mail/message-list.c line 4035
#14 mail_msg_proxy
at ../../../evolution/mail/mail-mt.c line 520
#15 ??
from /usr/lib/libglib-2.0.so.0
#16 ??
from /usr/lib/libglib-2.0.so.0
#17 start_thread
from /lib/tls/i686/cmov/libpthread.so.0
#18 clone
from /lib/tls/i686/cmov/libc.so.6
#0 summary_reloaded
at ../../../evolution-data-server/camel/camel-vee-folder.c line 2018

$8 = (void *) 0x8ce4a30
(gdb) p *vf
$9 = {parent = {parent_object = {klass = 0x80b04a0, magic = 1, hooks = 0x0, 
      ref_count = 3215328, flags = 0, next = 0xe00, prev = 0x0}, 
    priv = 0x8147020, name = 0x1c <Address 0x1c out of bounds>, 
    full_name = 0x1c <Address 0x1c out of bounds>, 
    description = 0x178 <Address 0x178 out of bounds>, parent_store = 0x1, 
    summary = 0x1c, folder_flags = 30, permanent_flags = 148256160, later = {
      0x86a4ec0, 0x0, 0x0, 0x8f2c5c8}}, priv = 0x8bda8d0, expression = 0x0, 
  flags = 0, changes = 0x111, search = 0x3f000000, 
  parent_vee_store = 0x3f000000, hashes = 0x0, loaded = 0x2, deleted = 0}
(gdb)

Comment 2 Srinivasa Ragavan 2008-11-03 05:32:13 UTC

I will look into this this week.

Comment 3 Srinivasa Ragavan 2008-11-03 08:22:47 UTC

Can you do,

p *vf

I would be interested to see what is that vee folder. Then it should be easy to fix it.

Comment 4 Srinivasa Ragavan 2008-11-18 04:16:05 UTC

Did you get this again? Can you get me 
p *vf
and
 p *(CamelFolder *)vf

Outputs when it crashes.

Comment 5 Thomas 2008-11-20 23:10:27 UTC


(In reply to comment #4)
> Did you get this again? Can you get me 
> p *vf
> and
>  p *(CamelFolder *)vf
> 
> Outputs when it crashes.
> 

yes, got it now. Will try to get this info if it occurs again.

Comment 6 Akhil Laddha 2009-01-27 04:50:47 UTC

thomas, ping

Comment 7 Srinivasa Ragavan 2009-01-29 16:38:26 UTC

This is already fixed in a different bug.