I'm having a problem with LifeREA. I've got version 1.0.15 compiled with these use flags: net-news/liferea-1.0.15 USE="dbus -debug -firefox gtkhtml mozilla" 0 kB Once every few hours or so, LifeREA segfaults. This happens when I look at a new RSS item, or when I close the program to the systray, or even when I start it. It seems rather random. I've attached the backtrace and my emerge --info. Let me know if I can help in any further way. ~~ Andrew D.
Created attachment 89871 [details] My emerge --info
Created attachment 89872 [details] gdb backtrace
I have the same problem but use different use flags. [ebuild R ] net-news/liferea-1.0.15 USE="firefox gtkhtml -dbus -debug -mozilla" 0 kB Andrew D's description of the bug matches mine. I will be attaching my backtrace and emerge --info.
Created attachment 90053 [details] Backtrace of liferea crashing liferea backtrace
Created attachment 90054 [details] emergeinfo emerge --info
Created attachment 90064 [details] It's a little more complete
could you reproduce this with liferea-1.0.16 ?
Yes, this happens on 1.0.16 as well.
I am also seeing this bug, in several versions up to and including 1.0.16. I'm also using AMD64 like the other two reporters. net-news/liferea-1.0.16 USE="dbus firefox gtkhtml -debug -seamonkey" Even though I have firefox enabled I am actually using GtkHtml2 to render the articles.
Re-assign, maintainer retired.
I'm the new maintainer, I'll be working on this with upstream. My current belief is that this is releated to gtk+ change (or possibly glib).
I've just added liferea-1.0.18 with a fix to make the gtkhtml browser work under amd64. If you were having problems with old versions, could you try this one? As for the mozilla browser, our firefox seems to be deficient in headers. I'm emerging seamonkey now to see if that is good enough. If so, I'll have to remove the firefox option until we can get a firefox package that work (or I can come up with a patch that works). In the meantime, don't try the mozilla browser on amd64, it will likely crash and burn badly.
I spoke too soon. There's still a crash.
Okay, update. This new crash is caused by trying to display the Slashdot feed. If I remove that, it's working again (so far). I'll dig deeper.
you can also try liferea-1.0.19 (lots of 64bit arch patches). (revbump the ebuild if not yet in portage)
Still segfaults on 1.0.21. I do appreciate you being so on-the-ball about LifeREA ebuilds and such, though. Sure beats the old "revbump every 5-6 versions" routine. :) ~~ Andrew D.
I also still see crashes with 1.0.21, but they are different crashes and they also occur less frequently. It used to be that I got crashes when I selected a new feed to read, but I have not seen this for some time (not sure which exact upgrade fixed this). I still do get crashes when using the popup menu in the feedlist (e.g. to mark a feed as read or update it). Sometimes the menu pops down right after poping up, and a bit of hit and miss here causes the crash. Since this messes with the event queue it is not so much fun to debug (read: no other mouse clicks or keyboard events are processed until the liferea process it gone) and I haven't got a backtrace yet.
Still crashes with net-news/liferea-1.0.22 ... [ebuild R ] net-news/liferea-1.0.22 USE="dbus firefox gtkhtml -debug -seamonkey" 0 kB
ditto [ebuild R ] net-news/liferea-1.0.23 USE="dbus gtkhtml -debug -firefox -seamonkey" 0 kB
I am now completely unable to reproduce any crashes with 1.0.23. Could people post how they're getting crashes?
For me at least, it seems to happen most during a refresh of feeds (click on a feed during the refresh, say goodbye to liferea). I thought it was related to some random dbus messages lifrea puts out, but doesn't seem to be so (ie, the crash isn't consistent).
Okay, you're right, I can get that crash too. The workaround for now is simple, tho: don't do that. :) At any rate, I'll look. It doesn't really seem to be a problem in liferea, as there's no liferea code in the backtrace after main(). Probably, it's some kind of threading bug.
Created attachment 98134 [details] gdb backtrace of menu popup crash I see the problem mentioned in comment 22 as well, but I also see regular crashes that seem related to the menu popup behavior. I usually use this menu to mark a feed as read. I popup the menu using the right mouse button, then I select the mark as read option, and then I select that using the left mouse button. My right mouse button seems a bit flaky so I sometimes have to press it a few times for the menu to remain popped up. In this case, sometimes, I get a crash. Looking at the backtrace that I have uploaded it looks like this may be a bug in gtk, but I don't see these crashes in other applications, despite sometimes having the same issues with the popup menus.
*** Bug 152384 has been marked as a duplicate of this bug. ***
Things are working fine for me now with Liferea 1.2-rc1... anyone else have problems with this recently?
There have been reports of several crashes vanishing in -rc1. There was apparently a general cleanup of some of the menu/mouse handling.
The last few unstable versions (starting with 1.1.8 or so) have been really stable for me. I haven't seen a single crash with these versions on amd64.
i don't know, it's managed to crash on me twice in the last ten minutes. the original bug i had with it crashing while selecting folders/whatever during a feed load is gone - now it's more random, like when i right click on a feed.
** ERROR **: file update.c: line 422 (update_execute_request): assertion failed: (new_request->options != NULL) aborting...
as said in 1.2 release notes, x86_64 is unsupported, so I think we can mark this WONTFIX.
Funny, because 1.2 has been really stable for me on amd64 since before the RC versions. I haven't seen a single crash with it. I agree that the bug can be closed WONTFIX, though, since this crash happens in 1.0.x, and I don't think that can be stabled on amd64.
Liferea is stable with Gecko (Mozilla) engine. This it true for 1.0.x as well as for 1.2.x. So do not use GtkHTML2 engine on amd64. Please see my test results and author comments at http://sourceforge.net/tracker/index.php?func=detail&aid=1497315&group_id=87005&atid=581684 So I think this bug can be "fixed" by masking gtkhtml USE flag for this package (for amd64 only).
Well, gtkhtml is a global use flag, so we cannot mask it. Howerver, as of 1.2.5, you cannot enable gtkthml on amd64 (enforced by upstream), so giving that flag errors out. I'm actually tempted to remove gtkhtml support entirely, but that's another story.
No longer relevant, I believe.
