[BUG]: RSS Guard crashing upon fetching a feed

[rxxsta]

Brief description of the issue

RSS Guard 4.2.5 AppImage Crashes when fetching any/all feeds from initial feeds of RSS/ATOM/JSON.

How to reproduce the bug?

1. Launch RSS Guard 4.2.5: ./rssguard-4.2.5-828697bd-nowebengine-linux64.AppImage
2. Add new account prompts
3. Select RSS/RDF/ATOM/JSON
4. Select OK
5. Network proxy prompts
6. Select System proxy
7. Select OK
8. Load initial set of feeds prompts
9. Select Yes
10. Initial RSS feeds load
11. Right click any feed
12. Select "Fetch Selected"
13. Application closes
14. After crash, and upon reopening, the respective feed is populated. Note: "Fetch all" also causes a crash.

What was the expected result?

To fetch a feed without a crash

What actually happened?

Fetching a feed caused a crash, needed to restart application

Debug log

debug.log

Operating system and version

• OS: EndeavourOS Linux x86_64 (KDE Desktop Environment)
• RSS Guard version: 4.2.5

[akinokonomi]

Can reproduce it. Same error.

The problem seems to be the notifications.

Unchecking Settings -> Notifications -> Enable notifications fixes it.

---

How to reproduce the bug?

1. Launch RSS Guard 4.2.5: `./rssguard-4.2.5-828697bd-nowebengine-linux64.AppImage`

2. Add new account prompts

3. Select RSS/RDF/ATOM/JSON

4. Select OK

5. Network proxy prompts

6. Select System proxy

7. Select OK

8. Load initial set of feeds prompts

9. Select Yes

10. Initial RSS feeds load

11. Right click any feed

12. Select "Fetch Selected"

13. Application closes

14. After crash, and upon reopening, the respective feed is populated.
    Note: "Fetch all" also causes a crash.

@rxxsta Please don't be so verbose.
This much is enough:

1. Start RSS Guard nowebengine appimage with clean config
2. Create new RSS/RDF/ATOM/JSON account
3. Load initial feeds list
4. Fetch any feed
5. If new articles were fetched, RSS Guard crashes

[rxxsta]

Sorry for the extra stuff. And thank you, this has solved the problem.

[akinokonomi]

Sorry for the extra stuff.

No need to be. It's okay.

this has solved the problem.

Thanks for confirming it.

To add to it , the webengine version crashes as well.

[martinrotter]

Yes, this is known problem and at this point AppImage is semi-broken. Precise reason is that I migrated to Qt 6 for AppImage and the tool which generates AppImage does not really support bundling "gstreamer" libraries to play sounds in a good way, it is buggy.

Theoretically, it is only enough to disable playing sounds in notifications.

Seeing this, I might revert to qt 5 for appimage. Not really sure tho.

[martinrotter]

Well, let me describe the situation.

There is a tool which is great at generating AppImages - https://github.com/probonopd/linuxdeployqt

The tool needs to be run on "OLDEST LTS UBUNTU RELEASE" to generate proper AppImage which can can on almost any thinkable up-to-date Linux distribution.

RSS Guard is compiled via "github actions" and Github Actions did offer Ubuntu 18.04 build environment (oldest LTS at this point) but that one is DEPRECATED and will be removed soon. Also, this old Ubuntu only offers Qt 5 packages.

https://github.blog/changelog/2022-08-09-github-actions-the-ubuntu-18-04-actions-runner-image-is-being-deprecated-and-will-be-removed-by-12-1-22/

"linuxdeployqt" will support newer Ubuntu 20.04 LTS but only when 18.04 is finally obsolete which will be somewhere on 2023. When that happens, fully working Qt-6 based AppImages will be possible.

So we cannot use Qt 5 (Ubuntu 18.04) as it is obsolete (to be removed anyway), we also have buggy Qt 6 AppImages.

Also, RSS Guard already has native packages for many Linux distributions + fully working Flatpak release.

My proposition is to drop AppImage completely and rely on native Linux packages + Flatpak. Simply because debugging, preparing, fixing AppImage is quite painstaking and time consuming for me.

[martinrotter]

OK, I reverted to Qt 5 and will stay on this as long as possible. Once compiled, pls test all, including sounds from notifications, crashes etc.

ad31cec3

[akinokonomi]

when 18.04 is finally obsolete which will be somewhere on 2023.

@martinrotter For now, the end of standard support is in April 2023: https://wiki.ubuntu.com/Releases.

that one is DEPRECATED and will be removed soon. https://github.blog/changelog/2022-08-09-github-actions-the-ubuntu-18-04-actions-runner-image-is-being-deprecated-and-will-be-removed-by-12-1-22/

So we cannot use Qt 5 (Ubuntu 18.04) as it is obsolete (to be removed anyway),

On the page you linked, they say

*update: we extended the deprecation schedule until April 2023 with updated dates for brownouts.

So it should be okay.

we also have buggy Qt 6 AppImages.

Personally, I have no problem with leaving Qt6 Appimages, declaring this a "known problem", pinning this issue until further notice and calling it a day.

My proposition is to drop AppImage completely and rely on native Linux packages + Flatpak.

Fair enough. That's what I'd have done, too, but people seem to really like them and use them a lot. It helps with testing some fixes quick, too, for people who can't compile themselves.

I truly hope someone will make creating AppImages easier.

---

ad31cec

Both versions (webengine and nowebengine) don't crash on fetch for me, and play sound just fine.

Nowebengine version seems good.

Webengine version does not render article in the article viewer, though.

EDIT: As a counter point, Qt5 version shows Breeze icons just fine, Qt6 not.

794

Oh, I thought I've already seen something like this before...

[martinrotter]

@akinokonomi

Yes, anyway let's stick with Qt 5 and I believe, if it works, there is no need to really change it right?

So even after we move to Ubuntu 20.04 as AppImage building system, we could stick to Qt 5 if it seems to works just fine.

[akinokonomi]

@martinrotter, Sure, except that the Qt5 webengine version does not render the article in article viewer. At all. Article viewer just remains blank. Tested with latest 1339350c , and it's still the same.