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

Top level break instruction causes panic on REPL #584

Closed
hachi8833 opened this issue Jan 23, 2018 · 2 comments · Fixed by #837
Closed

Top level break instruction causes panic on REPL #584

hachi8833 opened this issue Jan 23, 2018 · 2 comments · Fixed by #837
Assignees

Comments

@hachi8833
Copy link
Member

The following Goby code from https://github.com/goby-lang/goby/blob/master/vm/statement_test.go#L13 causes panic only on REPL:

x = [1, 2, 3]
y = 0
x.each do |i|
  y += i
  if i == 2
    break
  end
end
y
» y
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x68 pc=0x43ef404]

goroutine 1 [running]:
github.com/goby-lang/goby/vm.(*VM).REPLExec(0xc4200a6780, 0xc4201e69c0, 0x5, 0x8)
	/Users/hachi8833/deve/golang/gopath/sys/src/github.com/goby-lang/goby/vm/repl.go:38 +0x4d4
github.com/goby-lang/goby/igb.StartIgb(0x4577c2d, 0x5)
	/Users/hachi8833/deve/golang/gopath/sys/src/github.com/goby-lang/goby/igb/repl.go:231 +0xd23
main.main()
	/Users/hachi8833/deve/golang/gopath/sys/src/github.com/goby-lang/goby/goby.go:29 +0x954

Note that the code works fine when running as a file.

And the following works fine on REPL; looks like the bug only occurs on top level break instruction.

» def foo
¤   x = [1, 2, 3]
¤   y = 0
¤   x.each do |i|
¤     y += i
¤     if i == 2
¤       break
¤     end
¤   end
¤   y
» end

» foo
#» 3

FYI: complied with Go 1.9.3.

@ear7h
Copy link
Contributor

ear7h commented Mar 1, 2018

Was looking into this today. Seem like something with the break statement. The following snippet is interesting because it doesn't panic at the break statement, but at an instruction afterwards. I'm guessing that break pops the stack more times than necessary at the top level.

Goby 0.1.7 🙃 😚 😺
» [1, 2, 3].each do |i|
¤   break
» end
#» [1, 2, 3]
»
» y = 0
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x60 pc=0x44006b5]

goroutine 1 [running]:
github.com/goby-lang/goby/vm.(*VM).REPLExec(0xc4200a6820, 0xc4201fa6c0, 0x3, 0x4)
	/Users/julio/lib/go/src/github.com/goby-lang/goby/vm/repl.go:38 +0x435
github.com/goby-lang/goby/igb.StartIgb(0x459e471, 0x5)
	/Users/julio/lib/go/src/github.com/goby-lang/goby/igb/repl.go:231 +0xc13
main.main()
	/Users/julio/lib/go/src/github.com/goby-lang/goby/goby.go:29 +0x8fc

@ear7h ear7h self-assigned this Mar 1, 2018
@ear7h
Copy link
Contributor

ear7h commented Mar 1, 2018

@hachi8833

Ran another test (see snippet below) and the problem seems to be related to the top level but not with the break statement being on the top level. I'm not really sure why, but some instruction on the top level after the a break statement.

Goby 0.1.7 🤓 😐 🤧
» def foo
¤   [1, 2, 3].each do |i|
¤     break
¤   end
¤   y = 0
» end

» foo
#» 0
» y = 0
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x60 pc=0x44006b5]

goroutine 1 [running]:
github.com/goby-lang/goby/vm.(*VM).REPLExec(0xc4200a68c0, 0xc420204cc0, 0x5, 0x8)
	/Users/julio/lib/go/src/github.com/goby-lang/goby/vm/repl.go:38 +0x435
github.com/goby-lang/goby/igb.StartIgb(0x459e471, 0x5)
	/Users/julio/lib/go/src/github.com/goby-lang/goby/igb/repl.go:231 +0xc13
main.main()
	/Users/julio/lib/go/src/github.com/goby-lang/goby/goby.go:29 +0x8fc

@st0012 st0012 mentioned this issue Mar 2, 2018
@st0012 st0012 modified the milestones: version 0.1.12, version 0.1.13 Feb 14, 2020
@st0012 st0012 assigned st0012 and unassigned ear7h Mar 21, 2020
st0012 added a commit that referenced this issue Mar 22, 2020
@st0012 st0012 closed this as completed in 9c2e449 Mar 22, 2020
st0012 added a commit that referenced this issue Mar 22, 2020
@st0012 st0012 linked a pull request Apr 26, 2020 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants