Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Question: how to debug non-compiling code? (syscall error) #1104

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
msikma opened this issue Feb 9, 2022 · 3 comments
Closed

Question: how to debug non-compiling code? (syscall error) #1104

msikma opened this issue Feb 9, 2022 · 3 comments

Comments

@msikma
Copy link

msikma commented Feb 9, 2022

Hi all. I'm a JS dev who's a total noob to Go, and I've been looking into GopherJS because I'm currently working on a tool that will run in the browser and would really greatly benefit from being able to run a library written in Go that's not available on any other platform.

For testing purposes I'm doing everything in Node so far. What I've been wondering about is if there's some way to more easily debug problems—for example, right now I've made a really simple script that calls the library I want and tried to use it on a single file and then print the results.

It compiles, but then crashes when running:

$ gopherjs build main.go
$ node main.js
2022/02/09 14:39:22 a
/Users/msikma/Projects/screp-js/cmd/screp-js/main.js:1610
        throw err;
        ^

Error: runtime error: native function not implemented: internal/abi.FuncPCABI0
    at $callDeferred (/Users/msikma/Projects/screp-js/cmd/screp-js/main.js:1526:17)
    at $panic (/Users/msikma/Projects/screp-js/cmd/screp-js/main.js:1581:3)
    at throw$1 (/Users/msikma/Projects/screp-js/cmd/screp-js/main.js:2710:3)
    at Object.FuncPCABI0 (/Users/msikma/Projects/screp-js/cmd/screp-js/main.js:7726:3)
    at Object.Open (/Users/msikma/Projects/screp-js/cmd/screp-js/main.js:18376:12)
    at openFileNolog (/Users/msikma/Projects/screp-js/cmd/screp-js/main.js:26608:19)
    at OpenFile (/Users/msikma/Projects/screp-js/cmd/screp-js/main.js:27288:10)
    at Object.Open (/Users/msikma/Projects/screp-js/cmd/screp-js/main.js:27278:10)
    at Object.NewFromFile (/Users/msikma/Projects/screp-js/cmd/screp-js/main.js:38181:11)
    at ParseFileConfig (/Users/msikma/Projects/screp-js/cmd/screp-js/main.js:40405:21)
    at Object.ParseFile (/Users/msikma/Projects/screp-js/cmd/screp-js/main.js:40391:10)
    at main (/Users/msikma/Projects/screp-js/cmd/screp-js/main.js:41377:18)
    at $init (/Users/msikma/Projects/screp-js/cmd/screp-js/main.js:41402:9)
    at $goroutine (/Users/msikma/Projects/screp-js/cmd/screp-js/main.js:1601:19)
    at $runScheduled (/Users/msikma/Projects/screp-js/cmd/screp-js/main.js:1647:7)
    at $schedule (/Users/msikma/Projects/screp-js/cmd/screp-js/main.js:1671:5)
    at $go (/Users/msikma/Projects/screp-js/cmd/screp-js/main.js:1633:3)
    at Object.<anonymous> (/Users/msikma/Projects/screp-js/cmd/screp-js/main.js:41414:1)
    at Object.<anonymous> (/Users/msikma/Projects/screp-js/cmd/screp-js/main.js:41417:4)
    at Module._compile (node:internal/modules/cjs/loader:1101:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at main (/Users/msikma/Projects/screp-js/cmd/screp-js/main.js:41377:18)
    at $init (/Users/msikma/Projects/screp-js/cmd/screp-js/main.js:41402:9)
    at $goroutine (/Users/msikma/Projects/screp-js/cmd/screp-js/main.js:1601:19)
    at $runScheduled (/Users/msikma/Projects/screp-js/cmd/screp-js/main.js:1647:7)
    at $schedule (/Users/msikma/Projects/screp-js/cmd/screp-js/main.js:1671:5)
    at $go (/Users/msikma/Projects/screp-js/cmd/screp-js/main.js:1633:3)
    at Object.<anonymous> (/Users/msikma/Projects/screp-js/cmd/screp-js/main.js:41414:1)
    at Object.<anonymous> (/Users/msikma/Projects/screp-js/cmd/screp-js/main.js:41417:4)
    at Module._compile (node:internal/modules/cjs/loader:1101:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:79:12)
    at node:internal/main/run_main_module:17:47

When compiling for Linux (I'm on macOS), it seems I get a bit more information:

$ GOOS=linux gopherjs build main.go
$ node main.js
2022/02/09 14:48:16 a
warning: system calls not available, see https://github.com/gopherjs/gopherjs/blob/master/doc/syscalls.md
2022/02/09 14:48:16 b
2022/02/09 14:48:16 c
2022/02/09 14:48:16 d
2022/02/09 14:48:16 null

After going through the document and installing the syscall module, I still get the same error compiling for Darwin, but compiling for Linux now yields the following:

$ node main.js
2022/02/09 14:59:29 a
fish: Job 1, 'node main.js' terminated by signal SIGSYS (Bad system call)

My guess in this case is that the system call for opening files is not working. In the library it does the following:

// NewFromFile creates a new Decoder that reads and decompresses data form a
// file.
func NewFromFile(name string) (d Decoder, err error) {
	var f *os.File
	f, err = os.Open(name)
	if err != nil {
		return
	}
...

I'm guessing this is probably the issue that I'd need to look into, in this particular case. Like maybe I need to use Node's own methods for loading the file and then rewrite the library code to accept a file buffer?

My question is, is there a better process for tracking down problems and knowing how to fix them? As a JS developer who hasn't worked in Go before I feel a little out of depth here and I'm not sure how to approach things that might come up. Any tips are greatly appreciated.

@nevkontakte
Copy link
Member

First, appreciate a detailed report, it makes a lot easier to provide support :)

Are you using an M1 Mac? It is, unfortunately, a known problem that under M1 Mac GopherJS doesn't work well: #1041. The biggest problem is that neither of current GopherJS maintainers have an M1 Mac, so it's hard for us to test against it. If you build with GOOS=linux, but run on Mac OS, the crash is unsurprising — linux syscalls are incompatible with darwin. There are some long-term enhancements planned (#693), but I haven't had enough time to finish them yet.

In the short term, you have several options:

  • If you are learning Go, it might be easier to get your program working with a regular Go compiler first, and then port it over to GopherJS. Assuming it doesn't use unsafe package, it should be little to no changes.
  • You can proceed with a browser-oriented version from the start. All the issues reside at the boundary between GopherJS and OS, and in a browser filesystem is not a thing :)
  • You can use github.com/gopherjs/gopherjs/js package to invoke Node's fs package to read and write files. It won't be idiomatic Go, but it will work :)
  • Finally, you could spin up a Linux VM, in which syscalls will work as expected.

Hope that helps :)

@msikma
Copy link
Author

msikma commented Feb 11, 2022

Thanks for your help! I totally forgot to mention this, but I'm on macOS 10.14 on an Intel machine, so this is not an M1 issue at least.

I'm going to actually try a slightly different route, since my eventual goal is to have this run in the browser rather than on Node I'll just see if I can use the library with a binary buffer as input rather than a filename, and then figure out how to connect a JS browser file buffer from a drag and drop operation to that. That should obviate the need for syscalls to begin with.

Your list of options is very helpful, so thanks for that. I'll give it a go.

@nevkontakte
Copy link
Member

Glad to hear that. I'll close this issue for now, feel free to reopen if you have more questions. Also, we have a #gopherjs channel in the Gophers slack, feel free to join and ask there :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants