Hey Florence, > 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), > connection, > path, > &error) > 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, > NULL);
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. Cheers! -- Aleksander https://aleksander.es