<div dir="ltr">Hey Aleksander,<div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Is that "self" in the g_object_get() the same as in the<br>g_dbus_interface_skeleton_export()?<br clear="all"></blockquote><div><br></div><div>Yes, <font face="monospace">self</font> refers to a a <font face="monospace">MMIfaceSimEap *</font>. <font face="arial, sans-serif">I have a </font><font face="monospace">MMGdbusSimEap*</font><font face="arial, sans-serif"> created by the command </font><font face="monospace">mm_gdbus_sim_eap_skeleton_new ()</font>. However is that not different from the <font face="monospace">GDBusInterfaceSkeleton*</font> that is required? What do you mean that the <font face="monospace">self</font> cannot be the same/why can't it?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">What do you mean here overridden accordingly in the base sim class?</blockquote><div> The skeleton corresponding to my interface is overridden in the base sim class. I used the modem interfaces as reference:<br><font face="monospace"> g_object_class_override_property (object_class,<br>                                   PROP_SIM_EAP_DBUS_SKELETON,<br>                                   MM_IFACE_SIM_EAP_DBUS_SKELETON);</font><br></div><div>It also has corresponding implementation in the <font face="monospace">set_property</font> and <font face="monospace">get_property</font> method</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Did g_dbus_interface_skeleton_export() return FALSE? or did it return<br>TRUE? is error really != NULL with error->message == NULL? <br></blockquote><div><br></div><div>Yes, <font face="monospace">g_dbus_interface_skeleton_export() </font>returned FALSE, hence the respective debug statements being printed. I added more debug statements and yes, <font face="monospace">error != NULL</font> however <font face="monospace">error->message</font> == NULL. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Also, do you have a git commit published anywhere with those changes?</blockquote><div><br></div><div>You can see my most recent changes here: <a href="https://chromium-review.googlesource.com/c/chromiumos/third_party/modemmanager-next/+/3276345">https://chromium-review.googlesource.com/c/chromiumos/third_party/modemmanager-next/+/3276345</a> . Hopefully it helps. </div><div><br></div><div>In the meantime I will look for other ways to obtain a <span style="font-family:monospace">GDBusInterfaceSkeleton* </span><font face="arial, sans-serif">and see if valgrind shows me something useful.</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Thanks Aleksander!</font></div><div><div dir="ltr" data-smartmail="gmail_signature"><div dir="ltr">- Florence</div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 11, 2021 at 2:47 AM Aleksander Morgado <<a href="mailto:aleksander@aleksander.es" target="_blank">aleksander@aleksander.es</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hey Florence,<br>
<br>
> 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:<br>
> g_dbus_interface_skeleton_export (G_DBUS_INTERFACE_SKELETON (self),<br>
>                                   connection,<br>
>                                   path,<br>
>                                   &error)<br>
> self is a pointer to my interface The connection and path are properties are the base sim's connection and path, retrieved like this:<br>
>   g_object_get (MM_BASE_SIM(self),<br>
>                 MM_BASE_SIM_CONNECTION, &connection,<br>
>                 MM_BASE_SIM_PATH,       &path,<br>
>                 NULL);<br>
<br>
Is that "self" in the g_object_get() the same as in the<br>
g_dbus_interface_skeleton_export()? If so, that may be the issue here.<br>
The MMBaseSim object inherits from a MmGdbusSimSkeleton, so we can say<br>
the base SIM object implements the<br>
org.freedesktop.ModemManager1.Sim.xml interface. Once the skeleton<br>
object gets both PATH and CONNECTION defined, the object and interface<br>
are exposed in DBus.<br>
<br>
For your new interface, we need a new skeleton object for the new<br>
interface, so it's a completely different object, it cannot be the<br>
same "self" object. Just looking at your explanation is probably not<br>
enough to understand what the issue could be, though.<br>
<br>
> 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)<br>
><br>
<br>
What do you mean here overridden accordingly in the base sim class?<br>
<br>
> 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?<br>
><br>
<br>
Did g_dbus_interface_skeleton_export() return FALSE? or did it return<br>
TRUE? is error really != NULL with error->message == NULL? That is<br>
extremely weird. The best, easiest way to catch where this error comes<br>
from, is probably to run your changes under valgrind's memcheck tool.<br>
That will give us hints of where the problem could be:<br>
<br>
$ sudo G_DEBUG=always-malloc valgrind --leak-check=full<br>
--log-file=valgrind.out /usr/sbin/ModemManager --debug<br>
<br>
The command above will dump the valgrind log to a separate file. You<br>
could also remove --log-file so that the valgrind logs reporting<br>
invalid memory accesses are mixed with the MM debug logs, which<br>
sometimes helps to detect where exactly the issue happens. The<br>
--leak-check option is really not needed to look for invalid memory<br>
accesses, but it's not a bad idea to have it around always to make<br>
sure no directly lost leaks are found.<br>
<br>
Also, do you have a git commit published anywhere with those changes?<br>
It could be easier check by looking at the code.<br>
<br>
Cheers!<br>
<br>
-- <br>
Aleksander<br>
<a href="https://aleksander.es" rel="noreferrer" target="_blank">https://aleksander.es</a><br>
</blockquote></div>