<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 06/10/2014 04:19 AM, Matěj Cepl
wrote:<br>
</div>
<blockquote cite="mid:slrnlpdft1.ngg.mcepl@wycliff.ceplovi.cz"
type="cite">
<pre wrap="">I am trying to figure out the Fedora builds in
<a class="moz-txt-link-freetext" href="http://copr.fedoraproject.org/coprs/mcepl/xiphos-3.2.1/">http://copr.fedoraproject.org/coprs/mcepl/xiphos-3.2.1/</a> (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).</pre>
</blockquote>
<font face="FreeSerif">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.</font><br>
<blockquote cite="mid:slrnlpdft1.ngg.mcepl@wycliff.ceplovi.cz"
type="cite">
<pre wrap="">Meanwhile, could I ask anybody to take a look at the crashes we
have in Bugzilla? Are <a class="moz-txt-link-freetext" href="https://bugzilla.redhat.com/801979">https://bugzilla.redhat.com/801979</a>,
<a class="moz-txt-link-freetext" href="https://bugzilla.redhat.com/1085621">https://bugzilla.redhat.com/1085621</a>, and
<a class="moz-txt-link-freetext" href="https://bugzilla.redhat.com/1098005">https://bugzilla.redhat.com/1098005</a> all caused by some of our
packaging issues, or are they genuine crashes?
</pre>
</blockquote>
<font face="FreeSerif">Hm...<br>
<br>
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.<br>
<br>
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.<br>
<br>
#34 0xa845141f in libmodman::module_manager::load_file
(this=this@entry=0x9223ed8, filename="<b><font color="#ff0000">/usr/lib/libproxy/0.4.11/modules/config_kde4.so</font></b>",
symbreq=symbreq@entry=true) at
/usr/src/debug/libmodman-2.0.1/libmodman/module_manager.cpp:278<br>
mod_info = 0xa85100f4 <mm_info_><br>
#35 0xa8451998 in libmodman::module_manager::load_dir<br>
#36 0xa8461392 in libproxy::proxy_factory::proxy_factory
(this=0x9223ec0) at
/usr/src/debug/libproxy-0.4.11/libproxy/proxy.cpp:165<br>
module_dir = 0xa8471670
"/usr/lib/libproxy/0.4.11/modules"<br>
#37 0xa8461f18 in pxProxyFactory_<br>
#39 0xaa5801b5 in g_libproxy_resolver_init<br>
#40 0xb75fd7de in g_type_create_instance<br>
#41 0xb75df796 in g_object_new_internal<br>
#42 0xb75e1859 in g_object_newv<br>
#43 0xb75e1f70 in g_object_new<br>
<br>
1098005: I've stared at this backtrace a while, and it's
troublesome to me. The last (only) source lines being executed
are<br>
xiphos_html_new<br>
gui_create_bible_pane<br>
create_mainwindow<br>
main<br>
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<br>
=> 0xb51780a1 <+33>: movl $0x0,0xbbadbeef<br>
"bad beef" is surely somebody's internal consistency marker, and
it's not Xiphos'.</font><br>
</body>
</html>