Bug 791787 – rare failure in gdbus-peer test: invalid uninstantiatable type '(null)' in cast to 'GDBusServer'

After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.

Bug 791787 - rare failure in gdbus-peer test: invalid uninstantiatable type '(null)' in cast to 'GDBusServer'


Summary:	rare failure in gdbus-peer test: invalid uninstantiatable type '(null)' in ca...


Status:	RESOLVED OBSOLETE

Product:	glib
Classification:	Platform
Component:	gdbus
Version:	unspecified
Hardware:	Other Linux

Importance:	Normal normal
Target Milestone:	---
Assigned To:	gtkdev
QA Contact:	gtkdev

URL:
Whiteboard:

Depends on:
Blocks:

Reported:	2017-12-19 14:45 UTC by Simon McVittie
Modified:	2018-05-24 20:06 UTC

See Also:
GNOME target:	---
GNOME version:	---

Description Simon McVittie 2017-12-19 14:45:41 UTC

+ Trace 238273

Thread 1 (Thread 0x7fe93db8b700 (LWP 15920))

#0 _g_log_abort
at /home/smcv/src/glib/glib/gmessages.c line 583
#1 g_logv
at /home/smcv/src/glib/glib/gmessages.c line 1391
#2 g_log
at /home/smcv/src/glib/glib/gmessages.c line 1432
#3 g_type_check_instance_cast
at /home/smcv/src/glib/gobject/gtype.c line 4069
#4 on_run
at /home/smcv/src/glib/gio/gdbusserver.c line 950
#5 ffi_call_unix64
from /usr/lib/x86_64-linux-gnu/libffi.so.6
#6 ffi_call
from /usr/lib/x86_64-linux-gnu/libffi.so.6
#7 g_cclosure_marshal_generic_va
at /home/smcv/src/glib/gobject/gclosure.c line 1604
#8 _g_closure_invoke_va
at /home/smcv/src/glib/gobject/gclosure.c line 867
#9 g_signal_emit_valist
at /home/smcv/src/glib/gobject/gsignal.c line 3300
#10 g_signal_emit
at /home/smcv/src/glib/gobject/gsignal.c line 3447
#11 g_threaded_socket_service_func
at /home/smcv/src/glib/gio/gthreadedsocketservice.c line 87
#12 g_thread_pool_thread_proxy
at /home/smcv/src/glib/glib/gthreadpool.c line 307
#13 g_thread_proxy
at /home/smcv/src/glib/glib/gthread.c line 784
#14 start_thread
at pthread_create.c line 456
#15 clone
at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 97

Comment 1 Simon McVittie 2017-12-19 14:46:48 UTC

To reproduce, run the gdbus-peer test in a loop (this is rare, it took me 1583 attempts).

Possibly related to Bug #701105.

Complete backtrace (all threads):

(gdb) thread apply all bt

+ Trace 238274

Thread 1 (Thread 0x7fe93db8b700 (LWP 15920))

#0 _g_log_abort
at /home/smcv/src/glib/glib/gmessages.c line 583
#1 g_logv
at /home/smcv/src/glib/glib/gmessages.c line 1391
#2 g_log
at /home/smcv/src/glib/glib/gmessages.c line 1432
#3 g_type_check_instance_cast
at /home/smcv/src/glib/gobject/gtype.c line 4069
#4 on_run
at /home/smcv/src/glib/gio/gdbusserver.c line 950
#5 ffi_call_unix64
from /usr/lib/x86_64-linux-gnu/libffi.so.6
#6 ffi_call
from /usr/lib/x86_64-linux-gnu/libffi.so.6
#7 g_cclosure_marshal_generic_va
at /home/smcv/src/glib/gobject/gclosure.c line 1604
#8 _g_closure_invoke_va
at /home/smcv/src/glib/gobject/gclosure.c line 867
#9 g_signal_emit_valist
at /home/smcv/src/glib/gobject/gsignal.c line 3300
#10 g_signal_emit
at /home/smcv/src/glib/gobject/gsignal.c line 3447
#11 g_threaded_socket_service_func
at /home/smcv/src/glib/gio/gthreadedsocketservice.c line 87
#12 g_thread_pool_thread_proxy
at /home/smcv/src/glib/glib/gthreadpool.c line 307
#13 g_thread_proxy
at /home/smcv/src/glib/glib/gthread.c line 784
#14 start_thread
at pthread_create.c line 456
#15 clone
at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 97

Comment 2 Philip Withnall 2017-12-21 10:36:33 UTC

I suspect this is because on_run() can be run in any thread.

1. GDBusServer.on_run() gets called in a new worker thread
2. GDBusServer.finalize() gets called in another thread (the worker thread doesn’t have a reference to the GDBusServer)
3. GDBusServer.finalize() completes and disconnects on_run() (but that’s too late)
4. GDBusServer.on_run() resumes and finds that its @server is garbage

The fix is probably going to end up being a global hash table of GDBusServer instances, since we can’t allocate any per-GDBusServer locks or weak refs, since there’d be no safe place to free them afterwards.

Comment 3 Simon McVittie 2017-12-21 11:42:33 UTC

(In reply to Philip Withnall from comment #2)
> The fix is probably going to end up being a global hash table of GDBusServer
> instances, since we can’t allocate any per-GDBusServer locks or weak refs,
> since there’d be no safe place to free them afterwards.

I would hope we can do better than that, but I'm not sure how.

Maybe on_run could have a GWeakRef<GDBusServer> as its user-data and convert it to a strong ref for the duration? GWeakRef is meant to be thread-safe.

Comment 4 Philip Withnall 2017-12-21 11:51:24 UTC

(In reply to Simon McVittie from comment #3)
> (In reply to Philip Withnall from comment #2)
> > The fix is probably going to end up being a global hash table of GDBusServer
> > instances, since we can’t allocate any per-GDBusServer locks or weak refs,
> > since there’d be no safe place to free them afterwards.
> 
> I would hope we can do better than that, but I'm not sure how.
> 
> Maybe on_run could have a GWeakRef<GDBusServer> as its user-data and convert
> it to a strong ref for the duration? GWeakRef is meant to be thread-safe.

I already played around with that earlier this morning and couldn’t work out how to safely free the GWeakRef afterwards — you end up freeing it after it first returns NULL, but that’s not safe if there are multiple on_run() calls in flight in different worker threads.

Comment 5 GNOME Infrastructure Team 2018-05-24 20:06:11 UTC

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/1318.