Skip to content

panic: nil package for unexported qualified name #620

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.

Sign up for GitHub

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
Open
fiatjaf opened this issue Apr 7, 2017 · 5 comments
Open

panic: nil package for unexported qualified name #620

fiatjaf opened this issue Apr 7, 2017 · 5 comments

Comments

@fiatjaf
Copy link

fiatjaf commented Apr 7, 2017 •
edited
Loading

I'm seeing this error when building a package that imports another package. It uses --tags, don't know if it is related somehow.

The error: https://pastebin.com/raw/5RSvSQF9
My versions:

fiatjaf@cantillon ~/c/g/s/g/f/summuladb> gopherjs version
GopherJS 1.8-1
fiatjaf@cantillon ~/c/g/s/g/f/summuladb> go version
go version go1.8 linux/amd64

To (try to) reproduce, download the code from https://github.com/fiatjaf/summuladb/tree/ca927b4878876cb184118de8227382cfb16d31dc and run gopherjs build --tags=levelupjs on it.

But it is much stranger than that: basically the error vanishes and the package compiles perfectly as soon as I edit qualifiedName to include a log.Print() statement, which I did to start debugging. After a go get the error stopped happening and the logged things were being logged to the terminal, as expected. I then removed the log.Print() line and ran go get again. Still no errors.

An hour later the error appeared again in the meantime I had run gopherjs build multiple times in my package, without a problem, and didn't edit or ran anything else. Again, the error vanished after I did the log.Print() trick. This comeback keep happening every once in a while.

See more in the discussion starting at https://gophers.slack.com/archives/C039C0R2T/p1491492286272286.
@flimzy
Copy link
Member

flimzy commented Apr 7, 2017

This may not be of any help, but when I find myself chasing phantom errors like this in GopherJS, I've usually discovered that it's the result of a caching bug (See #559). If you clear the GopherJS cache before each test, do you still get errors? Do they become consistent?

rm -rf ${GOPATH}/pkg/*_js

@fiatjaf
Copy link
Author

fiatjaf commented Apr 7, 2017

Solved it!

@dmitshur
Copy link
Member

dmitshur commented Apr 8, 2017

It's good to hear that clearing the cache fixed it.

It'd still be nice to resolve this, so the problem cannot occur.

I can't immediately tell if it's identical to #559, but it's at least related.

The panic happens in github.com/gopherjs/gopherjs/third_party/importer package, which is code we don't control directly. It's a copy of an older package from x/tools, that was deprecated during various changes done there. It might be worth it to check if equivalent functionality is available elsewhere in x/tools by now that GopherJS can be updated to use instead.

But that may or may not be related to the panic that happened here, so I would imagine it'd make more sense to start by fixing #559 first.

@fiatjaf
Copy link
Author

fiatjaf commented Apr 10, 2017 •
edited
Loading

A tip: it is actually safer to run rm -rf ${GOPATH}/pkg/*_js_* instead of rm -rf ${GOPATH}/pkg/*_js, since gopherjs will save things at $GOPATH/pkg/pkg/linux_js_min/ when run with the -m option.

Doing rm -rf ${GOPATH}/pkg/*_js_* before every test or build will solve it for all cases.

@fiatjaf fiatjaf mentioned this issue Apr 10, 2017
Open
@dmitshur
Copy link
Member

I've fixed #559 just now. Is it possible for you to check if this issue still occurs with latest GopherJS?

@nevkontakte nevkontakte mentioned this issue Feb 16, 2022
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@fiatjaf @dmitshur @flimzy