Fixed in a branch, along with some more checks. (In reply to comment #0) > ** ERROR **: Out of memory > aborting... > Aborted This is another manifestation of Bug #30171, incidentally. Created attachment 45003 [details] [review] [PATCH 1/5] dbus_g_proxy_new_from_proxy: check that the old proxy is in fact a proxy Created attachment 45004 [details] [review] [PATCH 2/5] Document that most DBusGProxy methods stop working on ::destroy Created attachment 45005 [details] [review] [PATCH 3/5] dbus_g_proxy_set_interface: check that it's a proxy and not destroyed If it has emitted destroy, our use of priv->manager will be a NULL pointer dereference. Created attachment 45006 [details] [review] [PATCH 4/5] dbus_g_proxy_end_call: check that it's a proxy Created attachment 45007 [details] [review] [PATCH 5/5] DBusGProxy: link against GIO and use GDBus to check names' syntax (In reply to comment #0) > Alternatively, if it is to be handled with an assertion, there should be an > associated > function that a programmer can use to sanity check the path. I used GDBus (GIO) for this; life's too short to implement these functions yet again. 11:39 < wjt> smcv: top marks for proposing that dbus-glib use methods from gdbus Created attachment 45010 [details] [review] [PATCH 5/5 v2] DBusGProxy: link against GIO and use GDBus to check names' syntax Oops, one of the NULL returns on a programming error should have been FALSE. Review of attachment 45003 [details] [review]: looks good. Review of attachment 45004 [details] [review]: I'm assuming that you grepped for g_return_if_fail (!DBUS_G_PROXY_DESTROYED (proxy)); to decide where to sprinkle these notes? Looks good in any case. Review of attachment 45005 [details] [review]: Looks fine. Review of attachment 45006 [details] [review]: Looks good. Review of attachment 45010 [details] [review]: Looks fine. All applied to master for 0.94, thanks! Bug #36216 has a similar documentation patch, adjusted to apply after this one. Bug #7909, Bug #35767 should now be mergeable. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
I just saw the following: process 4716: arguments to dbus_message_new_method_call() were incorrect, assertion "_dbus_check_is_valid_path (path)" failed in file dbus-message.c line 1078. This is normally a bug in some application using the D-Bus library. ** ERROR **: Out of memory aborting... Aborted The problem is in the following code: dbus = dbus_g_bus_get (DBUS_BUS_SYSTEM, &e); ofono = dbus_g_proxy_new_for_name (dbus, "org.ofono", priv->device, intf); The problem is that the server expects a string that's a dbus path, but the string was incorrect. Ie, priv->device should've been "/G1", but instead an old value was there ("dev:/dev/smd0"). This string was then passed to dbus_g_proxy_new_for_name as the path. It's not unreasonable to assume that the object path may come from something that's not hardcoded (a config file, or from a user). This type of error (invalid path) should really be an error, not an assertion; it could easily be handled w/ an error message. Alternatively, if it is to be handled with an assertion, there should be an associated function that a programmer can use to sanity check the path. Ie: if (!dbus_g_proxy_path_is_sane (priv->device)) { g_set_error (error, "%s is an invalid path!", priv->device); return FALSE; } ofono = dbus_g_proxy_new_for_name (dbus, "org.ofono", priv->device, intf);