Skip to content
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

Go 1.3 and 1.4 test with race raise an exceptions #68

Closed
miry opened this issue Sep 9, 2015 · 9 comments
Closed

Go 1.3 and 1.4 test with race raise an exceptions #68

miry opened this issue Sep 9, 2015 · 9 comments

Comments

@miry
Copy link

miry commented Sep 9, 2015

Tested in Alpine 3.2(go 1.4) and 3.1(go 1.3)

When tried to run tests with -race. I got next exception:

# runtime/race
race_linux_amd64.syso: In function `__sanitizer::InternalAlloc(unsigned long, __sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator32<0ul, 140737488355328ull, 16ul, __sanitizer::SizeClassMap<17ul, 64ul, 14ul>, 24ul, __sanitizer::TwoLevelByteMap<2048ull, 4096ull, __sanitizer::NoOpMapUnmapCallback>, __sanitizer::NoOpMapUnmapCallback> >*)':
gotsan.cc:(.text+0x1130): undefined reference to `__libc_malloc'
race_linux_amd64.syso: In function `__tsan::WriteMemoryProfile(char*, unsigned long)':
gotsan.cc:(.text+0x929b): undefined reference to `__libc_mallinfo'
race_linux_amd64.syso: In function `__sanitizer::ReExec()':
gotsan.cc:(.text+0xa047): undefined reference to `__libc_stack_end'
race_linux_amd64.syso: In function `__sanitizer::InternalFree(void*, __sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator32<0ul, 140737488355328ull, 16ul, __sanitizer::SizeClassMap<17ul, 64ul, 14ul>, 24ul, __sanitizer::TwoLevelByteMap<2048ull, 4096ull, __sanitizer::NoOpMapUnmapCallback>, __sanitizer::NoOpMapUnmapCallback> >*)':
gotsan.cc:(.text+0x4d8d): undefined reference to `__libc_free'
collect2: error: ld returned 1 exit status

Tried to use https://github.com/andyshinn/alpine-pkg-glibc also.

But it works without -race option: go test -v ./...

Created simple example to reproduce issue: https://gist.github.com/miry/fece267c7faba904c360

@miry miry changed the title Go 1.3 and 1.4 test with race exceptions Go 1.3 and 1.4 test with race raise an exceptions Sep 9, 2015
@progrium
Copy link
Contributor

progrium commented Sep 9, 2015

Doesn't it normally work without the race option without glibc?

I can imagine race might use non-standard features of libc that are not in
musl. And that somehow the way it uses libc cannot pick up glibc, perhaps
because it depends on utilities (ld, etc) that are going to be set up for
musl.

On Wed, Sep 9, 2015 at 2:54 AM, Michael Nikitochkin <
[email protected]> wrote:

Tested in Alpine 3.2(go 1.4) and 3.1(go 1.3)

When tried to run tests with -race. I got next exception:

runtime/race

race_linux_amd64.syso: In function __sanitizer::InternalAlloc(unsigned long, __sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator32<0ul, 140737488355328ull, 16ul, __sanitizer::SizeClassMap<17ul, 64ul, 14ul>, 24ul, __sanitizer::TwoLevelByteMap<2048ull, 4096ull, __sanitizer::NoOpMapUnmapCallback>, __sanitizer::NoOpMapUnmapCallback> >*)': gotsan.cc:(.text+0x1130): undefined reference to__libc_malloc'
race_linux_amd64.syso: In function __tsan::WriteMemoryProfile(char*, unsigned long)': gotsan.cc:(.text+0x929b): undefined reference to__libc_mallinfo'
race_linux_amd64.syso: In function __sanitizer::ReExec()': gotsan.cc:(.text+0xa047): undefined reference to__libc_stack_end'
race_linux_amd64.syso: In function __sanitizer::InternalFree(void*, __sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator32<0ul, 140737488355328ull, 16ul, __sanitizer::SizeClassMap<17ul, 64ul, 14ul>, 24ul, __sanitizer::TwoLevelByteMap<2048ull, 4096ull, __sanitizer::NoOpMapUnmapCallback>, __sanitizer::NoOpMapUnmapCallback> >*)': gotsan.cc:(.text+0x4d8d): undefined reference to__libc_free'
collect2: error: ld returned 1 exit status

Tried to use https://github.com/andyshinn/alpine-pkg-glibc also.

But it works without -race option: go test -v ./...

Created simple example to reproduce issue:
https://gist.github.com/miry/fece267c7faba904c360


Reply to this email directly or view it on GitHub
#68.

Jeff Lindsay
http://progrium.com

@andyshinn
Copy link
Contributor

It looks like at the very least __libc_stack_end is an internal glibc symbol and not in musl. I think the Golang race detector is using some c++ stuff which is not fully compatible with musl.

Have you checked out the How do I use the musl-gcc wrapper? section at http://www.musl-libc.org/faq.html? It explains a little bit about the issue. Is there a way to recompile the Golang runtime/race detector against musl maybe?

I don't know enough about Golang and how it uses a toolchain, c++, and gcc to really dig into this.

@miry
Copy link
Author

miry commented Sep 10, 2015

@progrium @andyshinn Thanks for clarification. I will try to use Go 1.5.1, so it should not depends on libc. Do you have build for this version?

@andyshinn
Copy link
Contributor

Go 1.5 is in alpine:edge.

@miry
Copy link
Author

miry commented Sep 10, 2015

Ok. Found golang/go#12122. For go15 the race still use libc :(

@miry miry closed this as completed Sep 10, 2015
@miry
Copy link
Author

miry commented Sep 10, 2015

some logs from me:

CGO_LDFLAGS="-g" "-O2" /usr/lib/go/pkg/tool/linux_amd64/cgo -objdir $WORK/runtime/race/_obj/ -importpath runtime/race -import_syscall=false -- -I $WORK/runtime/race/_obj/ race.go
gcc -I . -fPIC -m64 -pthread -fmessage-length=0 -I $WORK/runtime/race/_obj/ -g -O2 -o $WORK/runtime/race/_obj/_cgo_main.o -c $WORK/runtime/race/_obj/_cgo_main.c
gcc -I . -fPIC -m64 -pthread -fmessage-length=0 -I $WORK/runtime/race/_obj/ -g -O2 -o $WORK/runtime/race/_obj/_cgo_export.o -c $WORK/runtime/race/_obj/_cgo_export.c
gcc -I . -fPIC -m64 -pthread -fmessage-length=0 -I $WORK/runtime/race/_obj/ -g -O2 -o $WORK/runtime/race/_obj/race.cgo2.o -c $WORK/runtime/race/_obj/race.cgo2.c
gcc -I . -fPIC -m64 -pthread -fmessage-length=0 -o $WORK/runtime/race/_obj/_cgo_.o $WORK/runtime/race/_obj/_cgo_main.o $WORK/runtime/race/_obj/_cgo_export.o $WORK/runtime/race/_obj/race.cgo2.o race_linux_amd64.syso -g -O2
# runtime/race
race_linux_amd64.syso: In function `__sanitizer::InternalAlloc(unsigned long, __sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator32<0ul, 140737488355328ull, 0ul, __sanitizer::SizeClassMap<17ul, 64ul, 14ul>, 20ul, __sanitizer::TwoLevelByteMap<32768ull, 4096ull, __sanitizer::NoOpMapUnmapCallback>, __sanitizer::NoOpMapUnmapCallback> >*)':
gotsan.cc:(.text+0x15e1): undefined reference to `__libc_malloc'
race_linux_amd64.syso: In function `__sanitizer::ReExec()':
gotsan.cc:(.text+0x7177): undefined reference to `__libc_stack_end'
race_linux_amd64.syso: In function `__sanitizer::InternalFree(void*, __sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator32<0ul, 140737488355328ull, 0ul, __sanitizer::SizeClassMap<17ul, 64ul, 14ul>, 20ul, __sanitizer::TwoLevelByteMap<32768ull, 4096ull, __sanitizer::NoOpMapUnmapCallback>, __sanitizer::NoOpMapUnmapCallback> >*)':
gotsan.cc:(.text+0x50e8): undefined reference to `__libc_free'
collect2: error: ld returned 1 exit status
$WORK/github.com/pubnative/ad_server/_test/ad_server.test -test.v=true
FAIL    github.com/pubnative/ad_server [build failed]

@andyshinn
Copy link
Contributor

Thanks for linking up the Golang issue for others to find. Indeed, it looks like this won't work until Golang fixes up the race detector to support other libc or is rewritten in pure Golang.

@jerome-laforge
Copy link

jerome-laforge commented Apr 26, 2017

From the alpine dockerfile, I can see that you compile go from the source.
The link below gives us how to compile with race support.
https://getgb.io/faq/#missing-race-support

Could you take it in account?
Thx

@tianon
Copy link
Collaborator

tianon commented Apr 26, 2017

See golang/go#14481 -- Go upstream does not support the race detector on Alpine Linux yet.

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

No branches or pull requests

5 participants