Bug 199222
Summary: | liferea crashes on startup | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Bill Nottingham <notting> |
Component: | liferea | Assignee: | Brian Pepple <bdpepple> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | extras-qa, johnp, lmacken, rvokal, sangu.fedora |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | 1.0.20 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2006-08-09 13:58:57 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Bill Nottingham
2006-07-18 03:42:22 UTC
I get this same backtrace when running /usr/bin/liferea, but /usr/bin/liferea-bin seems to work fine. It looks like /usr/bin/liferea sets the LD_LIBRARY_PATH, which leads to the segfault somehow. [lmacken@crow ~]$ /usr/bin/liferea-bin A stale lockfile has been found, and was deleted. ** (liferea:4576): WARNING **: Failed to open HTML widget module (/usr/lib/liferea/liblihtmlm.so) specified in configuration! libgtkembedmoz.so: cannot open shared object file: No such file or directory trying to load browser module GtkHTML2 (liblihtmlg.so) ERROR: No output during decompression (Liferea then loads fine.. happiness ensues) [lmacken@crow ~]$ export LD_LIBRARY_PATH=/usr/lib/mozilla-1.7.13: [lmacken@crow ~]$ /usr/bin/liferea-bin Segmentation fault So, it crashes in the d-bus code, but only if it uses mozilla for rendering? Neat trick. *** Bug 200698 has been marked as a duplicate of this bug. *** Because it is using threads if it is using mozilla and threading must be initlized: g_thread_init() gdk_threads_init() dbus_g_thread_init() Liferea upstream ought to have interest in examining this. With an added early call of dbus_g_thread_init and rebuilding against firefox-devel, liferea crashes in the Mozilla rendering plugin instead of dbus. That is a step. Do you have a backtrace? This supposedly has been fixed 1.0.19, but I haven't had a chance to look to see if it actually works yet. https://sourceforge.net/tracker/?func=detail&atid=581684&aid=1523428&group_id=87005 $ rpm -q liferea liferea-1.0.19-1 $ MOZILLA_FIVE_HOME=/usr/lib/firefox-1.5.0.5 liferea Segmentation fault (core dumped) Program terminated with signal 11, Segmentation fault. #0 mozsupport_preference_set_boolean ( preference_name=0x997ec0 "javascript.enabled", new_boolean_value=1) at mozsupport.cpp:222 222 prefService->GetBranch ("", getter_AddRefs(pref)); (gdb) bt #0 mozsupport_preference_set_boolean ( preference_name=0x997ec0 "javascript.enabled", new_boolean_value=1) at mozsupport.cpp:222 #1 0x00996beb in mozembed_init () at mozembed.c:276 #2 0x00997db1 in mozilla_init () at mozilla.c:46 #3 0x0808d26d in ui_htmlview_init () at ui_htmlview.c:196 #4 0x0807e1a4 in main (argc=0, argv=0xbf9a3164) at main.c:275 Current language: auto; currently c++ Looks like this bug has been around for a while. Here's a link to it: https://sourceforge.net/tracker/index.php?func=detail&aid=1455278&group_id=87005&atid=581684 I've added comments to that bug. There is a work-around included in there. Calling gtk_moz_embed_set_comp_path("/usr/lib/firefox-1.5.0.5") makes the plugin work so far. Instead of hardcoding it, it would be easy to make it evaluate an environment variable passed in from the liferea shell script. Another problem is in the /usr/bin/liferea wrapper, which messes up looking for the Firefox home. Basically, it has got the home directory right, but strips off two directories and then ends in /usr where it doesn't find the libraries. ;) Looks like version 1.0.20, should fix this. This should be fixed w/ 1.0.20. If you still have problems, please re-open this bug. |