[sword-devel] Xiphos crashes

[Karl Kleinpaste]

On 06/10/2014 04:19 AM, Matěj Cepl wrote:
> I am trying to figure out the Fedora builds in 
> http://copr.fedoraproject.org/coprs/mcepl/xiphos-3.2.1/ (I do 
> have builds for RHEL-7 and Fedora >= 20, others I have to figure 
> out yet). When I will be done, I will attach patches to the Red 
> Hat Bugzilla bugs and/or build the packages myself (I can do it, 
> although I am not a maintainer of the packages in question).
Greg is lately the regular producer of Fedora builds.  Primarily he's
building for Rawhide; out of a need for folks to get current state when
they're in F20 and even F19 (which is where I am), I've begun building
my own and making them available on Xiphos' SourceForge files.
> Meanwhile, could I ask anybody to take a look at the crashes we 
> have in Bugzilla? Are https://bugzilla.redhat.com/801979, 
> https://bugzilla.redhat.com/1085621, and 
> https://bugzilla.redhat.com/1098005 all caused by some of our 
> packaging issues, or are they genuine crashes?
Hm...

801979: That is from a version old enough that we no longer have or use
gecko at all.  It dates from xulrunner.  We use only WebKit now, and
have for a few years.  No longer relevant.

1085621: A crash on exit.  Not sure what to do about that.  Xiphos has
shutdown the Sword backend, the GUI frontend, and told GTK to quit, and
now just wants to leave.  I'll look into it but I'm mostly confused by
this: There are 60+ frames of nonsense above Xiphos' call to exit, and
perversely that includes the top 35 frames as being ... KDE
initialization.  Does the phrase "um, what?" mean the same thing to
others as it means to me?  Xiphos is a GNOME/GTK/GLib app.  I can't
begin to guess what KDE is doing in the picture.

    #34 0xa845141f in libmodman::module_manager::load_file
(this=this at entry=0x9223ed8,
filename="*/usr/lib/libproxy/0.4.11/modules/config_kde4.so*",
symbreq=symbreq at entry=true) at
/usr/src/debug/libmodman-2.0.1/libmodman/module_manager.cpp:278
            mod_info = 0xa85100f4 <mm_info_>
    #35 0xa8451998 in libmodman::module_manager::load_dir
    #36 0xa8461392 in libproxy::proxy_factory::proxy_factory
(this=0x9223ec0) at /usr/src/debug/libproxy-0.4.11/libproxy/proxy.cpp:165
            module_dir = 0xa8471670 "/usr/lib/libproxy/0.4.11/modules"
    #37 0xa8461f18 in pxProxyFactory_
    #39 0xaa5801b5 in g_libproxy_resolver_init
    #40 0xb75fd7de in g_type_create_instance
    #41 0xb75df796 in g_object_new_internal
    #42 0xb75e1859 in g_object_newv
    #43 0xb75e1f70 in g_object_new

1098005: I've stared at this backtrace a while, and it's troublesome to
me.  The last (only) source lines being executed are
    xiphos_html_new
    gui_create_bible_pane
    create_mainwindow
    main
and this is something I've never seen fail anywhere, ever.  All Xiphos
is doing at this point is obtaining its first HTML widget.  Above this
are 19 frames of GLib and WebKit nightmares.  Considering that this has
never been a problem for Xiphos anywhere else, I'm inclined to point the
finger at WebKit internals.  I think this seems supported by the fact
that the crash is pointed out at the bottom as
    => 0xb51780a1 <+33>:    movl   $0x0,0xbbadbeef
"bad beef" is surely somebody's internal consistency marker, and it's
not Xiphos'.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20140611/1015c98b/attachment-0001.html>