Bug 3791 - Fancy plugin may hang with full CPU load
Summary: Fancy plugin may hang with full CPU load
Status: NEW
Alias: None
Product: Claws Mail (Windows)
Classification: Unclassified
Component: default (show other bugs)
Version: 3.15.0
Hardware: PC Windows 8
: P3 normal
Assignee: users
URL:
Depends on:
Blocks:
 
Reported: 2017-03-27 17:00 CEST by m
Modified: 2019-08-29 19:36 CEST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description m 2017-03-27 17:00:10 CEST
Hi,

As I just selected a RSS feed with a single news item and marked it as read with Ctrl-M, Claws Mail was caught in a hang. The task showed as eating up 25% CPU (one full core) and with a solid 80-120MB/s I/O throughout.

Just as I'd downloaded and installed WhatIsHang, it seemed Claws Mail snapped out of it and successfully marked the news item as read. Will keep an eye out for it happening again. This is a regression - never happened to me in 3.14.1 and prior.
Comment 1 m 2017-03-27 17:43:09 CEST
Note, this was 64-bit.
Comment 2 Andrej Kacian 2017-03-27 17:45:38 CEST
Can you reproduce this behavior, perhaps by removing that feed and subscribing to it again? Can you share URL of that feed so that I can try too?
Comment 3 m 2017-03-27 21:29:03 CEST
I'm pretty sure it was the Guru3D newsfeed (http://www.guru3d.com/files-rss). I'd disabled thread view and selected 'hide read messages' previously.

Deleting and re-adding didn't reproduce the issue, and I've since marked news items in a couple of other RSS feeds as read without a hang.

It also was the very first thing I did after I started up the new version, once the list of feeds had finished updating. That might have something to do with it. If it happens again, I'll try to catch it.
Comment 4 m 2017-03-28 01:28:42 CEST
It happened again. This time I clicked on a RSS news item and Claws hung itself with the view window showing the item as 50% loaded. It again took about 40 seconds before the program was responsive once more. Here's the info:

https://pastebin.com/9qje4793
Comment 5 m 2017-03-28 01:31:01 CEST
This time the feed in question was https://www.youtube.com/feeds/videos.xml?user=thembpg but I believe it has nothing to do with any particular feed.
Comment 6 Andrej Kacian 2017-03-28 12:05:22 CEST
I agree, this has likely nothing to do with particular feeds. I just wanted to make sure we're working with the same "data", so to speak.

Anyway, can you try unloading the Fancy HTML Viewer plugin for a while to see if these crashes stop?

Also, if you can, please try the 32-bit version of Claws Mail (with Fancy loaded, of course).
Comment 7 wwp 2017-03-28 12:40:56 CEST
I often get some feeds that take ages (few seconds, up to maybe 30 sec) to refresh, of course what is wrong there, comes from DNS or remote servers, but it's true that it locks CM GUI in a way that is irritating. What I did for such feeds (when identified) is to reduce their update frequency or make sure refresh happens when I'm off.
Comment 8 m 2017-03-28 15:35:33 CEST
Will do, Andrej. I run 2 installations with identical settings so I can try 'em both. ;)

wwp, a program hang with 'spinning tires' CPU & I/O use is not the same as waiting for a slow refresh. And I've personally never experienced an UI lock from a slow refresh, either. I've got a whole boatload of feeds. They run automatically every 30 minutes and are usually quick to present new items. This is basically a new problem I'm describing. Been using the application since 3.12 or so.
Comment 9 m 2017-03-28 23:05:46 CEST
It happened in 32-bit too just now, clicking on a random feed item. Running Fancy and RSSyl. When Claws stopped responding, Fancy was stuck at 0% loaded.

The trace is here: https://pastebin.com/h6ZtUZJq
Comment 10 m 2019-08-29 17:05:24 CEST
Commenting to verify that it still happens in 3.17.4 32-bit.
Comment 11 Andrej Kacian 2019-08-29 19:36:10 CEST
Yes, I've seen this happening too, sometimes - first HTML display via Fancy takes a while. I believe it is due to the first load of the Webkit library, and some initializations therein.

I'm not sure what to do about it. I will try running it through a profiler to try to see where it's spending so much CPU cycles.