On Tue, Jan 9, 2018 at 6:01 PM Ian Lance Taylor <i...@golang.org> wrote:
> On Mon, Jan 8, 2018 at 5:28 PM, Justin Israel <justinisr...@gmail.com>
> wrote:
> >
> > I've got a cgo library that needed a pass of adding runtime.KeepAlive()
> to
> > prevent crashes when passing C pointers into cgo calls. Today a similar
> > crash occurred in one of my functions in the library that looks like the
> > following:
> >
> > func (i *ImageBuf) ReadFormatCallback(force bool, convert TypeDesc,
> progress
> > *ProgressCallback) error {
> > var cbk unsafe.Pointer
> > if progress != nil {
> > cbk = unsafe.Pointer(progress)
> > }
> >
> > ok := C.ImageBuf_read(i.ptr, 0, 0, C.bool(force),
> C.TypeDesc(convert),
> > cbk)
> > if !bool(ok) {
> > return i.LastError()
> > }
> >
> > return nil
> > }
> >
> > I had not added a KeepAlive() call after the C function because I assumed
> > the conditional usage of i.LastError() would keep it alive. Am I wrong in
> > that assumption? Should I still have a KeepAlive() call here?
> >
> > This could be a completely unrelated crash, although it looks the same as
> > the other SIGSEGV crashes that I had fixed.
>
> It depends. If `i.LastError()` is inlined, then whether the call
> keeps `i` alive or not depends on what the method does.
>
LastError()
<https://github.com/justinfx/openimageigo/blob/master/imagebuf.go#L56> will
always access the struct and pointer, and actually also includes its own
call to KeepAlive(). Maybe it is safer just to explicitly add the call
instead of relying on what the conditional logic, or inlining, may or may
not do.
>
> Ian
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
