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 310855 - Evolution uses up all memory when formatting large plain text email.
Evolution uses up all memory when formatting large plain text email.
Status: RESOLVED DUPLICATE of bug 273171
Product: GtkHtml
Classification: Other
Component: Rendering
3.7.x
Other All
: High critical
: ---
Assigned To: gtkhtml-maintainers
Evolution QA team
: 318126 325231 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-07-19 10:49 UTC by Adam
Modified: 2006-03-15 04:25 UTC
See Also:
GNOME target: ---
GNOME version: 2.7/2.8


Description Adam 2005-07-19 10:49:15 UTC 
Steps to reproduce:
1. Select large email with single click and evolution eats up memory as quickly 
as the other programs are swapped out (I'd normally kill it by the time it 
reaches 70% of 700MB).
The email in question is a plain text rsync output so it's larger than the 
average email (10MB) but still shouldn't 'crash' the mailer.

Stack trace:

+ Trace 61851

Thread 1 (Thread 16384 (LWP 25114))

  • #0 mallopt
    from /lib/libc.so.6
  • #1 malloc
    from /lib/libc.so.6
  • #2 g_malloc
    from /usr/lib/libglib-2.0.so.0
  • #3 pango_script_iter_new
    from /usr/lib/libpango-1.0.so.0
  • #4 pango_context_get_metrics
    from /usr/lib/libpango-1.0.so.0
  • #5 pango_itemize_with_base_dir
    from /usr/lib/libpango-1.0.so.0
  • #6 html_text_get_pango_info
    from /usr/lib/libgtkhtml-3.6.so.18
  • #7 html_text_direction_pango_to_html
    from /usr/lib/libgtkhtml-
  • #8 html_object_calc_min_width
    from /usr/lib/libgtkhtml-3.6.so.
  • #9 html_clueflow_style_equals
    from /usr/lib/libgtkhtml-3.6.so.
  • #10 html_object_calc_min_width
    from /usr/lib/libgtkhtml-3.6.so.
  • #11 html_clueflow_style_equals
    from /usr/lib/libgtkhtml-3.6.so.
  • #12 html_object_calc_size
    from /usr/lib/libgtkhtml-3.6.so.18
  • #13 html_cluev_set_style
    from /usr/lib/libgtkhtml-3.6.so.18
  • #14 html_cluev_set_style
    from /usr/lib/libgtkhtml-3.6.so.18
  • #15 html_object_calc_size
    from /usr/lib/libgtkhtml-3.6.so.18
  • #16 html_cluev_set_style
    from /usr/lib/libgtkhtml-3.6.so.18
  • #17 html_cluev_set_style
    from /usr/lib/libgtkhtml-3.6.so.18
  • #18 html_object_calc_size
    from /usr/lib/libgtkhtml-3.6.so.18
  • #19 html_engine_calc_size
    from /usr/lib/libgtkhtml-3.6.so.18
  • #20 html_engine_refresh_fonts
    from /usr/lib/libgtkhtml-3.6.so.
  • #21 html_engine_goto_anchor
    from /usr/lib/libgtkhtml-3.6.so.18
  • #22 html_engine_flush
    from /usr/lib/libgtkhtml-3.6.so.18
  • #23 gtk_html_flush
    from /usr/lib/libgtkhtml-3.6.so.18
  • #24 em_html_stream_get_type
    from /usr/lib/evolution/2.2/
  • #25 em_sync_stream_get_type
    from /usr/lib/evolution/2.2/
  • #26 g_io_channel_unix_get_fd
    from /usr/lib/libglib-2.0.so.0
  • #27 g_idle_remove_by_data
    from /usr/lib/libglib-2.0.so.0
  • #28 g_idle_remove_by_data
    from /usr/lib/libglib-2.0.so.0
  • #29 g_main_loop_run
    from /usr/lib/libglib-2.0.so.0
  • #30 bonobo_main
    from /usr/lib/libbonobo-2.so.0
  • #31 main
  • #0 __pthread_sigsuspend
    from /lib/libpthread.so.0 


Other information:
Comment 1 Nagappan Alagappan 2005-07-20 08:13:03 UTC 
Adam: I'm unable to reproduce this bug. I tried wiht Evolution 2.3.4 and gtkhtml
3.7.4. I tried an attachment with 38 MB and I don't face any such issues as
stated in this bug. I tried rpm file as attachment. What type of attachment you
tried ?
Comment 2 Adam 2005-07-20 11:13:41 UTC 
Thanks for the reply. Attachments are fine, it's when you actually try to 
display the contents that the problem arises. It turns out that it isn't a 
problem specific to the 10MB email, it's just a reflection of the heavy memory 
usage involved in displaying large emails. I used the following to generate 
various sized emails:

cat /dev/urandom | uuencode -m - | grep -v base64 \ 
| dd bs=1k count=5000 |mail -s 5mb <email address>

Here are the virtual sizes of evolution after startup and displaying 1 email:

1KB - 139MB
1MB - 181MB
3MB - 282MB
5MB - 392MB

The memory also isn't freed after viewing a different email. I'm not sure how 
much memory is considered too much for this kind of thing.
The version of gtkhtml I'm using is 3.6.2, I don't seem to have any newer 
versions listed using my preferred install system.

Adam.
Comment 3 Nagappan Alagappan 2005-08-04 13:35:53 UTC 
Shaheed / Subodh / Shilpa ?
Hey guys can you regress this bug in IMAP / Groupwise / Exchange mailer ?
Comment 4 Kaushal Kumar 2005-10-24 05:43:01 UTC 
Needinfo.
Comment 5 Kaushal Kumar 2005-10-24 05:47:28 UTC 
*** Bug 318126 has been marked as a duplicate of this bug. ***
Comment 6 André Klapper 2005-10-26 13:38:56 UTC 
adding memory keyword
Comment 7 Adam 2005-12-13 12:13:44 UTC 
Due to the amount of spam I'm now getting to the address I used solely for 
submitting this bug report I'm no longer going to be collecting email destined 
for this address. Maybe you could prevent bugzilla from putting email addresses 
directly into the html whilst you are fixing this bug ;)

Thanks,

Adam.
Comment 8 Rohini 2006-02-24 09:35:22 UTC 
*** Bug 325231 has been marked as a duplicate of this bug. ***
Comment 9 Rohini 2006-03-15 04:25:48 UTC 

*** This bug has been marked as a duplicate of 273171 ***