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

another sample for the problem in global variable definition #735

Closed
topxeq opened this issue Jul 2, 2020 · 0 comments · Fixed by #739
Closed

another sample for the problem in global variable definition #735

topxeq opened this issue Jul 2, 2020 · 0 comments · Fixed by #739
Assignees
Labels
area/core bug Something isn't working
Milestone

Comments

@topxeq
Copy link

topxeq commented Jul 2, 2020

First thanks to you all. The following program sample.go triggers a panic(maybe related to #730 ):

package main

import "strconv"

var optionsG map[string]string

var roundG int = 30

func strToInt(s string, defaultValue int) int {
	n, err := strconv.ParseInt(s, 10, 0)
	if err != nil {
		return defaultValue
	}

	return int(n)
}

func main() {

	optionsG := map[string]string{"round": "12", "b": "one"}

	roundG = strToInt(optionsG["round"], 50)

	println(roundG)

	println(optionsG)
}

Expected result:

$ go run ./sample.go
12
0xc000039e38

Got:

$ yaegi ./sample.go
sample.go:10:12: panic
sample.go:20:32: panic
reflect.Set: value of type int is not assignable to type map[string]string
goroutine 1 [running]:
runtime/debug.Stack(0x1, 0xc000368600, 0x40)
        c:/go/src/runtime/debug/stack.go:24 +0xa4
github.com/containous/yaegi/interp.(*Interpreter).Eval.func1(0xc00008fde0)
        D:/goprjs/src/github.com/containous/yaegi/interp/interp.go:333 +0xc3
panic(0xce3a40, 0xc00018ce90)
        c:/go/src/runtime/panic.go:969 +0x174
github.com/containous/yaegi/interp.runCfg.func1(0xc0003e40a0, 0xc0003f0100)
        D:/goprjs/src/github.com/containous/yaegi/interp/run.go:115 +0x213
panic(0xce3a40, 0xc00018ce90)
        c:/go/src/runtime/panic.go:969 +0x174
github.com/containous/yaegi/interp.runCfg.func1(0xc0003e4140, 0xc0003ee400)
        D:/goprjs/src/github.com/containous/yaegi/interp/run.go:115 +0x213
panic(0xce3a40, 0xc00018ce90)
        c:/go/src/runtime/panic.go:969 +0x174
reflect.Value.assignTo(0xce2f00, 0xc000402040, 0x182, 0xe1ae4b, 0xb, 0xd29d60, 0x0, 0xc000402050, 0x82, 0xc000402050)
        c:/go/src/reflect/value.go:2403 +0x42d
reflect.Value.Set(0xd29d60, 0xc000190288, 0x195, 0xce2f00, 0xc000402040, 0x182)
        c:/go/src/reflect/value.go:1532 +0xc4
github.com/containous/yaegi/interp._return.func1(0xc0003e4140, 0xc00018cce0)
        D:/goprjs/src/github.com/containous/yaegi/interp/run.go:1792 +0x88
github.com/containous/yaegi/interp.runCfg(0xc0003ee400, 0xc0003e4140)
        D:/goprjs/src/github.com/containous/yaegi/interp/run.go:121 +0x74
github.com/containous/yaegi/interp.call.func7(0xc0003e40a0, 0xc0003e1ab0)
        D:/goprjs/src/github.com/containous/yaegi/interp/run.go:991 +0xc49
github.com/containous/yaegi/interp.runCfg(0xc0003f0100, 0xc0003e40a0)
        D:/goprjs/src/github.com/containous/yaegi/interp/run.go:121 +0x74
github.com/containous/yaegi/interp.(*Interpreter).run(0xc0001b61a0, 0xc0003ef500, 0xc0003e4000)
        D:/goprjs/src/github.com/containous/yaegi/interp/run.go:99 +0x240
github.com/containous/yaegi/interp.(*Interpreter).Eval(0xc0001b61a0, 0xc000364340, 0x19f, 0x0, 0x0, 0x0, 0x0, 0x0)
        D:/goprjs/src/github.com/containous/yaegi/interp/interp.go:409 +0x532
main.main()
        D:/goprjs/src/github.com/containous/yaegi/cmd/yaegi/yaegi.go:159 +0x664
@mvertes mvertes added area/core bug Something isn't working labels Jul 2, 2020
@mvertes mvertes self-assigned this Jul 2, 2020
mvertes added a commit that referenced this issue Jul 2, 2020
In all situations where the results are set directly
to the frame, and not using a value helper, the right level of
indirections must be applied, otherwise we may end-up writing
in the wrong frame (the local one, instead of a caller or global).

Fixes #735.
@mvertes mvertes added this to the v0.8.x milestone Jul 2, 2020
mvertes added a commit that referenced this issue Jul 3, 2020
In all situations where the results are set directly
to the frame, and not using a value helper, the right level of
indirections must be applied, otherwise we may end-up writing
in the wrong frame (the local one, instead of a caller or global).

Fixes #735.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/core bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants