runtime: Go program "just terminates" with exit 0 #15873
Comments
|
The runtime shouldn't exit with status 0,
there must be some code that is caling
os.Exit(0).
Please double check the source code,
and if you're using cgo, check the external
c/c++ code too.
|
|
@minux Of course I agree with you, otherwise I wouldn't have reported this. There's nothing I'm calling that calls Exit, and the etcd authors said there is nothing that does it either. When it happened an earlier time I figured it was my fault, but when I got the log with the assembly code, I realized it was probably a golang bug. There's no reason I would see that asm line AFAIK. |
|
It's pretty hard to diagnose this without the source of your program. Can On Mon, May 30, 2016 at 7:53 AM, James notifications@github.com wrote:
|
|
On Sun, May 29, 2016 at 6:11 PM, Dave Cheney notifications@github.com
Once I can distill the code down, I will. I suppose the binary won't help? |
|
You could try using gdb to debug the program and
use "catch syscall exit_group" to catch the point
where the process issues the exit syscall.
When the catchpoint is hit, please issue bt command
to see exactly where issues the exit syscall.
|
|
This seems to be related to issues where a null pointer would get used and in the protobuf golang package. So in theory if your code has zero bugs (mine doesn't) then you won't hit this. So something is either failing in a strange way, or something relating to protobufs is suppressing the trace dump on null pointer. |
ianlancetaylor
changed the title
|
We need a test case or the backtrace that minux suggested. |
|
I am running into the exact same problem in one of our microservices. The only thing we were able to observe is that some network polling fails before it happens, but that might or might not be related. I searched the entire code base (including vendored libraries), and the only place where it calls It simply shouldn't be possible for the application to exit with It happens on a timescale of several hours to several days, so it's really hard to track anything down. |
|
We need a test case. |
|
Our issue was, in fact, unrelated to this. The shutdown messages were just hidden in front of hundreds of warnings in the log, as execution was terminating and closing everything down. The reason for the shutdown was an unexpected signal other than SIGINT, SIGTERM and SIGHUP being issued, and us deciding to catch all signals. After we stopped catching the signal, the software stopped "crashing". We still don't know what issued the signal, since we found nothing in OS logs. |
|
Timeout. Closing this bug. Without details or a repro, we can't help. |
While hacking on a medium sized golang project, I've found that certain things seem to cause my program to terminate, but without any trace or exit code. I'm assuming this is a golang bug, since there's no clear reason why the program would exit without reason.
I've got a binary that I compiled that experiences this, and I can reproduce it on other machines.
I'm running golang:
go version go1.5.4 linux/amd64
On Fedora 23.
If this is a known issue someone can point me to, I'd appreciate it, otherwise please let me know what I can run to debug this.
Here is the output of my most recent terminate:
Of particular note is that the last line contains the contents of a log.Printf command, which is some debugging text I put there, but it doesn't happen at asm_amd64.s:438 (I've enabled logging of file and line numbers)
Thanks for your time, and I'm happy to post the binary if anyone is interested.
The text was updated successfully, but these errors were encountered: