<table border="1" cellspacing="0" cellpadding="8">
    <tr>
        <th>Issue</th>
        <td>
            <a href=https://github.com/llvm/llvm-project/issues/69730>69730</a>
        </td>
    </tr>

    <tr>
        <th>Summary</th>
        <td>
            [mlir][python] Tracking of live operations fails.
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            mlir
      </td>
    </tr>

    <tr>
      <th>Assignees</th>
      <td>
      </td>
    </tr>

    <tr>
      <th>Reporter</th>
      <td>
          ingomueller-net
      </td>
    </tr>
</table>

<pre>
    I am running into a problem with the Python bindings of MLIR related to how `PyOperation`s track the underlying `Operation`s.

If I understand things right, when a `PyOperation` is created, the pointer to the underlying `Operation` is tracked in [`PyMlirContext::liveOperations`](https://github.com/llvm/llvm-project/blob/3a4b1d17/mlir/lib/Bindings/Python/IRModule.h#L256) (e.g., [here](https://github.com/llvm/llvm-project/blob/3a4b1d17/mlir/lib/Bindings/Python/IRCore.cpp#L1092)). This is used (potentially among other things) to return the same `PyOperation` for existing `Operation`s, e.g., [here](https://github.com/llvm/llvm-project/blob/3a4b1d17/mlir/lib/Bindings/Python/IRCore.cpp#L1106-L1109).

However, it is possible to obtain a `PyOperation` to an `Operation` that is then destroyed without the Python binding noticing, for example, by running a pass that deletes that `Operation`. At that point, `PyMlirContext::liveOperations` has an entry for an `Operation` that doesn't exist anymore. It is then possible that that memory location is used for a new `Operation` that is created through `PyOperation::createDetached` (for example, through [`PyOperation::clone`](https://github.com/llvm/llvm-project/blob/3a4b1d17/mlir/lib/Bindings/Python/IRCore.cpp#L1419), which is called by the Python-bound method [`_OperationBase.clone`](https://github.com/llvm/llvm-project/blob/3a4b1d17/mlir/lib/Bindings/Python/IRCore.cpp#L2930-L2934)). `PyMlirContext::liveOperations` thus contains the pointer of the previous operation that has been destroyed in the meantime and `PyOperation::createDetached` wants to add that same pointer again for a (supposedly not-yet-existing) "new" `Operation`. Accordingly, the [assertion](https://github.com/llvm/llvm-project/blob/3a4b1d17/mlir/lib/Bindings/Python/IRCore.cpp#L1116-L1117) in `PyOperation::createDetached` fails.

I am unsure what the best way to fix this is. After a day of thinking about the problem, my best guess is to say that such a tracking is, in fact, not possible. My second best guess is to say that it is illegal to hold `PyOperation` to ops that could be modified by some other functions but (1) that seems quite error-prone and (2) I haven't been able to find out how to release the `PyOperation` that is causing the problem in my case. Before I spend more time to think about this topic, let me ask for input from the people that are more familiar with that part of the code: @stellaraccident, @teqdruid, @mikeurbach, @ftynse.
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJzMV0tv3DwS_DWcS8OCxHkf5mDHGOwAMTYIcl9QYkvimiIVPjzRv180qRnHjwTeS_JdZGhMNrurq6op4b3qDOKBre_Y-n4hYuitOyjT2SGi1uhuDIZFbeV0OIEYwEVjlOlAmWBBwOhsrXGAswo9hB7hyxR6a6BWRirTebAtPHw-fQWHWgSUECz09gxsU36Z_j2iE0FZwzalh-BE85hiRCPR6YmOYZvyxaqClfesvM3PUwunvNgHYSSEPh3pVNcHxj_BuUcD4u1ZoDw0DikfWkZHjlaZgI7S-30GtDdlihKUAYKNwj9o5T5ZE_BHYMtbtrzV6gmv-zzblGx9z_iuD2H0tIIfGT92KvSxLho7MH7U-uny52Z09r_YBMaPtbY148elWNWVrLaMHwetHK1T9PvdjDPjx4w848fT1wcro8aiZ3z5ma83jO-B8R0WXUH1svVdjw7_ZEKfrMOiGUdKqCr3nPE94_sCvvXKE6LRo6QURxvQBCW0nkAM1nRgQ09t6XPMPTXIYYjOpD55MeA7_W2tA_yhfHiPQgTBPwWKqtzc0DOh8TO1_2XP-ISOclSBEBqt96rWSADYOgj1PrNJlOYNZ0MvUpBAgpDog7MTyiRaG8M7ugVjg2qU6SiBjKYYRo30Wk9XExAwCu9zeIkaA84vrxIo4DbkfySdJeQ_phrohaeK0AQ3pUx-VZ606A3j25A7D8JMA0ENp-fSn0GkHekx4GDdBNo2KdyVjOkoMHj-JZizg0DonY1d_7oZqZ685h6DaHqUtJvx3Ss8r_tnK3kdQluDf9g_XnB0Ve2TXMlPVdOn0oXWKIkJz9S5qW00EgYMvZVzMf-51nInPBZ_uxS-X5Y39Fxd_OejLAx99NBYQ7rzLwaGbfOrwydlowd72Zd5QvSt8YXqVLauAYUJakCgyfUx7pyFCT5JXMocPvnfJRXRkStk4jK-83EcrUepJ1LzzYTh5uKJeSBwg2fG-TtibRrrCEs9XeYjW98J79GlNX_NLavklrR3n4bvh1BrhdKv7g10kYnGR4dwzk6AUKMPcBYT4duqHzRyaDQVcNsmcEGKKXdbmcdkfvXFO-dLEGE1TDlQF9GnyRYseAqauhWbHkS-PqQ7VJpF1DPRJFM0Nlw9qoCHCTw21sjfhMzDQWmNndD5cqXf0CnPBTvO5tzYqCkmDFaqVmUhezvgPGzbaJrEfKhjICZVafCmChAHD9-jCgjonHXUXzNzmO9orsMJevGE2YoT9cU8tlplJBBmdAFMc1yj8Jj59Tbji82K6Amsn4AmyIYJGvIUuMPWOoQT-BHJf-gl6Spd5ZR5vDYqQTeqhpDWSNYPwj8mwSgzxgCts0M-B-14mRLCYQ7aikFpJdzlrkvTTLhwcYDGSmTLW2Cr0gfUWjjRNEriPO5WZcDv0kUl59dBPWJ0tWj6-Yc2TMZjsZCHpdwv92KBh2qz3-6qquTVoj-s220pt6LaVjWWK75br0Sz3qzERm7rtuRyoQ685Muq5GW1oj3FTmz2Yovr5XYj5Kaq2arEQShdkDIL67qF8j7iYbPfLsuFFjVqnz4EOM_S5PRJ4A5JyHXsPFuVWvngnwMEFXT6eEgb1vdsfTdm9a7v4duF6LYF8tRnc_SzKhfR6cP_7SQpazKKlPj_AgAA__9pST8O">