Exporting an Interface

[Florence Chan]

Hey Aleksander,

Is that "self" in the g_object_get() the same as in the
> g_dbus_interface_skeleton_export()?
>

Yes, self refers to a a MMIfaceSimEap *. I have a MMGdbusSimEap* created by
the command mm_gdbus_sim_eap_skeleton_new (). However is that not different
from the GDBusInterfaceSkeleton* that is required? What do you mean that
the self cannot be the same/why can't it?

What do you mean here overridden accordingly in the base sim class?

 The skeleton corresponding to my interface is overridden in the base sim
class. I used the modem interfaces as reference:
 g_object_class_override_property (object_class,
                                   PROP_SIM_EAP_DBUS_SKELETON,
                                   MM_IFACE_SIM_EAP_DBUS_SKELETON);
It also has corresponding implementation in the set_property and
get_property method

Did g_dbus_interface_skeleton_export() return FALSE? or did it return
> TRUE? is error really != NULL with error->message == NULL?
>

Yes, g_dbus_interface_skeleton_export() returned FALSE, hence the
respective debug statements being printed. I added more debug statements
and yes, error != NULL however error->message == NULL.

Also, do you have a git commit published anywhere with those changes?


You can see my most recent changes here:
https://chromium-review.googlesource.com/c/chromiumos/third_party/modemmanager-next/+/3276345
. Hopefully it helps.

In the meantime I will look for other ways to obtain a GDBusInterfaceSkeleton*
and see if valgrind shows me something useful.

Thanks Aleksander!
- Florence


On Thu, Nov 11, 2021 at 2:47 AM Aleksander Morgado <aleksander at aleksander.es>
wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/modemmanager-devel/attachments/20211111/fb1837e1/attachment-0001.htm>