Bug 303634 – 100% CPU Usage on message open

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 303634 - 100% CPU Usage on message open


Summary:	100% CPU Usage on message open


Status:	RESOLVED FIXED

Product:	GtkHtml
Classification:	Other
Component:	Parsing
Version:	3.7.x
Hardware:	Other All

Importance:	High major
Target Milestone:	2.5
Assigned To:	gtkhtml-maintainers
QA Contact:	Evolution QA team

URL:
Whiteboard:

Duplicates:	306279 320875 326074 (view as bug list)
Depends on:
Blocks:

Reported:	2005-05-10 07:56 UTC by Jeremy Nickurak
Modified:	2006-06-12 12:11 UTC

See Also:
GNOME target:	---
GNOME version:	2.9/2.10

Attachments
Importable message that causes described problem. (28.65 KB, application/octet-stream) 2005-05-10 07:58 UTC, Jeremy Nickurak		Details
patch (1.37 KB, patch) 2006-02-13 04:31 UTC, Rohini	committed	Details \| Review

Description Jeremy Nickurak 2005-05-10 07:56:51 UTC

Steps to reproduce:
1. Import the attached message
2. Attempt to open said message

Evolution freezes and consumes 100% CPU until force-killed.

Stack trace:


Other information:

Comment 1 Jeremy Nickurak 2005-05-10 07:58:08 UTC

Created attachment 46270 [details]
Importable message that causes described problem.

Comment 2 Nagappan Alagappan 2005-05-11 11:05:19 UTC

+ Trace 59487

Thread 7 (Thread 81926 (LWP 13117))

#0 __pthread_sigsuspend
from /lib/libpthread.so.0
#1 __pthread_wait_for_restart_signal
from /lib/libpthread.so.0
#2 pthread_cond_wait
from /lib/libpthread.so.0
#3 e_msgport_wait
at e-msgport.c line 511
#4 thread_dispatch
at e-msgport.c line 874
#5 pthread_start_thread
from /lib/libpthread.so.0
#6 clone
from /lib/libc.so.6

Thread 6 (Thread 65541 (LWP 13116))

#0 __pthread_sigsuspend
from /lib/libpthread.so.0
#1 __pthread_wait_for_restart_signal
from /lib/libpthread.so.0
#2 pthread_cond_wait
from /lib/libpthread.so.0
#3 e_msgport_wait
at e-msgport.c line 511
#4 thread_dispatch
at e-msgport.c line 874
#5 pthread_start_thread
from /lib/libpthread.so.0
#6 clone
from /lib/libc.so.6

Thread 5 (Thread 49156 (LWP 13114))

#0 __pthread_sigsuspend
from /lib/libpthread.so.0
#1 __pthread_wait_for_restart_signal
from /lib/libpthread.so.0
#2 pthread_cond_wait
from /lib/libpthread.so.0
#3 e_msgport_wait
at e-msgport.c line 511
#4 sync_op
at em-sync-stream.c line 225
#5 stream_flush
at em-sync-stream.c line 299
#6 camel_stream_flush
at camel-stream.c line 136
#7 do_flush
at camel-stream-filter.c line 365
#8 camel_stream_flush
at camel-stream.c line 136
#9 do_flush
at camel-stream-filter.c line 365
#10 camel_stream_flush
at camel-stream.c line 136
#11 do_flush
at camel-stream-filter.c line 365
#12 camel_stream_flush
at camel-stream.c line 136
#13 decode_to_stream
at camel-data-wrapper.c line 209
#14 camel_data_wrapper_decode_to_stream
at camel-data-wrapper.c line 233
#15 em_format_format_text
at em-format.c line 1080
#16 efh_text_plain
at em-format-html.c line 732
#17 em_format_part_as
at em-format.c line 584
#18 em_format_part
at em-format.c line 611
#19 efh_format_message
at em-format-html.c line 1708
#20 efhd_format_message
at em-format-html-display.c line 1065
#21 efh_format_do
at em-format-html.c line 1164
#22 mail_msg_received
at mail-mt.c line 556
#23 thread_received_msg
at e-msgport.c line 826
#24 thread_dispatch
at e-msgport.c line 907
#25 pthread_start_thread
from /lib/libpthread.so.0
#26 clone
from /lib/libc.so.6

Thread 4 (Thread 32771 (LWP 13112))

#0 __pthread_sigsuspend
from /lib/libpthread.so.0
#1 __pthread_wait_for_restart_signal
from /lib/libpthread.so.0
#2 pthread_cond_wait
from /lib/libpthread.so.0
#3 e_msgport_wait
at e-msgport.c line 511
#4 thread_dispatch
at e-msgport.c line 874
#5 pthread_start_thread
from /lib/libpthread.so.0
#6 clone
from /lib/libc.so.6

Thread 3 (Thread 16386 (LWP 13111))

#0 __pthread_sigsuspend
from /lib/libpthread.so.0
#1 __pthread_wait_for_restart_signal
from /lib/libpthread.so.0
#2 pthread_cond_wait
from /lib/libpthread.so.0
#3 e_msgport_wait
at e-msgport.c line 511
#4 thread_dispatch
at e-msgport.c line 874
#5 pthread_start_thread
from /lib/libpthread.so.0
#6 clone
from /lib/libc.so.6

Comment 3 Not Zed 2005-05-19 12:55:26 UTC

gtkhtml stuff

Comment 4 Ganesh (Novell) 2005-05-20 09:22:55 UTC

I don't think it is a bug. It is just the mail is lengthy (450 pages ???) so it
takes long time to display. Otherwise it works fine.

Comment 5 Jeremy Nickurak 2005-05-20 19:42:20 UTC

Even so, a long email really can't be allowed to consume evolution's exclusive
attention for very long. If the user's trying to give up on it and open another
message/folder, or even just close evolution, they should be able to, right?

Comment 6 Krishnan R 2005-09-02 14:51:15 UTC

I am marking this as "Major" which can be addressed post GNOME 2.12.

Comment 7 André Klapper 2005-10-09 19:42:06 UTC

adding keywords

Comment 8 Behdad Esfahbod 2005-11-08 18:52:29 UTC

removing keywords

Comment 9 Johnny Proton 2005-12-26 22:39:18 UTC

*** Bug 320875 has been marked as a duplicate of this bug. ***

Comment 10 Rohini 2006-01-10 05:59:39 UTC

*** Bug 326074 has been marked as a duplicate of this bug. ***

Comment 11 Rohini 2006-02-09 08:58:02 UTC

The mail has a lot of blank lines. Similar to 306279.

Comment 12 Rohini 2006-02-09 11:26:28 UTC

Every paragraph in a mail should be associated with a direction. When a mail has many blank lines, each CR is treated as a paragraph. To associate a direction to the blank-line, the previous paragraph's dir is acquired using the functions html_object_get_direction and html_clueflow_real_get_direction. 

In this case, the previous paragraph is also empty. So the function calls proceed until a paragraph with proper direction is obtained. This happens for every blank paragraph

Assuming a mail with 100 blank paragraphs... The no of function calls to determine dir for a blank paragraph is...

1st line --> 1 call to object_get_dir, 1 to cluflow_real_get_dir
2nd line --> 2 calls to object_get_dir, 2 to cluflow_real_get_dir
3rd line --> 3 calls to object_get_dir, 3 to cluflow_real_get_dir
.
.
.
.
.
.
.

.
100th line --> 100 calls to object_get_dir, 100 to cluflow_real_get_dir

The total number of function calls to refresh the preview pane for 100 blank lines amounts to 100! +100! (Huh...) This mail with more than 25000 blank lines would  definitely eat the processor.

Why should we put in so much effort to get the direction for a paragraph that has nothing?

Comment 13 Rohini 2006-02-13 04:31:17 UTC

Created attachment 59229 [details] [review]
patch

Comment 14 Rohini 2006-02-24 09:42:25 UTC

*** Bug 306279 has been marked as a duplicate of this bug. ***

Comment 15 Harish Krishnaswamy 2006-06-12 12:11:01 UTC

Reviewed and committed in HEAD and the gnome-2-14 branches.