[Lldb-commits] [PATCH] D18459: Fix FILE * leak in Python API

[Zachary Turner via lldb-commits]

Could there be an overload of SBCommandReturnObject constructor that takes
an fd instead of a FILE*, and pass through to the private method which does
its own duping? Then this typemap could be changed to convert to int
instead of to FILE*

Also I'm OOO until tomorrow now, so I can't look at the code again until
then
On Thu, Mar 24, 2016 at 3:56 PM Francis Ricci <fjricci at fb.com> wrote:

> fjricci added inline comments.
>
> ================
> Comment at: scripts/Python/python-typemaps.swig:532
> @@ -531,3 +524,1 @@
> -         file.Clear();
> -    }
>  }
> ----------------
> zturner wrote:
> > zturner wrote:
> > > fjricci wrote:
> > > > The problem is that here, we save the `FILE*` (`$1`) and let the
> `File` (`file`) go out of scope. So the `File` gets destructed (but it's
> after calling `file.Clear()`, so the close doesn't happen). But we still
> hold onto the `FILE*`, and we pass it, as `$1`, to the API call (not seen
> here, but it comes right after this block in the generated swig cpp code).
> > > I think SWIG explicitly has a mechanism to handle this.  Let me find
> it.
> > It's the `freearg` [[
> http://www.swig.org/Doc1.3/Typemaps.html#Typemaps_nn33 | typemap ]].
> >
> > Basically you can put a rule that just calls `fclose()` on the argument,
> and it will generate this code after it's called the API.
> >
> > Would this work?
> So the issue is that we don't want to `fclose()` after
> `SetImmediateOutputFile()`, we want it to `fclose()` when we're done
> writing to the `FILE*`, which happens when the `CommandReturnObject` is
> destructed.
>
>
> http://reviews.llvm.org/D18459
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20160324/84583757/attachment-0001.html>