[all-commits] [llvm/llvm-project] 970cb5: [mlir] fix crash in PybindAdaptors.h

ftynse via All-commits all-commits at lists.llvm.org
Mon Jan 17 01:28:16 PST 2022


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 970cb57ef72c9045250e0492cb00127b49ddfea8
      https://github.com/llvm/llvm-project/commit/970cb57ef72c9045250e0492cb00127b49ddfea8
  Author: Alex Zinenko <zinenko at google.com>
  Date:   2022-01-17 (Mon, 17 Jan 2022)

  Changed paths:
    M mlir/include/mlir/Bindings/Python/PybindAdaptors.h

  Log Message:
  -----------
  [mlir] fix crash in PybindAdaptors.h

The constructor function was being defined without indicating its "__init__"
name, which made it interpret it as a regular fuction rather than a
constructor. When overload resolution failed, Pybind would attempt to print the
arguments actually passed to the function, including "self", which is not
initialized since the constructor couldn't be called. This would result in
"__repr__" being called with "self" referencing an uninitialized MLIR C API
object, which in turn would cause undefined behavior when attempting to print
in C++.

Fix this by specifying the correct name.

This in turn uncovers the fact the the mechanism used by PybindAdaptors.h to
bind constructors directly as "__init__" functions taking "self" is deprecated
by Pybind. The modern method requires using "py::init", which seems to rely on
the C++ equivalent of the bound class to be available, which is not the case in
PybindAdaptors.h. A deeper inspection shows that the deprecation concerns
old-style pybind11 constructors that had to allocate the object using
placement new with "self" as memory. The PybindAdaptors.h only provides
extension classes and never allocates (the object construction is delegated to
the base class), so it does not use the deprecated functionality. Use the
implementation detail tag class to convince pybind11 that we are using the
modern constructor binding method and suppress the warning.

On top of that, the definition of the function was incorrectly indicated as the
method on the "None" object instead of being the method of its parent class.
This would result in a second problem when Pybind would attempt to print
warnings pointing to the parent class since the "None" does not have a
"__name__" field or its C API equivalent.

Fix this by specifying the correct parent class by looking it up by name in the
parent module.

Reviewed By: stellaraccident

Differential Revision: https://reviews.llvm.org/D117325




More information about the All-commits mailing list