Comment 5 for bug 741726

So Ted asked me to look at this, in the hopes another set of eyeballs would help.

I'm leery that the linked branch will do much. The type of the properties is already checked in get_properties_callback(). And the g_variant_iter_loop() format_string argument in the stack trace is "v}" which is clearly wrong. Looks like memory got corrupted somewhere upstack rather than unexpected variants in the properties list.

There aren't that many near opportunities for memory corruption. The 'data' argument to the function seems to be correctly ref'd before the callback is setup so it seems to be valid memory for the dbusmenu_menuitem_properties_list() call. That would leave get_properties_callback()...

What about line 604?

601 GVariant * child = g_variant_get_child_value(params, 0);
602 GVariantIter iter;
603 g_variant_iter_init(&iter, child);
604 g_variant_unref(child);
605 while ((child = g_variant_iter_next_value(&iter)) != NULL) {

Seems suspicious to unref the child there, since the docs say the iter is only valid as long as child is.

Additionally, though this wouldn't cause the crash, on line 1381, the "have_error == FALSE" check should be moved up to the surrounding "properties != NULL" check; otherwise you'll leak the first key/value pair if have_error is TRUE.