view libpurple/purple-uninstalled.pc.in @ 31518:b39b6d0008c5

upnp: Asynch-ronize the callbacks from UPnP to calling code. Refs #12387 I have no idea if this will resolve the crashes, but with the help of the packet capture, I /think/ these are correct. Short summary: it's possible for the callback to fire (and ar be freed) before the top-level function (purple_upnp_cancel_port_mapping) returns, even though cancel_port_mapping returns the now-invalid ar (which may lead to a subsequent use-after-free). At least one call path through the code that I think leads to this (backed up by one of the debug logs I looked at): purple_upnp_cancel_port_mapping(...) do_port_mapping_cb (has_control_mapping == TRUE, ar->add == FALSE) purple_upnp_generate_action_message_and_send(..., done_port_mapping_cb, ar) /* We fail to parse the URL (see some debug logs) */ done_port_mapping_cb ar->cb(FALSE, cbdata) return; return; return; return ar; ...and something which calls: do_port_mapping_cb(has_control_mapping == TRUE, ar->add == TRUE) ar->cb(FALSE, cbdata) g_free(ar) return;

prefix=@prefix@
exec_prefix=@exec_prefix@
libdir=@libdir@
includedir=@includedir@
datarootdir=@datarootdir@
datadir=@datadir@
sysconfdir=@sysconfdir@

abs_srcdir=@abs_srcdir@
abs_builddir=@abs_builddir@

plugindir=${libdir}/purple-@PURPLE_MAJOR_VERSION@

Name: libpurple
Description: libpurple is a GLib-based instant messenger library.
Version: @VERSION@
Requires: glib-2.0
Cflags: -I${abs_srcdir} -I${abs_builddir}
Libs: ${abs_builddir}/libpurple.la