[xiphos-devel] totally lost -- how did i get to where i am?

[Karl Kleinpaste]

I was working on a change to the prefs dialog today. I had previously
merged 2 PRs without incident, and then made changes to a few files,
including ui/prefs.* and several src/gnome2/*.c. Built, ran...and the
prefs dialog won't open.

mod.mgr and adv.search open fine.

I backed out changes, rebuilt, no difference. I backed out my git tree
several ways, including "git reset --hard HEAD~~" to get to the point
before the merges. Rebuilt, no difference. Did a bunch of other things,
trying to understand how and where I lost the ability to open prefs.
This makes no sense to me because I built yesterday and have been toying
with biblesync, via prefs of course. I did git reset to a point before
the double arrows were fixed a week ago, rebuilt, no difference. Prefs
will not open. Completely reboot the whole machine, rebuilt from a
totally clean tree, no difference.

The worst/best part is that Xiphos *thinks* it opened prefs. After
quitting Xiphos, settings.xml shows <prefsopen>1</prefsopen>. When I ask
for prefs to open, and noting that I use MATE desktop, the taskbar stops
showing the Xiphos window itself as having focus...but nothing else
does, either. No new window has come into existence, but the Xiphos
window has lost focus.

Approaching desperation, I breakpointed create_preferences_dialog() in
gdb, and what I get is at the bottom.

Big question: What in the world are org.gtk.vfs.UDisks2VolumeMonitor and
g_unix_volume_monitor_init(), and why are they involved in creation of a
prefs dialog, and why are they failing when (if they were involved
yesterday) they didn't fail until today?

You can't tell from the simple copy/paste below, but after hitting the
last 'n', Xiphos simply...went away. For perhaps a minute. And then the
"Error calling ..." message, at which point I hit ^C and backtraced.

Seriously, what has happened here? I have literally zero understanding
of what sort of "volume monitoring" has tried to take place or why it
has begun just now, or why (if it has been going on before) it failed to
be started today. Googling the "Error calling Start..." has been
uninformative, search results being anywhere from 2 to 5 years in the
past, and related to things like gvfs, yet my environment has had no
changes lately so that the state of things like gvfs would change.

Life theme of mine: I love puzzles, I hate mysteries. This is total mystery.

I am in serious need of a huge clue. Anyone?

--karl

(gdb) n
2915        gxml = gtk_builder_new();
(gdb)
2916        gtk_builder_add_from_file(gxml, glade_file, NULL);
(gdb) l
2911        g_return_if_fail(glade_file != NULL);
2912   
2913    /* build the widget */
2914    #ifdef USE_GTKBUILDER
2915        gxml = gtk_builder_new();
2916        gtk_builder_add_from_file(gxml, glade_file, NULL);
2917    #else
2918        gxml = glade_xml_new(glade_file, NULL, NULL);
2919    #endif
2920        g_free(glade_file);
(gdb) n
Error creating proxy: Error calling StartServiceByName for
org.gtk.vfs.UDisks2VolumeMonitor: Timeout was reached (g-io-error-quark, 24)
^C
Thread 1 "xiphos" received signal SIGINT, Interrupt.
0x00007fffecfedb99 in syscall () from /lib64/libc.so.6
(gdb) bt
#0  0x00007fffecfedb99 in syscall () at /lib64/libc.so.6
#1  0x00007ffff748350f in g_cond_wait () at /lib64/libglib-2.0.so.0
#2  0x00007ffff1962d03 in g_context_specific_group_request_state () at
/lib64/libgio-2.0.so.0
#3  0x00007ffff1962db4 in g_context_specific_group_get () at
/lib64/libgio-2.0.so.0
#4  0x00007ffff1a1e579 in g_unix_volume_monitor_init () at
/lib64/libgio-2.0.so.0
#5  0x00007ffff773af2d in g_type_create_instance () at
/lib64/libgobject-2.0.so.0
#6  0x00007ffff771bdb8 in g_object_new_internal () at
/lib64/libgobject-2.0.so.0
#7  0x00007ffff771d555 in g_object_new_with_properties () at
/lib64/libgobject-2.0.so.0
#8  0x00007ffff771dfd1 in g_object_new () at /lib64/libgobject-2.0.so.0
#9  0x00007ffff19bce5c in g_volume_monitor_get () at /lib64/libgio-2.0.so.0
#10 0x00007ffff32f5585 in gtk_places_sidebar_init () at /lib64/libgtk-3.so.0
#11 0x00007ffff773af2d in g_type_create_instance () at
/lib64/libgobject-2.0.so.0
#12 0x00007ffff771bdb8 in g_object_new_internal () at
/lib64/libgobject-2.0.so.0
#13 0x00007ffff771d82d in g_object_newv () at /lib64/libgobject-2.0.so.0
#14 0x00007ffff319de0c in _gtk_builder_construct () at /lib64/libgtk-3.so.0
#15 0x00007ffff31a08ba in start_element () at /lib64/libgtk-3.so.0
#16 0x00007ffff7441194 in emit_start_element () at /lib64/libglib-2.0.so.0
[ and onward through 80 frames ]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/xiphos-devel/attachments/20180415/184dcd9d/attachment.html>