Bug 199222

Summary: liferea crashes on startup
Product: [Fedora] Fedora Reporter: Bill Nottingham <notting>
Component: lifereaAssignee: Brian Pepple <bdpepple>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: 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
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.

Comment 1 Luke Macken 2006-07-18 14:52:49 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


Comment 2 Bill Nottingham 2006-07-18 18:54:12 UTC
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 09:28:00 UTC
*** Bug 200698 has been marked as a duplicate of this bug. ***

Comment 4 John (J5) Palmieri 2006-07-31 14:19:27 UTC
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()

Comment 5 Michael Schwendt 2006-07-31 18:10:14 UTC
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 18:34:26 UTC
That is a step.  Do you have a backtrace?

Comment 7 Brian Pepple 2006-07-31 19:34:31 UTC
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

Comment 8 Michael Schwendt 2006-07-31 20:59:04 UTC
$ 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++


Comment 9 Brian Pepple 2006-08-01 13:21:33 UTC
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


Comment 10 Michael Schwendt 2006-08-01 15:15:50 UTC
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. ;)


Comment 11 Brian Pepple 2006-08-07 21:11:09 UTC
Looks like version 1.0.20, should fix this.

Comment 12 Brian Pepple 2006-08-09 13:58:57 UTC
This should be fixed w/ 1.0.20.  If you still have problems, please re-open this
bug.