> So, if the reservation scheme breaks down, it is possible that a C pointer > is allocated, and then freed, and the C allocator releases the memory, > but the dangling pointer survives, and the Go allocator allocates that > space, and the C dangling pointer somehow gets into Go, where it is > treated as a Go pointer.
How about this piece of code <https://play.golang.org/p/i5o874qbxI> in the play? I think it is possible to happen just like what you described even the reservation scheme works well, but it's been used very often in the current cgo implementation and many open source projects. package main > /* > #include <stdlib.h> > */ > import "C" > import ( > "fmt" > "os" > "runtime" > "unsafe" > ) > func main() { > type BigObject struct { > arr [1024 * 1024]byte > } > goCstring := func(s string) *C.char { > // C.malloc -> `addr0` > p := C.malloc(C.size_t(len(s) + 1)) > pp := (*[1 << 30]byte)(p) > copy(pp[:], s) > pp[len(s)] = 0 > // go has the 1st object:pp reference to `addr0` > // although slice pp is not been reference-d anymore > // but it still exist before the runtime.GC() > return (*C.char)(p) > } > { > s := string(make([]byte, 1024*1024)) > p := goCstring(s) > // C.free(`addr0`) > C.free(unsafe.Pointer(p)) > } > // go malloc -> `addr0` again > // the slice pp now points to valid go memory :) > { > b := BigObject{} > _ = b > } > // 1st GC in go > // go has 2 objects both reference to `addr0` now > // the Problem: > // what is the gc's behaviour in this circumstance? > // could this lead to some unexpected bugs ? > runtime.GC() > os.Exit(0) > } > But that is really no different from any other way that C can create > an invalid pointer and pass it into Go. *If an invalid C pointer gets * >* treated as a Go pointer*, there is a bug in the program. Let's define this Go pointer as `*pp`*. What if the `invalid C pointer been passed into go` accidently has the same memory address with one or several already exist go objects (some objects like channel, mutex or self defined struct, etc). Could it be possible to lead some disasters to occur even if `*pp*` isn't been referenced anymore? (Reminds me of this thread <https://groups.google.com/forum/#!topic/golang-nuts/i9OVP11rNoc>) Still, in the bottom of the doc in pkg/unsafe <https://golang.org/pkg/unsafe/>, there has this statement: In general, reflect.SliceHeader and reflect.StringHeader should be used > only > as *reflect.SliceHeader and *reflect.StringHeader pointing at actual > slices or > strings, never as plain structs. A program should not declare or allocate > variables > of these struct types. > > // INVALID: a directly-declared header will not hold Data as a reference. > var hdr reflect.StringHeader > hdr.Data = uintptr(unsafe.Pointer(p)) > hdr.Len = n > s := *(*string)(unsafe.Pointer(&hdr)) // p possibly already lost If this statement cannot break at any time, then there would be something wrong with the current implementation of _Cfunc_CString and the POC is this code <https://play.golang.org/p/i5o874qbxI> mentioned before. PS: Please forgive me because maybe I am just asking some stupid questions. I want to make sure that each lines of the codes I write is absolutely correct and no dangerous side cases. Thanks a lot. Enjoy! On Friday, September 22, 2017 at 10:34:33 PM UTC+8, Ian Lance Taylor wrote: > > On Fri, Sep 22, 2017 at 6:54 AM, Remus Clearwater > <remus.cl...@gmail.com <javascript:>> wrote: > > > > Hi Gernot, do you mean that the virtual address space used for `mmap` > > calling by go malloc and glibc's are always different? If the virtual > > address > > space of go malloc and glibc's are designed to be different > intentionally, > > could you please tell me where I could found the specs and guarantees? > > Does jemalloc/tcmalloc has this virtual address space convention too? > > It is a tittle weird still, I was thought they are self-adaption. > > The Go memory allocator attempts to reserve the address space it is > going to use in calls to runtime.sysReserve, a function that is > OS-specific. Look in the runtime package for the implementation for > the operating systems that you care about. > > In any case, the Go allocator has data structures that record the > valid addresses, and it does not give up that address space unless it > knows that there are no valid Go pointers into that space. So, if the > reservation scheme breaks down, it is possible that a C pointer is > allocated, and then freed, and the C allocator releases the memory, > but the dangling pointer survives, and the Go allocator allocates that > space, and the C dangling pointer somehow gets into Go, where it is > treated as a Go pointer. But that is really no different from any > other way that C can create an invalid pointer and pass it into Go. > If an invalid C pointer gets treated as a Go pointer, there is a bug > in the program. Reusing a C pointer after it has been freed is just a > special case of that. > > 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.
