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

Jump to bottom

test/fixedbugs: issue11656.go fails on Go1.17.3 for armv7l (Odroid-HC1) #49508

Open
Talkless opened this issue Nov 10, 2021 · 15 comments
Open

test/fixedbugs: issue11656.go fails on Go1.17.3 for armv7l (Odroid-HC1) #49508

Talkless opened this issue Nov 10, 2021 · 15 comments
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-Android
Milestone
Backlog

Comments

@Talkless
Copy link

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

Building 1.17.3
With 
# /usr/lib/go-1.11/bin/go version
go version go1.11.6 linux/arm
On
# uname -a
Linux odroid-hc1 4.19.0-18-armmp-lpae #1 SMP Debian 4.19.208-1 (2021-09-29) armv7l GNU/Linux

Does this issue reproduce with the latest release?

Yes, 1.17.3 tag.

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

go env Output
# /usr/lib/go-1.11/bin/go env
GOARCH="arm"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="arm"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/root/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/lib/go-1.11"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go-1.11/pkg/tool/linux_arm"
GCCGO="gccgo"
GOARM="6"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -marm -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build812163099=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Building 1.17.3 under Debian 10 Buster using script:

# cat my.go.build.sh 
#!/usr/bin/env bash

set -eu

export GOROOT_BOOTSTRAP=/usr/lib/go-1.11
(
    pushd go.git/src
    ./all.bash
)

What did you expect to see?

Successfull build, as 1.15.x was built before.

What did you see instead?

exit status 2                                                                                                                                                
SIGILL: illegal instruction                                                                                                                                  
PC=0x20a097c m=0 sigcode=1                                                                                                                                   
instruction bytes: 0x0 0x0 0x80 0xe5 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0

...
...

FAIL    fixedbugs/issue11656.go 1.335s
2021/11/10 21:32:15 Failed: exit status 1                                                            
                             
##### API check                                                                                     
Go version is "go1.17.3", ignoring -next /root/code/golang/go.git/api/next.txt
go tool dist: FAILED
@randall77
Copy link
Contributor

That instruction looks reasonable, if odd. It is

e5800000                MOVW R0, (R0)

But more generally, that doesn't really look like an instruction stream. The following instructions are all zeros, which would be

00000000                AND.EQ R0, R0, R0

which are useless instructions.

Can you build the test directly, using go build test/fixedbugs/issue11656.go and run it?
Can you disassemble it and see where that pc 0x20a097c lies?
I suspect it is some non-executable mapping.
Not sure how that would come about. Maybe tracing the execution in a debugger would help find when we jumped to that address.

@cherrymui
Copy link
Member

issue11656.go intentionally writes an artificial function in memory, which includes an MOVW R0, (R0) instruction and it is supposed to fault there (seg fault, not SIGILL). And the following bytes are all 0.

@randall77
Copy link
Contributor

So then this just looks like the heap is marked as non-executable?
I would think we'd have that same problem on other platforms if that was the case.
I guess we depend on getting a segv instead of a sigill?

@cherrymui
Copy link
Member

cherrymui commented Nov 10, 2021 •
edited

I guess we depend on getting a segv instead of a sigill?

Yeah. I think if the heap is not executable we expect to get a SEGV at the call instruction. If it is executable, we expect to get a SEGV from the heap.

SIGILL would be weird. Maybe some I-cache coherence thing? (So we read the data in the SIGILL handler (from D-cache, perhaps) and get the correct instruction)

@Talkless
Copy link
Author

Can I skip that one test somehow? Or I shouldn't because it's actually something wrong?

@cherrymui
Copy link
Member

@Talkless depends on what you want to do. You can skip the test by adding an ignore build tag to test/fixedbugs/issue11656.go, or simply delete that file. If you just want to build the Go toolchain, at the point where that test runs it is already built so you can just use it (and you can just run make.bash instead of make.bash).

@randall77
Copy link
Contributor

If you want to help us fix the Go distribution for all users, we'll need to figure out what exactly is different about your system.
Does it SIGILL when trying to execute code on non-executable pages? Or is something else going on?

@Talkless
Copy link
Author

@Talkless depends on what you want to do.

I just want to built some Go-based software, not as developer, as a user.

Does it SIGILL when trying to execute code on non-executable pages? Or is something else going on?

IDK, I was just building Go, please let me know how could I answer these questions.

@cherrymui
Copy link
Member

I just want to built some Go-based software, not as developer, as a user.

Then you can just run make.bash, instead of all.bash.

@odeke-em odeke-em changed the title 1.17.3 build fails under fixedbugs/issue11656.go on armv7l (Odroid-HC1) test/fixedbugs: issue11656.go fails on Go1.17.3 for armv7l (Odroid-HC1) Nov 13, 2021
@Talkless
Copy link
Author

Can you build the test directly, using go build test/fixedbugs/issue11656.go and run it?

Sorry, I've missed that question.

So I did:

/usr/lib/go-1.11/bin/go build test/fixedbugs/issue11656.go

and the output is:

SIGILL: illegal instruction
PC=0x2480f0c m=0 sigcode=4

goroutine 1 [running]:
runtime: unknown pc 0x2480f0c
stack: frame={sp:0x248097c, fp:0x0} stack=[0x2480000,0x2481000)
024808fc:  00000000  00000000  00000000  00000000 
0248090c:  00000000  00000000  00000000  00000000 
0248091c:  00000000  00000000  00000000  00000000 
0248092c:  00000000  00000000  00000000  00000000 
0248093c:  00000000  00000000  00000000  00000000 
0248094c:  00000000  00000000  00000000  00000000 
0248095c:  00000000  00000000  00000000  00000000 
0248096c:  00000000  00000000  00000000  00000000 
0248097c: <0007ac54 <main.f+136>  00000000  02480988  e3a00000 
0248098c:  e5800000  00000000  00000000  00000000 
0248099c:  00000000  00000000  00000000  00000000 
024809ac:  00000000  00000000  00000000  00000000 
024809bc:  00000000  00000000  00000000  0007ac54 <main.f+136> 
024809cc:  00000000  00000000  00000000  00000000 
024809dc:  00000000  00000000  00000000  00000000 
024809ec:  00000000  00000000  00000000  00000000 
runtime: unknown pc 0x2480f0c
stack: frame={sp:0x248097c, fp:0x0} stack=[0x2480000,0x2481000)
024808fc:  00000000  00000000  00000000  00000000 
0248090c:  00000000  00000000  00000000  00000000 
0248091c:  00000000  00000000  00000000  00000000 
0248092c:  00000000  00000000  00000000  00000000 
0248093c:  00000000  00000000  00000000  00000000 
0248094c:  00000000  00000000  00000000  00000000 
0248095c:  00000000  00000000  00000000  00000000 
0248096c:  00000000  00000000  00000000  00000000 
0248097c: <0007ac54 <main.f+136>  00000000  02480988  e3a00000 
0248098c:  e5800000  00000000  00000000  00000000 
0248099c:  00000000  00000000  00000000  00000000 
024809ac:  00000000  00000000  00000000  00000000 
024809bc:  00000000  00000000  00000000  0007ac54 <main.f+136> 
024809cc:  00000000  00000000  00000000  00000000 
024809dc:  00000000  00000000  00000000  00000000 
024809ec:  00000000  00000000  00000000  00000000 

trap    0x0
error   0x2480984
oldmask 0x0
r0      0x2480988
r1      0x24809c8
r2      0x0
r3      0x0
r4      0x0
r5      0x2
r6      0xb6fae8ec
r7      0x2480984
r8      0x0
r9      0x0
r10     0x24000e0
fp      0x7ac60
ip      0x13
sp      0x248097c
lr      0x7ac44
pc      0x2480f0c
cpsr    0x20000010
fault   0x0

@mengzhuo
Copy link
Contributor

FYI, I've tested on qemu arm (go 1.17.1) and it works fine.

@cherrymui
Copy link
Member

/usr/lib/go-1.11/bin/go

@Talkless Go 1.11 is very old. Could you try newer version of Go, Go 1.16, 1.17, or tip? Thanks.

@heschi heschi added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Nov 22, 2021
@heschi heschi added this to the Go1.18 milestone Nov 22, 2021
@Talkless
Copy link
Author

/usr/lib/go-1.11/bin/go

@Talkless Go 1.11 is very old. Could you try newer version of Go, Go 1.16, 1.17, or tip? Thanks.

Wait, I did it wrong I guess. I had to build Go 1.17.3 from source using Debian Buser's 1.11, and THEN using newly built 1.17.3 build that unit test, right?

@cherrymui cherrymui modified the milestones: Go1.18, Backlog Nov 23, 2021
@cherrymui
Copy link
Member

cherrymui commented Nov 23, 2021 •
edited

I had to build Go 1.17.3 from source using Debian Buser's 1.11, and THEN using newly built 1.17.3 build that unit test, right?

Yes, that sounds right. Or you can download it from https://go.dev/dl/ .

@Talkless
Copy link
Author 

# bin/go version                                                       
go version go1.17.3 linux/arm
# bin/go build test/fixedbugs/issue11656.go
# ./issue11656
SIGILL: illegal instruction
PC=0x49a980 m=0 sigcode=1
instruction bytes: 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0

goroutine 1 [running]:
runtime: unknown pc 0x49a980
stack: frame={sp:0x49a96c, fp:0x0} stack=[0x49a000,0x49b000)
0x0049a8ec:  0x0001f1b4 <runtime.heapBits.forwardOrBoundary+0x00000064>  0x00000000  0x00000000  0x0001fc94 <runtime.heapBits.initSpan+0x00000064> 
0x0049a8fc:  0x0001ad94 <runtime.mallocgc+0x00000750>  0x00000000  0x00000001  0xa6dbffff 
0x0049a90c:  0x00000800  0xa6d8b000  0x00000000  0x00000001 
0x0049a91c:  0xa6dbffff  0x00000800  0x000225a8 <runtime.(*mcentral).grow+0x00000100>  0xa6d8ae00 
0x0049a92c:  0x00000200  0x00000001  0xa6dbffff  0x0001f1b4 <runtime.heapBits.forwardOrBoundary+0x00000064> 
0x0049a93c:  0xa6d8b000  0x00000000  0x0001fc94 <runtime.heapBits.initSpan+0x00000064>  0xa6d8b000 
0x0049a94c:  0x00000000  0x00000001  0xa6dbffff  0x00000800 
0x0049a95c:  0xa6d8b200  0x00000000  0x00000001  0xa6dbffff 
0x0049a96c: <0x0007b14c <main.f+0x00000028>  0x000225a8 <runtime.(*mcentral).grow+0x00000100>  0x0049a978  0xe3a00000 
0x0049a97c:  0xe5800000  0x00000000  0x00000000  0x00000000 
0x0049a98c:  0x00000000  0x00000000  0x00000000  0x00000000 
0x0049a99c:  0x00000000  0x00000000  0x00000000  0x00000000 
0x0049a9ac:  0x00000000  0x00000000  0x00000000  0x0007b14c <main.f+0x00000028> 
0x0049a9bc:  0x00000000  0x000ff878  0x0049e0b8  0x00000000 
0x0049a9cc:  0xb6fc17e8  0x00079760 <path.init+0x0000001c>  0x00000008  0x00086748 
0x0049a9dc:  0x00021701 <runtime.(*mcache).refill+0x00000029>  0x0049e0b8  0x00052bdc <runtime.doInit+0x00000114>  0x00086748 
runtime: unknown pc 0x49a980
stack: frame={sp:0x49a96c, fp:0x0} stack=[0x49a000,0x49b000)
0x0049a8ec:  0x0001f1b4 <runtime.heapBits.forwardOrBoundary+0x00000064>  0x00000000  0x00000000  0x0001fc94 <runtime.heapBits.initSpan+0x00000064> 
0x0049a8fc:  0x0001ad94 <runtime.mallocgc+0x00000750>  0x00000000  0x00000001  0xa6dbffff 
0x0049a90c:  0x00000800  0xa6d8b000  0x00000000  0x00000001 
0x0049a91c:  0xa6dbffff  0x00000800  0x000225a8 <runtime.(*mcentral).grow+0x00000100>  0xa6d8ae00 
0x0049a92c:  0x00000200  0x00000001  0xa6dbffff  0x0001f1b4 <runtime.heapBits.forwardOrBoundary+0x00000064> 
0x0049a93c:  0xa6d8b000  0x00000000  0x0001fc94 <runtime.heapBits.initSpan+0x00000064>  0xa6d8b000 
0x0049a94c:  0x00000000  0x00000001  0xa6dbffff  0x00000800 
0x0049a95c:  0xa6d8b200  0x00000000  0x00000001  0xa6dbffff 
0x0049a96c: <0x0007b14c <main.f+0x00000028>  0x000225a8 <runtime.(*mcentral).grow+0x00000100>  0x0049a978  0xe3a00000 
0x0049a97c:  0xe5800000  0x00000000  0x00000000  0x00000000 
0x0049a98c:  0x00000000  0x00000000  0x00000000  0x00000000 
0x0049a99c:  0x00000000  0x00000000  0x00000000  0x00000000 
0x0049a9ac:  0x00000000  0x00000000  0x00000000  0x0007b14c <main.f+0x00000028> 
0x0049a9bc:  0x00000000  0x000ff878  0x0049e0b8  0x00000000 
0x0049a9cc:  0xb6fc17e8  0x00079760 <path.init+0x0000001c>  0x00000008  0x00086748 
0x0049a9dc:  0x00021701 <runtime.(*mcache).refill+0x00000029>  0x0049e0b8  0x00052bdc <runtime.doInit+0x00000114>  0x00086748 

trap    0x6
error   0x0
oldmask 0x0
r0      0x49a978
r1      0x49a9b8
r2      0x0
r3      0x0
r4      0x10
r5      0xf1960
r6      0x0
r7      0x49a974
r8      0x7
r9      0x8
r10     0x4000f0
fp      0x93a1c
ip      0x49e113
sp      0x49a96c
lr      0x7b1b0
pc      0x49a980
cpsr    0x20000010
fault   0x0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-Android
Projects
None yet
Milestone
Backlog
Development

No branches or pull requests
6 participants
@Talkless @mengzhuo @odeke-em @randall77 @cherrymui @heschi