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 257930 - Evolution 1.5.7 crash in libgtkhtml-3 fuction consumes all swap space
Evolution 1.5.7 crash in libgtkhtml-3 fuction consumes all swap space
Status: RESOLVED FIXED
Product: GtkHtml
Classification: Other
Component: Editing
unspecified
Other All
: Normal major
: 1.5
Assigned To: gtkhtml-maintainers
Evolution QA team
: 267970 492748 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2004-05-01 00:27 UTC by Andrew Farris
Modified: 2009-11-27 05:03 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Andrew Farris 2004-05-01 00:27:48 UTC
Description of Problem:
Evolution mail stops responding to input while writing a new email and then
consumes all available swap space (~2Gb on this system) until the process
is killed.  Everything operates fine the next time it is started (including
the saved copy of the email I was writing).

Crash occurs with no apparent trigger from me, I am typing in a new email
body (no html or links in the body area I am typing).  Each time I can
remember no special keystrokes or commands being used near when the crash
symptoms start.  Automatic mail retrieval could be occuring at the time.

Steps to reproduce the problem:
-- Cannot be reproduced on demand --
1. Open mailer, create new mail on pop3 account
2. Write email body

Actual Results:
Evolution is incapable of shutting down on its own, all windows stop
responding and refreshing.

How often does this happen? 
Frequently, it has been 3 times in 8 days of running this version.

Additional Information:
This is the first time I have captured any info about the problem.  If
additional info is needed I can run ev on top of gdb until it occurs again,
but I do not know what other output from gdb would be beneficial (make
requests).
- lmorgul on irc.freenode.net

gdb attached to the process after the crash began, bt below.
(gdb) bt
  • #0 html_link_dup
    from /usr/lib/libgtkhtml-3.1.so.7
  • #1 html_object_copy
    from /usr/lib/libgtkhtml-3.1.so.7
  • #2 html_object_dup
    from /usr/lib/libgtkhtml-3.1.so.7
  • #3 html_text_convert_nbsp
    from /usr/lib/libgtkhtml-3.1.so.7
  • #4 html_object_split
    from /usr/lib/libgtkhtml-3.1.so.7
  • #5 html_engine_reset_blinking_cursor
    from /usr/lib/libgtkhtml-3.1.so.7
  • #6 html_engine_cut
    from /usr/lib/libgtkhtml-3.1.so.7
  • #7 html_engine_cut
    from /usr/lib/libgtkhtml-3.1.so.7
  • #8 html_engine_insert_text_with_extra_attributes
    from /usr/lib/libgtkhtml-3.1.so.7
  • #9 html_engine_paste_text_with_extra_attributes
    from /usr/lib/libgtkhtml-3.1.so.7
  • #10 html_engine_paste_text
    from /usr/lib/libgtkhtml-3.1.so.7
  • #11 gtk_html_im_reset
    from /usr/lib/libgtkhtml-3.1.so.7
  • #12 g_cclosure_marshal_VOID__STRING
    from /usr/lib/libgobject-2.0.so.0
  • #13 g_closure_invoke
    from /usr/lib/libgobject-2.0.so.0
  • #14 g_signal_emit_by_name
    from /usr/lib/libgobject-2.0.so.0
  • #15 g_signal_emit_valist
    from /usr/lib/libgobject-2.0.so.0
  • #16 g_signal_emit_by_name
    from /usr/lib/libgobject-2.0.so.0
  • #17 gtk_im_multicontext_commit_cb
    at gtkimmulticontext.c line 453
  • #18 g_cclosure_marshal_VOID__STRING
    from /usr/lib/libgobject-2.0.so.0
  • #19 g_closure_invoke
    from /usr/lib/libgobject-2.0.so.0
  • #20 g_signal_emit_by_name
    from /usr/lib/libgobject-2.0.so.0
  • #21 g_signal_emit_valist
    from /usr/lib/libgobject-2.0.so.0
  • #22 g_signal_emit_by_name
    from /usr/lib/libgobject-2.0.so.0
  • #23 gtk_im_context_simple_commit_char
    at gtkimcontextsimple.c line 1037
  • #24 no_sequence_matches
    at gtkimcontextsimple.c line 1233
  • #25 gtk_im_context_simple_filter_keypress
    at gtkimcontextsimple.c line 1393
  • #26 gtk_im_context_filter_keypress
    at gtkimcontext.c line 317
  • #27 gtk_im_multicontext_filter_keypress
    at gtkimmulticontext.c line 315
  • #28 gtk_im_context_filter_keypress
    at gtkimcontext.c line 317
  • #29 gtk_html_get_editable
    from /usr/lib/libgtkhtml-3.1.so.7
  • #30 _gtk_marshal_BOOLEAN__BOXED
  • #31 g_cclosure_new_swap
    from /usr/lib/libgobject-2.0.so.0
  • #32 g_closure_invoke
    from /usr/lib/libgobject-2.0.so.0
  • #33 g_signal_emit_by_name
    from /usr/lib/libgobject-2.0.so.0
  • #34 g_signal_emit_valist
    from /usr/lib/libgobject-2.0.so.0
  • #35 g_signal_emit
    from /usr/lib/libgobject-2.0.so.0
  • #36 gtk_widget_event_internal
    at gtkwidget.c line 3563
  • #37 gtk_window_propagate_key_event
    at gtkwindow.c line 4212
  • #38 gtk_window_key_press_event
    at gtkwindow.c line 4242
  • #39 bonobo_window_get_accel_group
    from /usr/lib/libbonoboui-2.so.0
  • #40 _gtk_marshal_BOOLEAN__BOXED
    at gtkmarshalers.c line 82
  • #41 g_cclosure_new_swap
    from /usr/lib/libgobject-2.0.so.0
  • #42 g_closure_invoke
    from /usr/lib/libgobject-2.0.so.0
  • #43 g_signal_emit_by_name
    from /usr/lib/libgobject-2.0.so.0
  • #44 g_signal_emit_valist
    from /usr/lib/libgobject-2.0.so.0
  • #45 g_signal_emit
    from /usr/lib/libgobject-2.0.so.0
  • #46 gtk_widget_event_internal
    at gtkwidget.c line 3563
  • #47 gtk_propagate_event
    at gtkmain.c line 2318
  • #48 gtk_main_do_event
    at gtkmain.c line 1582
  • #49 gdk_event_dispatch
    at gdkevents-x11.c line 2133
  • #50 g_main_depth
    from /usr/lib/libglib-2.0.so.0
  • #51 g_main_context_dispatch
    from /usr/lib/libglib-2.0.so.0
  • #52 g_main_context_dispatch
    from /usr/lib/libglib-2.0.so.0
  • #53 g_main_loop_run
    from /usr/lib/libglib-2.0.so.0
  • #54 bonobo_main
    from /usr/lib/libbonobo-2.so.0
  • #55 main
    at main.c line 600
  8 Thread 38087600 (LWP 1071)  0x0047041a in ?? ()
  7 Thread 57920432 (LWP 1072)  0x0047041a in ?? ()
  6 Thread 85064624 (LWP 1074)  0x0047041a in ?? ()
  5 Thread 123546544 (LWP 1075)  0x0047041a in ?? ()
  4 Thread 1436294064 (LWP 1077)  0x0047041a in ?? ()
  3 Thread 1446783920 (LWP 1243)  0x0047041a in ?? ()
  2 Thread 1457273776 (LWP 1247)  0x0047041a in ?? ()
  1 Thread -150813056 (LWP 1067)  0x00381b22 in html_link_dup () from
/usr/lib/libgtkhtml-3.1.so.7
(gdb) info frame
Stack level 0, frame at 0xfeef19a0:
 eip = 0x381b22 in html_link_dup; saved eip 0x36da98
 called by frame at 0xfeef19b0
 Arglist at 0xfeef1998, args:
 Locals at 0xfeef1998, Previous frame's sp is 0xfeef19a0
 Saved registers:
  ebp at 0xfeef1998, eip at 0xfeef199c
Comment 1 Radek Doulik 2004-05-05 09:24:31 UTC
I suggest trying the newer snapshots. The backtrace unfortunatelly
doesn't say much. It looks like it crashed there only because the
system run out of memory and there's memory allocated in html_link_dup
(g_strdup) :(
Comment 2 Gerardo Marin 2004-10-12 00:29:46 UTC
*** bug 267970 has been marked as a duplicate of this bug. ***
Comment 3 Stanislav Brabec 2005-08-02 10:44:32 UTC
I am able to reproduce this bug about twice a day in the latest evolution
snapshot from SuSE Linux 10.0 Preview 3 (evolution-2.3.3, ) and AMD64 processor.

Note that I am not able to provide backtrace due to bug-buddy problem - it has
no limit for backtrace size and is not able to complete backtrace in a
reasonable time (one hour).
Comment 4 Kaushal Kumar 2005-08-02 11:41:58 UTC
If you could provide some steps or actions which were done, just before the hang
occurs, it would be really useful.
Comment 5 Stanislav Brabec 2006-03-09 23:54:39 UTC
There are more backtraces in Novel Bugzilla:
https://bugzilla.novell.com/show_bug.cgi?id=100135
Comment 6 Stanislav Brabec 2006-04-04 10:28:46 UTC
It seems that this problem was fixed as a side effect of UI redesign:
https://bugzilla.novell.com/show_bug.cgi?id=127570
Comment 7 Veerapuram Varadhan 2007-11-02 19:41:11 UTC
*** Bug 492748 has been marked as a duplicate of this bug. ***
Comment 8 Veerapuram Varadhan 2007-11-02 19:43:52 UTC
Re-opening the bug because of duplicate.  I also agree with Stanislav that this is still no fixed, though the frequency has reduced much.  However, it appears in 2.12.x as well.
Comment 9 Mathias Hasselmann (IRC: tbf) 2007-11-03 08:10:09 UTC
It just happend again. Below seemingly useless backtraces for Ubuntu 7.10. Should see if I can get more debug symbols:

(gdb) thread 1
[Switching to thread 1 (Thread -1233316176 (LWP 7034))]#0  0xffffe410 in __kernel_vsyscall ()
(gdb) backtrace 
  • #0 __kernel_vsyscall
  • #1 poll
    from /lib/tls/i686/cmov/libc.so.6
  • #2 ??
    from /usr/lib/libglib-2.0.so.0
  • #3 ??
  • #4 ??
  • #5 ??
  • #6 ??
  • #7 ??
  • #8 ??
    from /usr/lib/libglib-2.0.so.0
  • #9 pthread_mutex_lock
    from /lib/tls/i686/cmov/libpthread.so.0
  • #10 g_main_loop_run
    from /usr/lib/libglib-2.0.so.0
  • #11 bonobo_main
    from /usr/lib/libbonobo-2.so.0
  • #12 main
    at main.c line 602
  • #13 __libc_start_main
    from /lib/tls/i686/cmov/libc.so.6
  • #14 _start
  • #0 __kernel_vsyscall
  • #1 poll
    from /lib/tls/i686/cmov/libc.so.6
  • #2 ??
    from /usr/lib/libglib-2.0.so.0
  • #3 ??
  • #4 ??
  • #5 ??
  • #6 ??
  • #7 ??
  • #8 ??
  • #0 __kernel_vsyscall
  • #1 poll
    from /lib/tls/i686/cmov/libc.so.6
  • #2 ??
    from /usr/lib/libglib-2.0.so.0
  • #3 ??
  • #4 ??
  • #5 ??
  • #6 ??
  • #7 ??
  • #8 ??
    from /lib/tls/i686/cmov/libc.so.6
  • #9 pthread_mutex_lock
    from /lib/tls/i686/cmov/libpthread.so.0
  • #10 g_main_loop_run
    from /usr/lib/libglib-2.0.so.0
  • #11 startup_mainloop
    at e-book.c line 3767
  • #12 ??
    from /usr/lib/libglib-2.0.so.0
  • #13 ??
  • #0 __kernel_vsyscall
  • #1 pthread_cond_wait
    from /lib/tls/i686/cmov/libpthread.so.0
  • #2 ??
    from /usr/lib/libglib-2.0.so.0
  • #3 ??
  • #4 ??
  • #5 ??
  • #6 g_async_queue_pop_unlocked
    from /usr/lib/libglib-2.0.so.0
  • #7 e_msgport_wait
    at e-msgport.c line 684
  • #8 thread_dispatch
    at e-msgport.c line 1048
  • #9 start_thread
    from /lib/tls/i686/cmov/libpthread.so.0
  • #10 clone
    from /lib/tls/i686/cmov/libc.so.6
  • #0 __kernel_vsyscall
  • #1 pthread_cond_wait
    from /lib/tls/i686/cmov/libpthread.so.0
  • #2 ??
    from /usr/lib/libglib-2.0.so.0
  • #3 ??
  • #4 ??
  • #5 ??
  • #6 g_async_queue_pop_unlocked
    from /usr/lib/libglib-2.0.so.0
  • #7 e_msgport_wait
    at e-msgport.c line 684
  • #8 thread_dispatch
    at e-msgport.c line 1048
  • #9 start_thread
    from /lib/tls/i686/cmov/libpthread.so.0
  • #10 clone
    from /lib/tls/i686/cmov/libc.so.6
  • #0 __kernel_vsyscall
  • #1 pthread_cond_wait
    from /lib/tls/i686/cmov/libpthread.so.0
  • #2 ??
    from /usr/lib/libglib-2.0.so.0
  • #3 ??
  • #4 ??
  • #5 ??
  • #6 g_async_queue_pop_unlocked
    from /usr/lib/libglib-2.0.so.0
  • #7 e_msgport_wait
    at e-msgport.c line 684
  • #8 thread_dispatch
    at e-msgport.c line 1048
  • #9 start_thread
    from /lib/tls/i686/cmov/libpthread.so.0
  • #10 clone
    from /lib/tls/i686/cmov/libc.so.6
  • #0 __kernel_vsyscall
  • #1 pthread_cond_wait
    from /lib/tls/i686/cmov/libpthread.so.0
  • #2 ??
    from /usr/lib/libglib-2.0.so.0
  • #3 ??
  • #4 ??
  • #5 ??
  • #6 g_async_queue_pop_unlocked
    from /usr/lib/libglib-2.0.so.0
  • #7 e_msgport_wait
    at e-msgport.c line 684
  • #8 thread_dispatch
    at e-msgport.c line 1048
  • #9 start_thread
    from /lib/tls/i686/cmov/libpthread.so.0
  • #10 clone
    from /lib/tls/i686/cmov/libc.so.6
  • #0 __kernel_vsyscall
  • #1 poll
    from /lib/tls/i686/cmov/libc.so.6
  • #2 ??
    from /usr/lib/libglib-2.0.so.0
  • #3 ??
  • #4 ??
  • #5 ??
  • #6 ??
  • #7 ??
  • #8 ??
    from /usr/lib/libdbus-1.so.3
  • #9 pthread_mutex_lock
    from /lib/tls/i686/cmov/libpthread.so.0
  • #10 g_main_loop_run
    from /usr/lib/libglib-2.0.so.0
  • #11 ??
    from /usr/lib/libnm_glib.so.0
  • #12 ??
  • #13 ??
  • #14 ___tls_get_addr_internal
    from /lib/ld-linux.so.2
  • #15 ??
    from /usr/lib/libglib-2.0.so.0
  • #16 ??
  • #17 ??
  • #18 ??
    from /lib/tls/i686/cmov/libc.so.6
  • #19 __elf_set___libc_atexit_element__IO_cleanup__
    from /lib/tls/i686/cmov/libc.so.6
  • #20 __rpc_thread_destroy
    from /lib/tls/i686/cmov/libc.so.6
  • #21 start_thread
    from /lib/tls/i686/cmov/libpthread.so.0
  • #22 clone
    from /lib/tls/i686/cmov/libc.so.6
  • #0 __kernel_vsyscall
  • #1 pthread_cond_wait
    from /lib/tls/i686/cmov/libpthread.so.0
  • #2 ??
    from /usr/lib/libglib-2.0.so.0
  • #3 ??
  • #4 ??
  • #5 ??
  • #6 g_async_queue_pop_unlocked
    from /usr/lib/libglib-2.0.so.0
  • #7 e_msgport_wait
    at e-msgport.c line 684
  • #8 thread_dispatch
    at e-msgport.c line 1048
  • #9 start_thread
    from /lib/tls/i686/cmov/libpthread.so.0
  • #10 clone
    from /lib/tls/i686/cmov/libc.so.6

Comment 10 Mathias Hasselmann (IRC: tbf) 2007-11-04 10:37:28 UTC
Guess I've got something more meaningfull this time, indicating a problem in html_object_dup or the undo manager:

  • #0 g_slice_alloc
    from /usr/lib/libglib-2.0.so.0
  • #1 g_list_copy
    from /usr/lib/libglib-2.0.so.0
  • #2 copy
    at htmltext.c line 176
  • #3 html_object_copy
    at htmlobject.c line 1043
  • #4 html_object_dup
    at htmlobject.c line 891
  • #5 object_split
    at htmltext.c line 690
  • #6 html_object_split
    at htmlobject.c line 939
  • #7 split_and_add_empty_texts
    at htmlengine-edit-cut-and-paste.c line 369
  • #8 insert_object_for_undo
    at htmlengine-edit-cut-and-paste.c line 897
  • #9 insert_object
    at htmlengine-edit-cut-and-paste.c line 1141
  • #10 html_engine_insert_text_with_extra_attributes
    at htmlengine-edit-cut-and-paste.c line 1386
  • #11 html_engine_paste_text_with_extra_attributes
  • #12 html_engine_paste_text
    at htmlengine-edit-cut-and-paste.c line 1424
  • #13 gtk_html_im_commit_cb
    at gtkhtml.c line 3237
  • #14 g_cclosure_marshal_VOID__STRING
    from /usr/lib/libgobject-2.0.so.0
  • #15 g_closure_invoke
    from /usr/lib/libgobject-2.0.so.0
  • #16 ??
    from /usr/lib/libgobject-2.0.so.0
  • #17 ??
  • #18 ??

Comment 11 Andrew Farris 2007-11-04 10:58:10 UTC
I haven't used Evolution in over 2 years, but when this was originally reported this error could regularly be backtraced with the hardlockup happening in or near html_object_dup or html_link_dup.  It happened whether editing html mail or not (I usually worked in only text mail without typing links, but the app may really be treating that as an html document internally anyway I'm not sure).

Anyway, I just wanted to say it was normal for those two functions to show up in the last frames of the backtrace, when the machine was graphically locked up but could still be accessed through ssh.
Comment 12 Mathias Hasselmann (IRC: tbf) 2007-11-04 12:19:42 UTC
Ok, there is only one instance of g_list_copy in the copy method of HtmlText:

  dest->spell_errors = g_list_copy (src->spell_errors);

Yes, I had and have unrecognized words in my mail, so for my case the source of pain seems to be a corrupted list of spelling errors? How does spell checking work in Evolution? Per idle handler or per thread? Sure spell checking cannot interrupt any editing  operations meant to be atomic?

Disabling spell checking for now to see if this has an effect.
Comment 13 Stanislav Brabec 2007-11-04 20:04:33 UTC
I don't know, how it happens in Evolution. But from user perspective, this bug occurs probably only if two threads are running at once. I am nearly sure, that it happens if "checking new mail while typing" and maybe also "still checking spelling of previous word while next word is complete".
Comment 14 Matthew Barnes 2007-11-22 15:06:23 UTC
Possibly fixed in bug #495073.
Comment 15 Akhil Laddha 2009-08-06 10:10:38 UTC
(In reply to comment #14)
> Possibly fixed in bug #495073.
> 

Can you please check again whether this issue still happens in Evolution 2.24
or 2.26 and update this report by adding a comment and changing the "Version"
field? Thanks a lot.

Again thank you for reporting this bug and we are sorry it could not be fixed
for the version you originally used here.
Comment 16 Stanislav Brabec 2009-08-06 10:38:32 UTC
It seems that it was fixed sometimes in GNOME 2.22 release cycle and backported to GNOME 2.20.

Please follow:

bug 495073

http://bugzilla.redhat.com/show_bug.cgi?id=353121

https://bugzilla.novell.com/show_bug.cgi?id=100135 (Novell internal)
Comment 17 Akhil Laddha 2009-11-27 05:03:53 UTC
Thanks for taking the time to report this bug; however, closing due to lack of
response of the reporter, sorry. if you still see this issue with a current
release of evolution (2.26.3 or 2.28.x or later), please reopen. thanks in advance.