Bug 199222 - liferea crashes on startup
liferea crashes on startup
Product: Fedora
Classification: Fedora
Component: liferea (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Brian Pepple
Fedora Extras Quality Assurance
: 200698 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2006-07-17 23:42 EDT by Bill Nottingham
Modified: 2014-03-16 23:00 EDT (History)
5 users (show)

See Also:
Fixed In Version: 1.0.20
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-08-09 09:58:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Bill Nottingham 2006-07-17 23:42:22 EDT
Description of problem:

liferea crashes on startup.

Version-Release number of selected component (if applicable):

# rpm -q dbus dbus-glib liferea

How reproducible:

Every time

Steps to Reproduce:
1. Start liferea
2. Boom goes the dynamite!
3. There is no step 3.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208269120 (LWP 3186)]
0x00fd6bc4 in pthread_mutex_lock () from /lib/libpthread.so.0
(gdb) bt
#0  0x00fd6bc4 in pthread_mutex_lock () from /lib/libpthread.so.0
#1  0x003df72d in dbus_gmutex_lock (mutex=0xabcdef) at dbus-gthread.c:95
#2  0x00d0a3f8 in _dbus_mutex_lock (mutex=0x1) at dbus-threads.c:92
#3  0x00ce7533 in dbus_connection_get_dispatch_status (connection=0x8d071b0)
    at dbus-connection.c:3442
#4  0x003d2ae9 in message_queue_prepare (source=0x8d23af8, timeout=0xbfd89888)
    at dbus-gmain.c:94
#5  0x00be67c2 in g_main_context_prepare () from /lib/libglib-2.0.so.0
#6  0x00be6f95 in g_main_context_check () from /lib/libglib-2.0.so.0
#7  0x00be7679 in g_main_loop_run () from /lib/libglib-2.0.so.0
#8  0x005a0074 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#9  0x0807f067 in main (argc=Cannot access memory at address 0x0
) at main.c:285

CC'ing d-bus maintainer.
Comment 1 Luke Macken 2006-07-18 10:52:49 EDT
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
Comment 2 Bill Nottingham 2006-07-18 14:54:12 EDT
So, it crashes in the d-bus code, but only if it uses mozilla for rendering?

Neat trick.
Comment 3 Michael Schwendt 2006-07-31 05:28:00 EDT
*** Bug 200698 has been marked as a duplicate of this bug. ***
Comment 4 John (J5) Palmieri 2006-07-31 10:19:27 EDT
Because it is using threads if it is using mozilla and threading must be initlized:

Comment 5 Michael Schwendt 2006-07-31 14:10:14 EDT
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.
Comment 6 John (J5) Palmieri 2006-07-31 14:34:26 EDT
That is a step.  Do you have a backtrace?
Comment 7 Brian Pepple 2006-07-31 15:34:31 EDT
This supposedly has been fixed 1.0.19, but I haven't had a chance to look to see
if it actually works yet.

Comment 8 Michael Schwendt 2006-07-31 16:59:04 EDT
$ rpm -q liferea
$ MOZILLA_FIVE_HOME=/usr/lib/firefox- 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++
Comment 9 Brian Pepple 2006-08-01 09:21:33 EDT
Looks like this bug has been around for a while.  Here's a link to it:
Comment 10 Michael Schwendt 2006-08-01 11:15:50 EDT
I've added comments to that bug.

There is a work-around included in there. Calling
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. ;)
Comment 11 Brian Pepple 2006-08-07 17:11:09 EDT
Looks like version 1.0.20, should fix this.
Comment 12 Brian Pepple 2006-08-09 09:58:57 EDT
This should be fixed w/ 1.0.20.  If you still have problems, please re-open this

Note You need to log in before you can comment on or make changes to this bug.