Skip to content

fmt.Println causes SIGSEGV with target=arduino #349

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

Closed
directionless opened this issue May 14, 2019 · 7 comments
Closed

fmt.Println causes SIGSEGV with target=arduino #349

directionless opened this issue May 14, 2019 · 7 comments
Labels
bug Something isn't working

Comments

@directionless
Copy link
Contributor

directionless commented May 14, 2019

I'm not sure if this is a bug, or a limitation of the arduino platform:


func printOne() {
	fmt.Println("one")
}

func main() {
	f := printOne
	f()
}

Results in: (as run from a recently tiny-go docker container)

root@4aaf709538b5:/go/src/github.com/directionless/tiny-go-experiments# tinygo build -o test -target=arduino  ./func-pointers/
fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x1 addr=0x418 pc=0x7f7815ff6cdc]

runtime stack:
runtime.throw(0x842ef6, 0x2a)
	/usr/local/go/src/runtime/panic.go:617 +0x72
runtime.sigpanic()
	/usr/local/go/src/runtime/signal_unix.go:374 +0x4a9

goroutine 1 [syscall]:
runtime.cgocall(0x76ecb0, 0xc001065508, 0xc002bc73a8)
	/usr/local/go/src/runtime/cgocall.go:128 +0x5b fp=0xc0010654d8 sp=0xc0010654a0 pc=0x41ebfb
github.com/tinygo-org/tinygo/vendor/tinygo.org/x/go-llvm._Cfunc_LLVMTargetMachineEmitToMemoryBuffer(0x2d697d0, 0x2d7f340, 0xc000000001, 0xc002bc73a0, 0xc002bc73a8, 0xc000000000)
	_cgo_gotypes.go:8849 +0x4d fp=0xc001065508 sp=0xc0010654d8 pc=0x5efafd
github.com/tinygo-org/tinygo/vendor/tinygo.org/x/go-llvm.TargetMachine.EmitToMemoryBuffer.func1(0x2d697d0, 0x2d7f340, 0x1, 0xc002bc73a0, 0xc002bc73a8, 0x0)
	/go/src/github.com/tinygo-org/tinygo/vendor/tinygo.org/x/go-llvm/target.go:274 +0x18b fp=0xc001065548 sp=0xc001065508 pc=0x617ddb
github.com/tinygo-org/tinygo/vendor/tinygo.org/x/go-llvm.TargetMachine.EmitToMemoryBuffer(0x2d697d0, 0x2d7f340, 0x1, 0xc002bd21c0, 0x1b, 0x1)
	/go/src/github.com/tinygo-org/tinygo/vendor/tinygo.org/x/go-llvm/target.go:274 +0x84 fp=0xc0010655b0 sp=0xc001065548 pc=0x5fd624
github.com/tinygo-org/tinygo/compiler.(*Compiler).EmitObject(0xc00011a4e0, 0xc002bd21c0, 0x1b, 0xc002bd21c0, 0x1b)
	/go/src/github.com/tinygo-org/tinygo/compiler/compiler.go:2515 +0x4a fp=0xc001065600 sp=0xc0010655b0 pc=0x709d6a
main.Compile(0x7fff54d72eb1, 0x10, 0x7fff54d72e9e, 0x2, 0xc00013a160, 0xc001065f00, 0xc001065d88, 0x0, 0x0)
	/go/src/github.com/tinygo-org/tinygo/main.go:206 +0xbe9 fp=0xc001065d40 sp=0xc001065600 pc=0x75bfe9
main.Build(0x7fff54d72eb1, 0x10, 0x7fff54d72e9e, 0x2, 0x7fff54d72ea9, 0x7, 0xc000091f00, 0xc000104250, 0xc00010a200)
	/go/src/github.com/tinygo-org/tinygo/main.go:311 +0xe2 fp=0xc001065db0 sp=0xc001065d40 pc=0x75ed72
main.main()
	/go/src/github.com/tinygo-org/tinygo/main.go:604 +0xc74 fp=0xc001065f98 sp=0xc001065db0 pc=0x760a04
runtime.main()
	/usr/local/go/src/runtime/proc.go:200 +0x20c fp=0xc001065fe0 sp=0xc001065f98 pc=0x44943c
runtime.goexit()
	/usr/local/go/src/runtime/asm_amd64.s:1337 +0x1 fp=0xc001065fe8 sp=0xc001065fe0 pc=0x473b01

goroutine 5 [syscall]:
os/signal.signal_recv(0x0)
	/usr/local/go/src/runtime/sigqueue.go:139 +0x9c
os/signal.loop()
	/usr/local/go/src/os/signal/signal_unix.go:23 +0x22
created by os/signal.init.0
	/usr/local/go/src/os/signal/signal_unix.go:29 +0x41

Works fine when called with -target=qemu

directionless added a commit to directionless/drivers that referenced this issue May 14, 2019
Some initial testing. This code doesn’t seem to work on my Arduino board. Still debugging.

Due to tinygo-org/tinygo#349 the interface feels cumbersome.

Until we understand how to work with white LEDs, there are a couple of interfaces. It’s all an experiment
@aykevl
Copy link
Member

aykevl commented May 14, 2019

This is a limitation of the AVR backend in TinyGo. It has many bugs and limitations being a relatively new backend that doesn't get as much love as it should. I don't think there is a lot we can do about that, except wait for it to improve (or help it improve).

@aykevl
Copy link
Member

aykevl commented May 14, 2019

By the way, the issue here is probably the use of the fmt package. If you just use println for printing, things should improve.

@deadprogram deadprogram changed the title Functions assigned to variables Functions assigned to variables on AVR platforms May 14, 2019
@deadprogram deadprogram added the bug Something isn't working label May 14, 2019
@directionless
Copy link
Contributor Author

directionless commented May 15, 2019

Oh! You're right. The bug was fmt.Println vs println. Probably shouldn't be a SIGSEGV. I'll rename the bug.

simplest reproduction:

func main() {
	fmt.Println("sdf")
}

@directionless directionless changed the title Functions assigned to variables on AVR platforms fmt.Println causes SIGSEGV with target=arduino May 15, 2019
@niaow
Copy link
Member

niaow commented Mar 1, 2020

When building with a copy of LLVM with asserts on, we get some more information:

llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:9642: void llvm::SelectionDAGISel::LowerArguments(const llvm::Function&): Assertion `InVals.size() == Ins.size() && "LowerFormalArguments didn't emit the correct number of values!"' failed.

@niaow
Copy link
Member

niaow commented Mar 1, 2020

I think we hit some UB inside of LLVM, am adding some asserts into the relevant pass

@donleyp
Copy link

donleyp commented Dec 13, 2020

Hey, there! Is there a workaround for formatting numbers? I need to output numbers in binary and hexadecimal, not decimal. I am runninng on an ATMega2560

@dgryski
Copy link
Member

dgryski commented Feb 1, 2023

This example no longer segfaults the compiler and #2389 is tracking the actual error message produced by the compiler.

@dgryski dgryski closed this as completed Feb 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

6 participants