On 8/13/19 10:12 AM, Richard W.M. Jones wrote:
An optional Closure parameter, but otherwise works the same way as Closure. --- generator/generator | 57 ++++++++++++++++++++++++++++++++++++--------- 1 file changed, 46 insertions(+), 11 deletions(-)
@@ -4394,6 +4399,16 @@ let print_python_binding name { args; optargs; ret; may_set_error } = ) args; List.iter ( function + | OClosure { cbname } -> + pr " if (%s_user_data != Py_None) {\n" cbname; + pr " /* Increment refcount since pointer may be saved by libnbd. */\n"; + pr " Py_INCREF (%s_user_data);\n" cbname; + pr " if (!PyCallable_Check (%s_user_data)) {\n" cbname; + pr " PyErr_SetString (PyExc_TypeError,\n"; + pr " \"callback parameter %s is not callable\");\n" cbname; + pr " return NULL;\n";
Leaks %s_user_data, because we fail to do a matching Py_DECREF on failure paths. It would be easier to defer the Py_INCREF to after we verified it is Callable. However, on looking further, I see this is also a pre-existing bug affecting Closure. For that matter, should we be using 'py_ret = NULL; goto out;' similar to StringList, to avoid any other leaks on any other failure paths? (The generated python code still probably has a number of poor handling of failures, which needs a proper audit...)
+ pr " }\n"; + pr " }\n" | OFlags (n, _) -> pr " %s_u32 = %s;\n" n n ) optargs;
@@ -4423,6 +4438,9 @@ let print_python_binding name { args; optargs; ret; may_set_error } = ) args; List.iter ( function + | OClosure { cbname } -> + pr ", %s_user_data ? %s_wrapper : NULL" cbname cbname;
Still looks wrong. %s_user_data is non-NULL; the check here should be %s_user_data != Py_None. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org