Re: [RFC 8/8] mi/python: Allow redefinition of python MI commands

[Tom Tromey <tom@tromey.com>]

>>>>> "Jan" == Jan Vrany <jan.vrany@fit.cvut.cz> writes:

Jan> Redefining python MI commands is especially useful when developing
Jan> then.

>> It seems like this could lead to difficulties with dangling pointers.
>> Some assurance on this would be good.

Jan> I'm not sure what exactly do you mean. However, I changed mi_command_py to
Jan> use gdbpy_ref<> instead of PyObject* (or even void*). 

Jan> Therefore when one redefines the command:

Jan> +  if (mi_cmd_table.find (name) != mi_cmd_table.end ())
Jan> +    if (! mi_cmd_table[name]->can_be_redefined ())
Jan> +      return false;
Jan> +
Jan> +  mi_cmd_table[name] = std::move (command);

Jan> then the old command (if any) is destructed so Py_DECREF() is called on
Jan> Python objech held on by mi_command_py() instance. 

Jan> I double checked by tracing it in GDB - I don't know how to write
Jan> the test for for this though. 

Jan> Does above address your concern? 

The issue isn't a leak but rather the possibility of using an object
after it's been destroyed.

That is, if an MI command can be running when it is replaced, the code
has to be sure that the command object isn't referenced after the
replacement -- because the old object will have been destroyed.

Tom