Bug 120076 - advanced search on virtual folder makes evolution permanently crashing
Summary: advanced search on virtual folder makes evolution permanently crashing
Status: RESOLVED WORKSFORME
Alias: None
Product: SUSE LINUX 10.0
Classification: openSUSE
Component: Evolution (show other bugs)
Version: Final
Hardware: x86-64 All
: P5 - None : Normal
Target Milestone: ---
Assignee: Srinivasa Ragavan
QA Contact: Poornima Nayak
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-10-04 10:07 UTC by Stanislav Brabec
Modified: 2007-02-07 08:56 UTC (History)
0 users

See Also:
Found By: Other
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stanislav Brabec 2005-10-04 10:07:47 UTC
I have a virtual folder, which is defined as mails on local and IMAP folders,
which are read, not marked as importand and having no color label.

Giving advanced searching of mails containing string in recipient and another
string in the body, Evolution crashes.

Setting severity to Blocker because there is nearly no way to use Evolution
after this crash.

After restarting evolution, evolution crashes imediately after start.

After evolution --force-shutdown and restarting evolution, evolution crashes few
seconds after start.

When the fix will available, it should be provided by online update.

Additional note: Searched virtual folder contains about 65000 messages.

Backtrace was generated from '/opt/gnome/bin/evolution-2.4'

Using host libthread_db library "/lib64/tls/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread 46912613762112 (LWP 31999)]
[New Thread 1086347616 (LWP 32021)]
[Thread debugging using libthread_db enabled]
[New Thread 46912613762112 (LWP 31999)]
[New Thread 1086347616 (LWP 32021)]
[Thread debugging using libthread_db enabled]
[New Thread 46912613762112 (LWP 31999)]
[New Thread 1086347616 (LWP 32021)]
[New Thread 1084246368 (LWP 32020)]
[New Thread 1080043872 (LWP 32018)]
[New Thread 1082145120 (LWP 32007)]
[New Thread 1077942624 (LWP 32005)]
[New Thread 1075841376 (LWP 32004)]
0x00002aaab133f246 in __select_nocancel () from /lib64/tls/libc.so.6
#0  0x00002aaab133f246 in __select_nocancel () from /lib64/tls/libc.so.6
#1  0x00002aaab0adaef6 in _XWaitForReadable (dpy=0x54a110) at XlibInt.c:493
#2  0x00002aaab0adb2f2 in _XRead (dpy=0x54a110, 
    data=0x7fffffa0f080 "\034Ñ!7{", size=32) at XlibInt.c:1071
#3  0x00002aaab0adc1e1 in _XReply (dpy=0x54a110, rep=0x7fffffa0f080, extra=0, 
    discard=1) at XlibInt.c:1703
#4  0x00002aaab0ad19ee in XQueryPointer (dpy=0x54a110, w=44040438, 
    root=0x7fffffa0f100, child=0x7fffffa0f0f8, root_x=0x7fffffa0f124, 
    root_y=0x7fffffa0f120, win_x=0xfffffffffffffdfe, win_y=0xfffffffffffffdfe, 
    mask=0xfffffffffffffdfe) at QuPntr.c:43
#5  0x00002aaaaf8a4dd1 in _gdk_windowing_window_get_pointer (
    display=<value optimized out>, window=0xbd97e0, x=0x7fffffa0f15c, 
    y=0x7fffffa0f158, mask=0x7fffffa0f154) at gdkwindow-x11.c:3425
#6  0x00002aaaaf88171d in gdk_window_get_pointer (window=0xbd97e0, 
    x=0x7fffffa0f19c, y=0x7fffffa0f198, mask=0x0) at gdkwindow.c:2839
#7  0x00002aaaaca59d8f in gtk_html_get_url_at ()
   from /opt/gnome/lib64/libgtkhtml-3.8.so.15
#8  0x00002aaaaf30fed0 in _gtk_marshal_BOOLEAN__BOXED (closure=0x65a1d0, 
    return_value=0x7fffffa0f3b0, n_param_values=<value optimized out>, 
    param_values=0x7fffffa0f4b0, invocation_hint=<value optimized out>, 
    marshal_data=0x2aaaaca59c90) at gtkmarshalers.c:83
#9  0x00002aaab00e4770 in g_closure_invoke (closure=0x65a1d0, 
    return_value=0x7fffffa0f3b0, n_param_values=2, 
    param_values=0x7fffffa0f4b0, invocation_hint=0x7fffffa0f370)
    at gclosure.c:492
#10 0x00002aaab00f338b in signal_emit_unlocked_R (node=0x65a260, detail=0, 
    instance=0x987640, emission_return=0x7fffffa0f690, 
    instance_and_params=0x7fffffa0f4b0) at gsignal.c:2523
#11 0x00002aaab00f43eb in g_signal_emit_valist (instance=0x987640, 
    signal_id=<value optimized out>, detail=0, var_args=0x7fffffa0f6f0)
    at gsignal.c:2254
#12 0x00002aaab00f4a63 in g_signal_emit (instance=<value optimized out>, 
    signal_id=<value optimized out>, detail=<value optimized out>)
    at gsignal.c:2288
#13 0x00002aaaaf3ee295 in gtk_widget_event_internal (widget=0x987640, 
    event=0x5c9038) at gtkwidget.c:3735
#14 0x00002aaaaf30e2db in gtk_propagate_event (widget=0x987640, event=0x5c9038)
    at gtkmain.c:2161
#15 0x00002aaaaf30e757 in gtk_main_do_event (event=0x5c9038) at gtkmain.c:1398
#16 0x00002aaaaf89349c in gdk_event_dispatch (source=<value optimized out>, 
    callback=<value optimized out>, user_data=<value optimized out>)
    at gdkevents-x11.c:2292
#17 0x00002aaab044b54d in g_main_context_dispatch (context=0x55bc60)
    at gmain.c:1934
#18 0x00002aaab044e6ff in g_main_context_iterate (context=0x55bc60, block=1, 
    dispatch=1, self=<value optimized out>) at gmain.c:2565
#19 0x00002aaab044e9aa in g_main_loop_run (loop=0x694d10) at gmain.c:2769
#20 0x00002aaaae4f14d5 in bonobo_main () from /opt/gnome/lib64/libbonobo-2.so.0
#21 0x000000000041746a in main (argc=<value optimized out>, argv=0x1)
    at main.c:602

Thread 7 (Thread 1075841376 (LWP 32004)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at pthread_cond_wait.S:222
No locals.
#1  0x00002aaaac52aef4 in e_mutex_lock (m=0x64bfc0) at e-msgport.c:1078
	id = 1075841376
	err = -4
#2  0x00002aaab6c6ed1d in imap_refresh_info (folder=0x2aaab9714c20, ex=0x0)
    at camel-imap-folder.c:515
	imap_store = (CamelImapStore *) 0x64b780
	imap_folder = (CamelImapFolder *) 0x2aaab9714c20
	response = <value optimized out>
	si = <value optimized out>
#3  0x00002aaab5483d55 in refresh_folders_get (mm=<value optimized out>)
    at mail-send-recv.c:712
	m = (struct _refresh_folders_msg *) 0xbfb580
	i = 6
	folder = (CamelFolder *) 0x2aaab9714c20
#4  0x00002aaab547e493 in mail_msg_received (e=<value optimized out>, 
    msg=<value optimized out>, data=<value optimized out>) at mail-mt.c:556
	text = 0xbfaf80 " GTK_SHADOW_IN "
	m = (mail_msg_t *) 0xbfb580
#5  0x00002aaaac52a997 in thread_dispatch (din=<value optimized out>)
    at e-msgport.c:826
	e = (EThread *) 0x62bb40
	m = (EMsg *) 0xbfb580
	info = <value optimized out>
	self = 1075841376
#6  0x00002aaaaed13fa5 in start_thread (arg=<value optimized out>)
    at pthread_create.c:261
	__res = (void *) 0xfffffffffffffffc
	pd = (struct pthread *) 0x40200960
	unwind_buf = {cancel_jmp_buf = {{jmp_buf = {1075841376, 0, 
        46912565755664, 46912565784512, 46912565784512, 2097152, 1075839456, 
        46912565755758}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 
      0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
	not_first_call = 0
#7  0x00002aaab1345cb2 in clone () from /lib64/tls/libc.so.6
	__elf_set___libc_subfreeres_element_fstab_free__ = (
    const void *) 0x2aaab1378da0
#8  0x0000000000000000 in ?? ()
No symbol table info available.
#9  0x0000000000000000 in ?? ()
No symbol table info available.
#10 0x0000000000000000 in ?? ()
No symbol table info available.
#11 0x0000000000000000 in ?? ()
...
No symbol table info available.
#216 0x0000000000000000 in ?? ()
No symbol table info available.
#217 0x0000000000000000 in ?? ()
No symbol table info available.
#218 0x00002aaab14ae500 in _nl_C_locobj () from /lib64/tls/libc.so.6
No symbol table info available.
#219 0x0000000040200dc0 in ?? ()
No symbol table info available.
...
#242 0x0000000000000000 in ?? ()
No symbol table info available.
#243 0x0000000000000000 in ?? ()
No symbol table info available.
#244 0x00002aaaaee1e220 in stack_cache_maxsize ()
   from /lib64/tls/libpthread.so.0
No symbol table info available.
#245 0x00000000404019e0 in ?? ()
No symbol table info available.
...
#351 0x0000000000000000 in ?? ()
No symbol table info available.
#352 0x0000000000000000 in ?? ()
No symbol table info available.
#353 0x00002aaaac52a900 in e_thread_busy () at e-msgport.c:775
	ethread_list = {head = 0x669020, tail = 0x0, tailpred = 0x745ae0}
	ethread_lock = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, 
  __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}
#354 0x000000000062bb40 in ?? ()
No symbol table info available.
#355 0x0000000000000000 in ?? ()
No symbol table info available.
#356 0x0000000000000000 in ?? ()
No symbol table info available.
...
Comment 1 Harish Krishnaswamy 2005-10-04 16:59:38 UTC
Assigning this to the mailer guy. Possibly related to a particular mail item
that currently has focus (hence evolution crashes everytime it is started).
To verify if it is being caused due to the vfolder rule, you may try removing
the entry from ~/.evolution/vfolders.xml and starting evolution again. It should
still crash if it is related to the mail item on the focus.

Comment 2 Stanislav Brabec 2005-10-05 14:56:52 UTC
No, it does not crash and displays empty virtual folder. When I move
~/.evolution/mail/vfolders.xml back, it starts crashing again.

It is probably not realated to mail on the ficus, because it crashes
independently on search contents.

Additional info:

The search completed. Before crashing, I was seeing that the wiew was displayin
only about 15 of 65000 mails.

If I am fast enough to clean the search before the crash, I have a chance, that
next time it will not crash.
Comment 3 Stanislav Brabec 2005-10-05 15:01:42 UTC
And another note:

Search for mails containing string in recipient and another
string in the sender works.

Search for mails containing string in recipient and another
string in the body crashes.
Comment 4 Susarla Parthasarathi 2006-03-13 10:32:55 UTC
I really suspect this to be a gtkhtml issue. All the string searches in the body are done with the help of gtkhtml.. Reassigning bug to srini.
Comment 5 Stanislav Brabec 2006-03-15 17:54:09 UTC
In SuSE Linux 10.1 beta 7 with fix from bug 127570 I am not able to reproduce this problem. (Exactly: Evolution crashes three times before I was able to start search on virtual folder. But these crashes are reported as different bugs.)
Comment 6 Srinivasa Ragavan 2006-03-16 03:41:18 UTC
Partha, I dont think this has anything to do with gtkhtml. he says that the results dont yield any msgs and results a empty vfolder. comment #3 says that.
In this case gtkhtml has no role to play 

A stack trace would be very helpful. Moving to partha.
Comment 7 Stanislav Brabec 2006-03-16 11:06:31 UTC
It seems, that crash occurred in combination of body searching and vfolder.

Because nobody else reported it, and SuSE Linux 10.1 does not have this problem, decreasing priority.

You may want to decide to not fix for 10.0, depending whether the old branch is still maintained.
Comment 8 Srinivasa Ragavan 2007-02-07 08:56:42 UTC
As 10.1/later doesn't has this, I closing this and please reopen if you see this in later builds.