Skip to content
This repository has been archived by the owner on Aug 13, 2019. It is now read-only.

Potential unsafe memory access #86

Open
maxnordlund opened this issue Oct 23, 2014 · 1 comment
Open

Potential unsafe memory access #86

maxnordlund opened this issue Oct 23, 2014 · 1 comment

Comments

@maxnordlund
Copy link

I was browsing through the code today and noticed something that looked odd:

    cstr := C.CString(v)
    defer C.free(unsafe.Pointer(cstr))
    p = unsafe.Pointer(cstr)

    ...

    return p

Won't this create a unsafe memory access?

@jrick
Copy link
Member

jrick commented Oct 24, 2014

Yes, it's a use after free. Nice catch.

Since pointerVal is only called by Object.Set, and I think the memory handling for other types is incorrect as well, I think that whole function body should be moved into Object.Set.

The other memory problem here is that while returning an unsafe.Pointer does cause the pointed to Go value to escape to heap, the value is never freed if it is passed to a C function as a void * and is not type converted back to a Go pointer. So while the other types don't cause undefined behavior like strings do here, they are still memory leaks.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants