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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
