Description of problem: liferea crashes on startup. Version-Release number of selected component (if applicable): # rpm -q dbus dbus-glib liferea dbus-0.62-1.1 dbus-glib-0.62-1.1 liferea-1.0.16-3.fc6 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 (gdb) CC'ing d-bus maintainer.
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.