This no longer occurs...possibly some other commit in dconf fixed it, or maybe it was a gdbus bug?  Who knows, anyways closing.

I'm still seeing it in an ostree checkout from today

Can someone get me a qemu image or something that exhibits the problem?  (ideally with gdb inside of it as well...)

One hint: I've seen this the first time booting into a fresh ostree checkout, upon logging in, g-s-d hit this assertion and my session was over. Rebooting and trying again worked fine. So maybe there is some first-time-only thing at work here ?

(In reply to comment #3)
> Can someone get me a qemu image or something that exhibits the problem? 
> (ideally with gdb inside of it as well...)

If you've downloaded the data into /ostree already on the host, you can use:

# ostbuild privhelper-deploy-qemu /ostree/repo trees/gnomeos-3.8-x86_64-devel

Reading the source of that script will show just how simple it is to make a qemu disk.  I boot it then with:

# qemu-kvm -vga vmware -cpu core2duo -M pc-0.15 -kernel /boot/vmlinuz-$(uname -r) -initrd /boot/initramfs-ostree-$(uname -r).img -hda ostree-qemu.img -m 1024M -append 'rd.plymouth=0 root=/dev/sda ostree=current ' -monitor stdio

(In reply to comment #4)
> One hint: I've seen this the first time booting into a fresh ostree checkout,
> upon logging in, g-s-d hit this assertion and my session was over. Rebooting
> and trying again worked fine. So maybe there is some first-time-only thing at
> work here ?

Oh, that does seem likely, because several components IIRC do a gsettings write on first login (unfortunately...)

Figured out the problem, I think.

Due to one of a couple of recent bugs in the unstable releases of dconf-service, we were having the service crash for new users (usually as a result of not being able to write to the non-existent ~/.config/dconf directory and getting confused about that and crashing).

Everyone knows that when services on D-Bus crash, the bus daemon sends back error messages for any outstanding method calls at the time of the crash.

Some testing shows that those messages get sent in reverse order (ie: violating common assumptions about messages being well-ordered).


I'm not sure this is really covered by D-Bus's well-ordered guarantees since these error messages are being created by the bus daemon itself, but it certainly flies in the face of what you would expect, given a daemon that handles requests serially (ie: all replies will be in the same order as the method calls were).

I guess I'll fix dconf to make it more robust against this case since we have lots of this version of D-Bus 'in the wild' and we need to deal with that, but I think probably we should also fix D-Bus as well...

Reported https://bugs.freedesktop.org/show_bug.cgi?id=59780

Created attachment 234264 [details] [review]
engine: accept out-of-order error reply messages

Due to a quirk of the implementation of the D-Bus daemon (see upstream
bug https://bugs.freedesktop.org/show_bug.cgi?id=59780 for details)
error messages can arrive out of sequence with repsect to the order of
the method calls that they are in reply to.

This may or may not be a violation of the strict-ordering principle of
D-Bus (which does not actually appear to be written into the spec) but
either way, we should dial down our assumptions about ordering since the
D-Bus implementation that everyone is using does not currently work this
way.

Review of attachment 234264 [details] [review]:

::: engine/dconf-engine.c
@@ +906,3 @@
+      g_assert (error != NULL);
+
+      found = g_queue_remove (oc->change);

This is missing a parameter?

Created attachment 234267 [details] [review]
engine: accept out-of-order error reply messages

lol.  typing 'make' helps.

Review of attachment 234267 [details] [review]:

Makes sense to me.

Attachment 234267 [details] pushed as 0b7fe6e - engine: accept out-of-order error reply messages