Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upruntime: unexpected return pc for os/signal.loop called from 0x0 #35005
Labels
Comments
This comment has been minimized.
This comment has been minimized.
|
Hello, thanks for the report. It will be very helpful to try to create a smaller snippet that can reproduce this issue in order to find the root problem. Are you able to narrow it down further? If not, can you share more complete steps to reproduce the problem, if possible? What commands did you run in order to get the crash? |
This comment has been minimized.
This comment has been minimized.
|
@dmitshur There's more information on the Nakama issue tracker under this ticket: Here's what we've been able to determine with our investigation so far:
The current theory is that there's an issue with how shared objects are loaded by the Go runtime in containers that use the most recent version of musl libc within Alpine Linux. Though only when the host OS is Windows or Ubuntu (only Linux distro I tried). Does this provide more context? I don't know whether the Go team considers musl libc a no-go with the Go runtime. Please advise on what the recommended course of action is for Go projects that are packaged with Alpine Linux or other non-GNU libc core libraries. |
This comment has been minimized.
This comment has been minimized.
|
@dmitshur I just put together a simple project that reproduces this at https://github.com/joshgarnett/nakama-2.7.0-go-1.13-crash |
This comment has been minimized.
This comment has been minimized.
|
Thanks for doing that. /cc @aclements @randall77 |
This comment has been minimized.
This comment has been minimized.
|
I can't get this to crash using the given repro. Could you give more explicit steps? A list of things you typed at the command line + results, perhaps? I don't think we officially support non-GNU libc, at least with linux. I don't think that's intentional, just that we can only really support what we test with, and all our linux platforms are GNU libc (I think). |
This comment has been minimized.
This comment has been minimized.
|
@randall77 I ran these steps on macOS with Docker 2.1.0.5: $> git clone "https://github.com/joshgarnett/nakama-2.7.0-go-1.13-crash"
$> cd "nakama-2.7.0-go-1.13-crash"
$> docker-compose -f docker-compose.yml build nakama
[snip]
Successfully built c3c1ed2a29b6
Successfully tagged nakama-270-go-113-crash_nakama:latest
$> docker-compose -f docker-compose.yml up
[snip]
nakama-crash | {"level":"info","ts":"2019-12-10T12:56:13.808Z","msg":"Starting API server for gRPC requests","port":7349}
nakama-crash | {"level":"info","ts":"2019-12-10T12:56:13.815Z","msg":"Starting API server gateway for HTTP requests","port":7350}
nakama-crash | {"level":"info","ts":"2019-12-10T12:56:14.838Z","msg":"Startup done"}I'm no longer able to reproduce this issue either. |
This comment has been minimized.
This comment has been minimized.
|
@novabyte the issue doesn't appear on OSX. Only on Windows. I just re-ran it on Windows 10 (1803) with Docker for Desktop 2.1.0.5 and saw the same crash. I also did a docker system prune -a and restarted my machine for good measure before running. Below is the output: |
This comment has been minimized.
This comment has been minimized.
|
Ah yes I'd forgotten |
This comment has been minimized.
This comment has been minimized.
|
Well, windows only makes it a problem. I only have access to windows on gomotes, and they don't have docker installed. I'm not sure how to get around that (rdp + install chrome + install chocolatey + install docker?). I thought the whole point of Docker was that the host OS doesn't matter? |
This comment has been minimized.
This comment has been minimized.
|
Not sure if it supports Docker, but if it helps: Microsoft distributes free Windows VMs for testing in (Internet Explorer) https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/. |
This comment has been minimized.
This comment has been minimized.
|
@randall77 That's what makes this bug super gnarly. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env)?go envOutputWhat did you do?
I'm building a module which is supposed to work with another program (https://github.com/heroiclabs/nakama). The program runs fine as long as I don't load the module and crashes with below error while loading the module.
The program even starts loading the module (I know it because I can see the logs from module) but crashes instantly.
What did you expect to see?
Not crash
What did you see instead?