Documentation for method gupnp_service_proxy_begin_action()
Returns :
A GUPnPServiceProxyAction handle. This will be freed in call to 
gupnp_service_proxy_cancel_action() or
gupnp_service_proxy_end_action_valist(). [transfer none]


Method gupnp_service_proxy_begin_action() calls
   gupnp_service_proxy_begin_action_valist
and
   begin_action_msg

Method begin_action_msg can synchronously fail on number of reasons.
In this case method gupnp_service_proxy_begin_action_valist calls callback
and returns pointer to action.

       if (ret->error) {
               callback (proxy, ret, user_data);

               return ret;
       }

But it is expected that callback calls gupnp_service_proxy_end_action
and thus frees the action.
The pointer to returned action is invalid.

I found this problem by proof-reading the source code. 
It should happen when upnp server provides wrong description (empty service type / control uri that cannot be parsed).

To solve this issue I propose to call the application callback asynchronously. 
It does not change the documented API.
And application must be prepared for asynchronous invocation anyway.

I will prepare patch if maintainer(s) confirm this issue and agree with the proposed solution.

I am new to glib programming. What is the best way to enqueue the method to the event loop? Is g_timeout_add with 1 millisecond fine?

+static gboolean callback_timeout_cb (gpointer userdata)
+{
+    GUPnPServiceProxyAction *action = (GUPnPServiceProxyAction *) userdata;
+    action->callback (action->proxy, action, action->user_data);
+    return FALSE;
+}

-    callback (proxy, ret, user_data);
+    g_timeout_add (1, callback_timeout_cb, ret);