cmd/link: nil pointer dereference crash when building with an Android NDK toolchain #34788

mvdan · 2019-10-09T14:53:54Z

The only requisite is a version of Go and the NDK r18 installed at $ANROID_NDK. I can reproduce on go version devel +a38a917aee Wed Oct 9 06:14:44 2019 +0000 linux/amd64 and go version go1.13.1 linux/amd64.

Below is the script to reproduce the crash:

#!/bin/bash

set -e

go version
cat $ANDROID_NDK/source.properties

$ANDROID_NDK/build/tools/make-standalone-toolchain.sh --arch=x86 --install-dir=toolchain
TOOLCHAIN=$PWD/toolchain

git clone --depth=1 -b obfs4proxy-0.0.11 https://github.com/Yawning/obfs4 2>/dev/null

cd obfs4/obfs4proxy

GOARCH=386 GOOS=android CC=$TOOLCHAIN/bin/i686-linux-android-clang CGO_ENABLED=1 go build -buildmode=exe .

Here is the output from Go master:

go version devel +a38a917aee Wed Oct 9 06:14:44 2019 +0000 linux/amd64
Pkg.Desc = Android NDK
Pkg.Revision = 18.0.5002713
HOST_OS=linux
HOST_EXE=
HOST_ARCH=x86_64
HOST_TAG=linux-x86_64
HOST_NUM_CPUS=8
BUILD_NUM_CPUS=16
Toolchain installed to toolchain.
# gitlab.com/yawning/obfs4.git/obfs4proxy
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0x57a7f3]

goroutine 1 [running]:
cmd/link/internal/ld.elfrelocsect(0xc0006fe000, 0xc004cde190, 0xc000378000, 0x1a0c, 0x389c)
        /home/mvdan/tip/src/cmd/link/internal/ld/elf.go:1356 +0x783
cmd/link/internal/ld.Elfemitreloc(0xc0006fe000)
        /home/mvdan/tip/src/cmd/link/internal/ld/elf.go:1381 +0x10b
cmd/link/internal/x86.asmb2(0xc0006fe000)
        /home/mvdan/tip/src/cmd/link/internal/x86/asm.go:712 +0x3d6
cmd/link/internal/ld.Main(0x825c40, 0x10, 0x20, 0x1, 0x4, 0x8, 0x67ca5d, 0x12, 0x67fc3d, 0x18, ...)
        /home/mvdan/tip/src/cmd/link/internal/ld/main.go:271 +0xd7d
main.main()
        /home/mvdan/tip/src/cmd/link/main.go:65 +0x1bc

And from 1.13.1:

go version go1.13.1 linux/amd64
Pkg.Desc = Android NDK
Pkg.Revision = 18.0.5002713
HOST_OS=linux
HOST_EXE=
HOST_ARCH=x86_64
HOST_TAG=linux-x86_64
HOST_NUM_CPUS=8
BUILD_NUM_CPUS=16
Toolchain installed to toolchain.
# gitlab.com/yawning/obfs4.git/obfs4proxy
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0x58275f]

goroutine 1 [running]:
cmd/link/internal/ld.elfrelocsect(0xc000056000, 0xc004097c20, 0xc005472000, 0x1b74, 0x39fe)
        /usr/lib/go/src/cmd/link/internal/ld/elf.go:1356 +0x77f
cmd/link/internal/ld.Elfemitreloc(0xc000056000)
        /usr/lib/go/src/cmd/link/internal/ld/elf.go:1381 +0x10b
cmd/link/internal/x86.asmb2(0xc000056000)
        /usr/lib/go/src/cmd/link/internal/x86/asm.go:712 +0x3d6
cmd/link/internal/ld.Main(0x84bc40, 0x10, 0x20, 0x1, 0x4, 0x8, 0x6964d6, 0x12, 0x69969f, 0x18, ...)
        /usr/lib/go/src/cmd/link/internal/ld/main.go:271 +0xd9a
main.main()
        /usr/lib/go/src/cmd/link/main.go:65 +0x1d6

It seems like the line it fails on is an error line, so I assume this should error gracefully instead of panicking. I'm not sure though.

My intuition is that the build should succeed; this project in question (@grote's) was previously using Go 1.11.x without an issue. If the build should succeed here too, I'd suggest we backport a fix for 1.13.x.

/cc @cherrymui @mdempsky @ianlancetaylor @thanm as per the owners doc.

The text was updated successfully, but these errors were encountered:

thanm · 2019-10-09T15:04:03Z

I'll take look.

cherrymui · 2019-10-09T15:19:24Z

I haven't looked into this. My guess is that this may be related to CL http://golang.org/cl/173437. Maybe we missed a r.InitExt somewhere. But as @mvdan said, this probably will only get it from crashing to failing. So maybe there is something else.

(My previous comment is wrong.)

thanm · 2019-10-09T19:58:43Z

This appears to be related to the recent changes to the way TLS works on Android (see issue 29674).

As part of Go 1.13 we transitioned to a new TLS access sequence for Android that loads up the newly defined "runtime.tls_g" symbol. If you compile a Go source file with

GOARCH=386 GOOS=android go tool compile x.go

Here is what the prolog looks like (from go tool objdump):

  x.go:5   0x751  8b0d00000000   MOVL 0, CX          [2:6]R_ADDR:runtime.tls_g
  x.go:5   0x757  8b8900000000   MOVL 0(CX), CX      [2:6]R_TLS_LE
  x.go:5   0x75d  3b6108         CMPL 0x8(CX), SP

Note the R_TLS_LE relocation. Here is the description from
cmd/internal/objabi/reloctype.go:

	// R_TLS_LE, used on 386, amd64, and ARM, resolves to the offset of the
	// thread-local symbol from the thread local base and is used to implement the
	// "local exec" model for tls access (r.Sym is not set on intel platforms but is
	// set to a TLS symbol -- runtime.tlsg -- in the linker when externally linking).

At the point of the crash in the linker, we're trying to process an R_TLS_LE relocation on a text symbol (regular Go function), but the relocation's Xsym field is nil, so it tries to execute this line:

Errorf(s, "missing xsym in relocation %#v %#v", r.Sym.Name, s)

which faults because r.Sym is also nil. The code that ordinarily would have filled the r.Sym is here:

cmd/link/internal/ld/data.go:230

	case objabi.R_TLS_LE:
		if ctxt.LinkMode == LinkExternal && ctxt.IsELF {
			r.Done = false
			if r.Sym == nil {
				r.Sym = ctxt.Tlsg
			}
			r.Xsym = r.Sym
			r.Xadd = r.Add

however ctxt.Tlsg is now also nil due to CL 169618.

Not quite sure what the right fix is here-- as I understand it we are no longer using the "local exec" model for TLS (is this right?) in which case we should not have the R_TLS_RE in this case?

cherrymui · 2019-10-09T21:39:08Z

Thanks @thanm for looking into this!

in which case we should not have the R_TLS_RE in this case?

I think this is the right fix.

thanm · 2019-10-10T16:15:49Z

OK, I have a tentative fix, which I will send shortly. I am wondering where would be the place to put a test for this... I will consult with the team.

gopherbot · 2019-10-10T16:16:51Z

Change https://golang.org/cl/200337 mentions this issue: cmd/compile: fix spurious R_TLE_LE reloc on android/386

mvdan · 2019-10-10T16:23:23Z

Great! Should the build succeed after this patch, or simply error without a panic?

thanm · 2019-10-10T16:41:36Z

@mvdan the build should succeed.

thanm · 2019-10-10T16:45:43Z

@gopherbot Please open a backport to 1.13.

gopherbot · 2019-10-10T16:45:49Z

Backport issue(s) opened: #34825 (for 1.13).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases.

cagedmantis · 2019-12-03T18:57:23Z

@thanm @mvdan Can this issue be reproduced in 1.12? If so, can you backport the fix to 1.12 as well.

mvdan · 2019-12-03T19:11:53Z

1.12 only receives security updates at this point, so I don't think this fix qualifies. Also, I'm pretty sure the bug only appeared in 1.13.

thanm · 2019-12-03T19:12:49Z

I agree with @mvdan , this change depends on other things in 1.13 -- don't think it would be easily back-portable to 1.12.

cagedmantis · 2019-12-03T19:26:17Z

Both 1.12 and 1.13 are equally supported. Thank you for confirming that the fix isn't necessary for 1.12.

mvdan added the NeedsFix label Oct 9, 2019

mvdan added this to the Go1.14 milestone Oct 9, 2019

thanm self-assigned this Oct 9, 2019

rsc modified the milestones: Go1.14, Backlog Oct 9, 2019

thanm modified the milestones: Backlog, Go1.14 Oct 10, 2019

gopherbot mentioned this issue Oct 10, 2019

cmd/link: nil pointer dereference crash when building with an Android NDK toolchain [1.13 backport] #34825

Closed

gopherbot closed this as completed in e7ce862 Oct 29, 2019

golang locked and limited conversation to collaborators Dec 2, 2020

gopherbot added the FrozenDueToAge label Dec 2, 2020

rsc unassigned thanm Jun 23, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

cmd/link: nil pointer dereference crash when building with an Android NDK toolchain #34788

cmd/link: nil pointer dereference crash when building with an Android NDK toolchain #34788

mvdan commented Oct 9, 2019

thanm commented Oct 9, 2019

cherrymui commented Oct 9, 2019 •

edited

Loading

thanm commented Oct 9, 2019

cherrymui commented Oct 9, 2019

thanm commented Oct 10, 2019

gopherbot commented Oct 10, 2019

mvdan commented Oct 10, 2019

thanm commented Oct 10, 2019

thanm commented Oct 10, 2019

gopherbot commented Oct 10, 2019

cagedmantis commented Dec 3, 2019

mvdan commented Dec 3, 2019

thanm commented Dec 3, 2019

cagedmantis commented Dec 3, 2019

cmd/link: nil pointer dereference crash when building with an Android NDK toolchain #34788

cmd/link: nil pointer dereference crash when building with an Android NDK toolchain #34788

Comments

mvdan commented Oct 9, 2019

thanm commented Oct 9, 2019

cherrymui commented Oct 9, 2019 • edited Loading

thanm commented Oct 9, 2019

cherrymui commented Oct 9, 2019

thanm commented Oct 10, 2019

gopherbot commented Oct 10, 2019

mvdan commented Oct 10, 2019

thanm commented Oct 10, 2019

thanm commented Oct 10, 2019

gopherbot commented Oct 10, 2019

cagedmantis commented Dec 3, 2019

mvdan commented Dec 3, 2019

thanm commented Dec 3, 2019

cagedmantis commented Dec 3, 2019

cherrymui commented Oct 9, 2019 •

edited

Loading