New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

runtime: fatal error: bad pointer in write barrier in Cgo #15293

Open
whitezhang opened this Issue Apr 14, 2016 · 7 comments

Comments

Projects
None yet
2 participants
@whitezhang

whitezhang commented Apr 14, 2016

Please answer these questions before submitting your issue. Thanks!

  1. What version of Go are you using (go version)?

    go 1.6

  2. What operating system and processor architecture are you using (go env)?

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/map/zhanghuaizhi/tmpwork/2/nbserver/"
GORACE=""
GOROOT="/home/map/.jumbo/lib/go"
GOTOOLDIR="/home/map/.jumbo/lib/go/pkg/tool/linux_amd64"
GO15VENDOREXPERIMENT="1"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0"
CXX="g++"
CGO_ENABLED="1"

  1. What did you do?

I posted my question in stackoverflow, please take a look.

http://stackoverflow.com/questions/36591069/fatal-error-bad-pointer-in-write-barrier-in-cgo

Is that possible the address allocated by C is out the space of Golang?

@ianlancetaylor ianlancetaylor changed the title from fatal error: bad pointer in write barrier in Cgo to runtime: fatal error: bad pointer in write barrier in Cgo Apr 14, 2016

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Apr 14, 2016

Most likely your C code is somehow corrupting the Go heap. Try running your program with the environment variable GODEBUG set to cgocheck=2. Try running your program with the address sanitizer (-fsanitize=address).

@ianlancetaylor ianlancetaylor added this to the Unplanned milestone Apr 14, 2016

@whitezhang

This comment has been minimized.

whitezhang commented Apr 14, 2016

@ianlancetaylor I tried the following command GODEBUG=cgocheck=2 ./ttt -fsanitize=address, but when it crashed, I only get the same messages as before. Did I type the correct command?

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Apr 14, 2016

The GODEBUG setting is correct, though I guess it didn't help. The -fsanitize=address option is not. I was suggesting that you use that option when compiling your C code. This problem looks like memory corruption, which is almost certainly coming from the C code; you need to figure out what the C code is doing wrong.

@whitezhang

This comment has been minimized.

whitezhang commented Apr 15, 2016

@ianlancetaylor Actually, I have tested my C code by using valgrind. It told me that there is no memory leaks and everything is okay. I also used a loop(10000 times), to malloc and free the memory, but nothing crashed.
In the C code, printf("%d\n", *rgcmap); tells you the address allocated by malloc. And the error occurs in Go(line 78 fmt.Print("address", svc.maps)), which means the Go can not access to the maps of svc. Am I correct?

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Apr 15, 2016

The stack trace shows that a value that Go thinks should hold a pointer actually holds the value 0x20, which is not a valid pointer value. That is why the Go runtime is crashing.

My first guess would be memory corruption. But it is also possible that you are using a Go pointer to hold a value returned from C, and for some reason C is returning the value 0x20. That could cause this problem.

@whitezhang

This comment has been minimized.

whitezhang commented Apr 16, 2016

@ianlancetaylor I have a basic question. How to analyse the runtime stack? For example, my Go code is fmt.Print("address", svc.maps), and the runtime stack is fmt.Print(0xc8202bfe78, 0x2, 0x2, 0x4d5d00, 0x0, 0x0). How to make the connections between them? As I am thinking why you said that C is returning the value 0x20.
Basically, I have printed the address of the value which allocated by malloc. This address is -603977536. which I think is correct( is not 0x20)
So, I think that we still do not find the problem.

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Apr 17, 2016

The stack traceback maps to the arguments. A string is two words, a pointer, and a length, so in your example 0xc8202bfe78 is the string pointer and 0x2 is the string length. I don't know the type of svc.maps but the values you show suggest that it is four words long.

I never thought that malloc was returning 0x20. That would not make sense. I think that somewhere in your code a value that Go thinks holds a pointer is actually holding the value 0x20.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment