RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 949610 - Don't block UI while downloading message attachment
Summary: Don't block UI while downloading message attachment
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: evolution
Version: 6.4
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: rc
: ---
Assignee: Matthew Barnes
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-04-08 15:38 UTC by David Jaša
Modified: 2014-01-02 10:45 UTC (History)
3 users (show)

Fixed In Version: evolution-2.32.3-15.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-11-21 05:11:00 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
full backtrace (12.12 KB, text/plain)
2013-04-08 15:38 UTC, David Jaša 		no flags Details
evolution-2.28.3-async-load.patch (4.47 KB, patch)
2013-04-09 12:31 UTC, Milan Crha 		no flags Details | Diff
View All


Links
System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 600860 0 None None None Never
Red Hat Product Errata RHSA-2013:1540 0 normal SHIPPED_LIVE Low: evolution security, bug fix, and enhancement update 2013-11-21 00:40:51 UTC

Description David Jaša 2013-04-08 15:38:14 UTC 
Created attachment 732721 [details]
full backtrace

Description of problem:
When the message body or attachment is being downloaded, the evo UI is frozen.

Version-Release number of selected component (if applicable):


How reproducible:
always

Steps to Reproduce:
1. have a large message (message with large attachment) in your inbox
2. make sure that the message/attachment in question is not cached
3. click the message in msglist, if the message loads, click attachment
  
Actual results:
evo UI blocks for the time of the download without any visual cue that it is actually well and alive

Expected results:
evo UI keeps responding while the transfert takes place in the background

Additional info:
backtrace taken during download of MB-sized attachment over GPRS/EDGE connection (~ 25 kB/s - download time in order of minutes) - note that both transfer and UI takes place in Thread 1. Full backtrace is attached as a file

Thread 1 (Thread 0x7f44c483a980 (LWP 28990)):
#0  0x00000036aa2df253 in __poll (fds=<value optimized out>, nfds=<value optimized out>, timeout=<value optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:87
#1  0x0000003b23c26579 in ?? () from /lib64/libnspr4.so
#2  0x0000003b23c2746d in ?? () from /lib64/libnspr4.so
#3  0x0000003b2441b1ed in ssl_DefRecv (ss=<value optimized out>, buf=<value optimized out>, len=1408, flags=<value optimized out>) at ssldef.c:62
#4  0x0000003b24416480 in ssl3_GatherData (ss=0x6575ce0, flags=0) at ssl3gthr.c:59
#5  ssl3_GatherCompleteHandshake (ss=0x6575ce0, flags=0) at ssl3gthr.c:318
#6  0x0000003b244169ea in ssl3_GatherAppDataRecord (ss=0x6575ce0, flags=0) at ssl3gthr.c:404
#7  0x0000003b2442050a in DoRecv (ss=0x6575ce0, buf=0x7f44ad00554c '\023' <repeats 200 times>..., len=12137297, flags=0) at sslsecur.c:535
#8  ssl_SecureRecv (ss=0x6575ce0, buf=0x7f44ad00554c '\023' <repeats 200 times>..., len=12137297, flags=0) at sslsecur.c:1144
#9  0x0000003b244247d2 in ssl_Read (fd=<value optimized out>, buf=0x7f44ad00554c, len=12137297) at sslsock.c:2112
#10 0x0000003b2684c152 in stream_read (stream=<value optimized out>, buffer=0x7f44ad00554c '\023' <repeats 200 times>..., n=12137297) at camel-tcp-stream-ssl.c:347
#11 0x0000003b258472a6 in stream_read (stream=<value optimized out>, buffer=
    0x7f44aceeb011 "UEsDBBQAAgAIAOhucEKOkKdcAh4QAFoWEAAKAAAASU1HMDI2LmpwZ5xUeTyUaxt+39mM4ZD1KERZ\r\nxgmnGUz2PUSklH0pe7ZK1sqk7HKSGVmyK0xiyr6GT2Rp4SBLqI79cBJCdvO9Y6vvd84f3/fdv9/9\r\n3tfzvNdzP9f1Ps/vpfXRhn5J0/J3cQIAAwPgCAAAaAAN"..., n=12137297) at camel-stream-buffer.c:247
#12 0x00007f44b75fe281 in imap_read_untagged (store=0x1369620, response=0x7fffa437ea78, ex=0x0) at camel-imap-command.c:489
#13 camel_imap_command_response (store=0x1369620, response=0x7fffa437ea78, ex=0x0) at camel-imap-command.c:342
#14 0x00007f44b75fe71c in imap_read_response (store=0x1369620, ex=0x0) at camel-imap-command.c:396
#15 0x00007f44b75ff045 in camel_imap_command (store=0x1369620, folder=0x16ec980, ex=0x0, fmt=<value optimized out>) at camel-imap-command.c:116
#16 0x00007f44b75ffd89 in camel_imap_folder_fetch_data (imap_folder=0x16ec980, uid=0x62bc7e0 "16394", section_text=<value optimized out>, cache_only=0, ex=0x0) at camel-imap-folder.c:3827
#17 0x00007f44b7614a30 in write_to_stream (data_wrapper=0x5c40ec0, stream=0x64962d0) at camel-imap-wrapper.c:139
---Type <return> to continue, or q <return> to quit---
#18 0x0000003b2581f450 in decode_to_stream (data_wrapper=0x5c40ec0, stream=<value optimized out>) at camel-data-wrapper.c:210
#19 0x0000003b25833a1b in camel_mime_part_get_content_size (mime_part=<value optimized out>) at camel-mime-part.c:1125
#20 0x0000003b26432a08 in attachment_load_from_mime_part (attachment=<value optimized out>, callback=<value optimized out>, user_data=<value optimized out>) at e-attachment.c:1785
#21 e_attachment_load_async (attachment=<value optimized out>, callback=<value optimized out>, user_data=<value optimized out>) at e-attachment.c:1853
#22 0x00007f44bc3fbcb3 in efhd_attachment_button (efh=0x167b0c0 [EMFormatHTMLDisplay], eb=0x5a16e00 [GtkHTMLEmbedded], pobject=<value optimized out>) at em-format-html-display.c:1419
#23 0x00007f44bc3fc9fe in efh_object_requested (html=<value optimized out>, eb=0x5a16e00 [GtkHTMLEmbedded], efh=0x167b0c0 [EMFormatHTMLDisplay]) at em-format-html.c:637
#24 0x0000003831677488 in html_g_cclosure_marshal_BOOLEAN__OBJECT (closure=0x16a6ce0, return_value=0x7fffa437f050, n_param_values=<value optimized out>, param_values=0x37f6430, 
    invocation_hint=<value optimized out>, marshal_data=<value optimized out>) at htmlmarshal.c:81
#25 0x00000036ac60bb3e in IA__g_closure_invoke (closure=0x16a6ce0, return_value=0x7fffa437f050, n_param_values=2, param_values=0x37f6430, invocation_hint=0x7fffa437eec0) at gclosure.c:767
#26 0x00000036ac620e23 in signal_emit_unlocked_R (node=<value optimized out>, detail=0, instance=0x14f1660, emission_return=0x7fffa437f050, instance_and_params=0x37f6430) at gsignal.c:3247
#27 0x00000036ac621f4a in IA__g_signal_emit_valist (instance=<value optimized out>, signal_id=<value optimized out>, detail=<value optimized out>, var_args=0x7fffa437f0b0) at gsignal.c:2990
#28 0x00000036ac6225f3 in IA__g_signal_emit (instance=<value optimized out>, signal_id=<value optimized out>, detail=<value optimized out>) at gsignal.c:3037
#29 0x0000003831634e4e in html_engine_object_requested_cb (engine=<value optimized out>, eb=0x5a16e00 [GtkHTMLEmbedded], data=0x14f1660) at gtkhtml.c:550
Comment 1 David Jaša 2013-04-08 16:08:36 UTC 
clickable upstream bug: https://bugzilla.gnome.org/show_bug.cgi?id=600860
Comment 2 Milan Crha 2013-04-09 12:31:01 UTC 
Created attachment 733191 [details]
evolution-2.28.3-async-load.patch

Backport of the upstream bug patch. It works as expected, according to my test.
Comment 3 David Jaša 2013-04-09 14:07:48 UTC 
I forgot rhel build where I reproduced the behaviour so here it is:
evolution-2.28.3-30.el6.x86_64
Comment 10 Milan Crha 2013-07-25 10:21:35 UTC 
I updated a patch for asynchronous attachment load, because each view of a message with an image attachment caused pair of runtime warnings:
> GLib-GIO-CRITICAL **: g_file_info_set_size: assertion `G_IS_FILE_INFO (info)'
> failed
> GLib-GIO-CRITICAL **: g_file_info_get_icon: assertion `G_IS_FILE_INFO (info)'
> failed
due to asynchronous load, when the file_info held on EAttachment was not set yet.

It's part of evolution-2.32.3-15.
Comment 13 errata-xmlrpc 2013-11-21 05:11:00 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2013-1540.html
Note You need to log in before you can comment on or make changes to this bug.