Bug 720928 – Hangs in libwebkitgtk?

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 720928 - Hangs in libwebkitgtk?


Summary:	Hangs in libwebkitgtk?


Status:	RESOLVED DUPLICATE of bug 743926

Product:	evolution
Classification:	Applications
Component:	Mailer
Version:	3.10.x (obsolete)
Hardware:	Other Linux

Importance:	Normal normal
Target Milestone:	---
Assigned To:	evolution-mail-maintainers
QA Contact:	Evolution QA team

URL:
Whiteboard:

Depends on:
Blocks:

Reported:	2013-12-22 11:50 UTC by Hans Petter Jansson
Modified:	2015-03-31 15:16 UTC

See Also:
GNOME target:	---
GNOME version:	---

Attachments
Backtrace (no debuginfo). (15.02 KB, application/octet-stream) 2013-12-22 11:50 UTC, Hans Petter Jansson	Details

Description Hans Petter Jansson 2013-12-22 11:50:18 UTC

Created attachment 264754 [details]
Backtrace (no debuginfo).

Evolution frequently hangs when reading mail, even in offline mode. The UI becomes unresponsive and does not redraw.

I don't have debug symbols installed currently, but it *looks* like the hang might be in webkit calls. Attaching a backtrace. I'll try to come up with one with proper debuginfo.

Comment 1 Milan Crha 2014-02-05 17:30:05 UTC

Thanks for a bug report. You are right, the UI thread (main thread,
the Thread 1) is doing something in webkit library. Hard to tell what it is, without debug symbols. Would it be possible that it's not stuck, but does some busy loop? You may realize when looking on a CPU usage by evolution, if it's high, then it's a busy loop.

Comment 2 Hans Petter Jansson 2014-02-17 13:58:19 UTC

This was happening on a slow Internet connection -- I reported it because I don't think this should hang the main UI, and I didn't see it in earlier Evolution versions.

I'm *pretty* sure it wasn't a CPU hang (I used to have the system monitor applet running because it gave me a lot of contextual information in situations like this :).

It hasn't happened in a while now, but I've only had reliable Internet connections to test it with.

Comment 3 Brian J. Murrell 2015-03-17 20:26:33 UTC

Yeah, this (also) happens when opening a large (IMAP) message; the entire UI blocks while the message is loaded/parsed.  strace(1) doesn't even show it to be terribly busy while it's working away but top does.  The thread that is consuming 100% of a core has the following backtrace:

+ Trace 234866

#0 WebCore::Style::nextSiblingRenderer(WebCore::Text const&)
#1 WebCore::Style::createTextRendererIfNeeded(WebCore::Text&)
#2 WebCore::Style::attachChildren(WebCore::ContainerNode&)
#3 WebCore::Style::attachRenderTree(WebCore::Element&, WTF::PassRefPtr<WebCore::RenderStyle>)
#4 WebCore::Style::attachChildren(WebCore::ContainerNode&)
#5 WebCore::Style::attachRenderTree(WebCore::Element&, WTF::PassRefPtr<WebCore::RenderStyle>)
#6 WebCore::Style::attachChildren(WebCore::ContainerNode&)
#7 WebCore::Style::attachRenderTree(WebCore::Element&, WTF::PassRefPtr<WebCore::RenderStyle>)
#8 WebCore::Style::resolveTree(WebCore::Element&, WebCore::Style::Change)
#9 WebCore::Style::resolveTree(WebCore::Document&, WebCore::Style::Change)
#10 WebCore::Document::recalcStyle(WebCore::Style::Change)
#11 WebCore::Document::updateStyleIfNeeded()
#12 WebCore::Document::finishedParsing()
#13 WebCore::HTMLDocumentParser::prepareToStopParsing()
#14 WebCore::HTMLDocumentParser::finish()
#15 WebCore::DocumentWriter::end()
#16 WebCore::DocumentLoader::finishedLoading(double)
#17 WebCore::CachedResource::checkNotify()
#18 WebCore::CachedRawResource::finishLoading(WebCore::ResourceBuffer*)
#19 WebCore::SubresourceLoader::didFinishLoading(double)
#20 WebCore::readCallback(_GObject*, _GAsyncResult*, void*)
#21 async_ready_callback_wrapper
#22 g_task_return_now
#23 complete_in_idle_cb
#24 g_main_context_dispatch
#25 g_main_context_iterate.isra
#26 g_main_loop_run
#27 gtk_main
#28 main
at main.c line 685

Comment 4 Milan Crha 2015-03-31 15:16:40 UTC

Brian, your backtrace belongs to bug #743926. I guess Hans' backtrace is the same, thus let's mark this as a duplicate of it.

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