On Thu, May 23, 2019 at 9:05 PM <zodn...@gmail.com> wrote: > > Is there something else I can try to isolate this (msan and race have not > been fruitful)? Note our C code has some memory sanity options in it too - we > have a storage manager in it that on request will over-allocate all requests > placing the requested storage in the middle, then back-filling all but the > requested storage with 0xdeadbeef values with the entire storage chain having > their backfills verified on every storage invocation. That too is running > clean. Also, the first thing our C code does when it gets control is take out > a lock because our C code is not (yet) multi-threaded so that part is > single-threaded.
I haven't looked at your code so I don't know if it will help, but you can try setting the environment variable GODEBUG=cgocheck=2 when you run the program. That will turn on a more intensive set of tests for whether you are violating the cgo pointer passing rules. In general, read those rules, at https://golang.org/cmd/cgo, and make sure that you are following them. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcX3HckyaypEgkPm%3DzSgBX-sLtjskA6NeuBbMncsnF%2BH7w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
