download stuck not updating any feeds #1276
Comments
|
libglib-2_0-0-2.76.4-1.1.x86_64 |
|
During updates, the last message is 499/1092. |
|
Threre's a couple URLs where libsoup is not timing out, the https connection is getting closed, and the job callback is never called. I'm working on a test case outside of liferea to debug libsoup. There may be another problem, as I have a work-around in place and updates are still not working. |
|
There's two issues I also seeing in the current setup
|
|
I have a better handle on the issue, but no solution yet.
I'm still working on a test case that exhibits the issue. |
|
@rich-coe That's ugly. I could not reproduce the problem so far. I'll research whether there is some good timeout handling possible killing old requests. |
|
Here's a log of what I'm observing: |
|
Here's a the log from G_MESSAGES_DEBUG=all, I don't know why I didn't have it on earlier. The issue is the [GOAWAY], I'm assuming the connection is closed. |
|
Opened libsoup#363 to track this issue. |
|
Submitted merge request to libsoup with patch https://gitlab.gnome.org/GNOME/libsoup/-/merge_requests/377 |
|
Log with patch: |
|
I think this is occurring with the following sequence:
I am going to revisit generating a test case with this new information. |
|
I've modified update.c to use GThreadPool, one for high priority, 3 entries, and one for non-high priority, 3 entries. I'm still facing yet another bug in libsoup, so I'm still not satisfied with it. |
|
@rich-coe Thanks for investigating this! |
|
I've made one more change to improve job handling. I'm currently chasing the And libsoup#393 which happened only once, while I was chasing down libsoup#394, but looks similar in that libsoup is trying to read from a closed stream but on a http2 socket. I started chasing down the feedburner bug with -fsanitize=address as valgrind did not work for me (liferea memory space too large?). I now have compiled libsoup with -fsanitize as well, and I am waiting for one of the feeds to be unhappy. |
|
After fixing libsoup#393 to fix running synchronous libsoup on separate threads, I'm working on the next bug with -fsanitize=address. Below is several crashes and the debug output from libsoup/glib on the url causing the crash. The last output has the sanitize output. Unfortunately, I didn't have libnghttp2 compiled with -g when I built it for -fsanitize. I'm now running with -g in libnghttp2 along with -fsanitize. I hope the line numbers help me track down the issue. From the debug, it looks like the url host is closing the socket early which is causing the issue in libnghttp2 and/or libsoup. I'm going to write a small test case using the host urls causing the issue and see if I can get the error to happen more frequently. The error doesn't happen often. I'm only updating feeds at 4 hour intervals. ::::: lfx.1905 ::::: ::::: lfx.1906 ::::: ::::: lfx.1908 ::::: ::::: lfx.1918 ::::: ::::: lfx.1920 ::::: |
|
Tracking libnghttp2#2251 AddressSanitizer: heap-buffer-overflow nghttp2_hd_huff_decode |
|
After growing disillusioned by libsoup (3 bugs and growing), and then libnghhtp2 (or libsoup's use there of), I looked for another approach. Looking I found libcurl, and hey, didn't liferea used to use libcurl? YES. So without importing the 'glibcurl', I built using libcurl. I have an implementation working. I'd like to get several days (a week or so of runtime) to shake out any errors. All is not roses yet. I have to figure out how to fetch org.gnome.system.proxy values from dbus to get the current user's proxy settings. I'd also like to show the connection error status on the feed status page. But not strictly necessary for this solution to get reviewed. |
|
The actually sad thing is that one would think with libsoup3 being a GNOME base library it would be highly stable and well tested. |
|
In libsoup's defense, I think the primary issue is sockets to a server that get closed because of either rate limiting or 'too many attempts from this ip', where they are not closed normally, but forcefully/abnormally shutdown. It's also very hard to debug.
|
|
@rich-coe Would it help eliminating the HTTP2 code path entirely by disabling some libsoup3 feature flag. I guess HTTP2 for a feed reader is only additional overhead. |
|
This exact same thing is happening to me. My feed updates just freeze on one feed and refuse to update any further. Using the update monitor to Stop all updates and try updating again does not work - liferea must be restarted before I can update again. It only started since I updated to Fedora 40 with 15.4, in case that is important. I am also having to only run liferea via the webkit workaround in case that is relevant. I have tried updating to F41 / 15.7 and that did not change anything. This bug has sadly made liferea pretty much unusable to me because I cannot reliably update my feeds. (Been a very happy user for at least 10 years!) Happy to post whatever log would be helpful if you can tell me how to pull it. |
|
@SenorFusion |
|
@SenorFusion |
|
@lwindolf |
@rich-coe Thank you for this! I spent a few minutes and couldn't get it to compile and I don't have time to chase down all the dependencies right now, but hopefully someone with the build setup can test and merge it into main. |
|
@SenorFusion |
Fedora 40. I also tried on a clean install of 41 and got similar results and here if I run configure instead of the autogen script and here if I try the recommend env var issue: |
|
@SenorFusion |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
updated/pulled up to master 3acb5bc to pick up new glib/webkit changes
RSS feed updates hang with all requests in the 'Pending Queue'.
I tried --debug-net but observed no obvious messages.
During debugging, numberOfActiveJobs = 1, but nothing is obviously stuck.
Looking into debugging/tracing glib queue processing.
The text was updated successfully, but these errors were encountered: