Exporting an Interface
aleksander at aleksander.es
Thu Nov 11 10:47:35 UTC 2021
> Previously you mentioned the g_dbus_interface_skeleton_export() method to export my SIM interface, which I've been attempting to use. However I've been running with some issues with it. Currently I call this in my mm_iface_sim_eap_initialize method, like so:
> g_dbus_interface_skeleton_export (G_DBUS_INTERFACE_SKELETON (self),
> self is a pointer to my interface The connection and path are properties are the base sim's connection and path, retrieved like this:
> g_object_get (MM_BASE_SIM(self),
> MM_BASE_SIM_CONNECTION, &connection,
> MM_BASE_SIM_PATH, &path,
Is that "self" in the g_object_get() the same as in the
g_dbus_interface_skeleton_export()? If so, that may be the issue here.
The MMBaseSim object inherits from a MmGdbusSimSkeleton, so we can say
the base SIM object implements the
org.freedesktop.ModemManager1.Sim.xml interface. Once the skeleton
object gets both PATH and CONNECTION defined, the object and interface
are exposed in DBus.
For your new interface, we need a new skeleton object for the new
interface, so it's a completely different object, it cannot be the
same "self" object. Just looking at your explanation is probably not
enough to understand what the issue could be, though.
> From the debug statements the connection is non-null, the path matches with the base sim's path, and a skeleton for my interface was created successfully (and overridden accordingly in the base sim class)
What do you mean here overridden accordingly in the base sim class?
> However looking at my debug statements my interface fails to be exported, and error->message and error->code were (NULL) and 0 respectively, so I am unsure of what the issue is here. Do you know how to fix this?
Did g_dbus_interface_skeleton_export() return FALSE? or did it return
TRUE? is error really != NULL with error->message == NULL? That is
extremely weird. The best, easiest way to catch where this error comes
from, is probably to run your changes under valgrind's memcheck tool.
That will give us hints of where the problem could be:
$ sudo G_DEBUG=always-malloc valgrind --leak-check=full
--log-file=valgrind.out /usr/sbin/ModemManager --debug
The command above will dump the valgrind log to a separate file. You
could also remove --log-file so that the valgrind logs reporting
invalid memory accesses are mixed with the MM debug logs, which
sometimes helps to detect where exactly the issue happens. The
--leak-check option is really not needed to look for invalid memory
accesses, but it's not a bad idea to have it around always to make
sure no directly lost leaks are found.
Also, do you have a git commit published anywhere with those changes?
It could be easier check by looking at the code.
More information about the ModemManager-devel