[Lldb-commits] [PATCH] D67793: new api class: SBFile

Lawrence D'Anna via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Mon Jan 13 11:13:16 PST 2020


lawrence_danna marked an inline comment as done.
lawrence_danna added inline comments.


================
Comment at: lldb/trunk/scripts/Python/python-typemaps.swig:481
+  PyBuffer_Release(&view);
+  $1 = ($1_ltype) buf;
+  $2 = ($2_ltype) (size/sizeof($*1_type));
----------------
labath wrote:
> vadimcn wrote:
> > Sorry for being late to the party, but I just stumbled upon this code...  
> > 
> > It seems to return a pointer from a view that had just been released.  Isn't this kind of risky?   While most of the time buffer views point into object's internal memory, buffer protocol does not prohibit allocating memory just to fulfill the buffer request.  In which case PyBuffer_Release would be expected to release that memory, leaving the caller with a dangling pointer.
> Yes, that does seem worrying, though the swig typemap also does the same thing (but it could have the same bug too). @lawrence_danna, do you know anything about this? Should the buffer be released after the function returns (in the "out" typemap, I guess)?
@vadimcn   is correct.    If GetBuffer allocates to fulfill the request, rather than returning a pre-existing buffer, then this will access a dangling pointer.

@labath  "in" and "out" type-maps aren't paired up like that.   

I believe there is a way you can instruct SWIG to create a C++ helper variable for a typemap.   The solution in this case is to use such a temporary to carry the PyBuffer reference in RAII-style.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67793/new/

https://reviews.llvm.org/D67793





More information about the lldb-commits mailing list