-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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
runtime: fatal error: free list corrupted in godoc after hours of idle #12879
Comments
/cc @aclements |
Is it possible for you to try this with 1.5.1? |
This isn't reproducible even on 1.5. It might have happened once more since the release of 1.5, but I don't remember exactly. I have upgraded to 1.5.1 and will let you know if it happens again. |
I'm not sure what's going on, but I will note that "0x206567616b636170" is the string "package ". Do you know if anything in particular was happening around the time when it crashed? It looks like the godoc server hasn't done anything at all for 191 minutes, meaning that this is a background sweep following a periodic GC, but it would be good if we can confirm that. |
godoc was not in use when it crashed. I was away from the computer when it happened, so 191 minutes sounds right. |
I am having the same problem on my http server in golang 1.5.1
|
@helinwang Can you easily reproduce this problem? Does your program use the unsafe package? Does it use cgo? Have you tried running it under the race detector? Thanks. |
@ianlancetaylor I am using cgo, easily reproducible in go 1.5 and go 1.5.1. Do you think it could be caused by memory leak in the c part? I doubt if it because of race --- the code is http request handling. |
If it is because of C code, it wouldn't be a memory leak in the C code, but rather an incorrect use of cgo corrupting the Go heap. For example, C code manipulating a pointer in the Go heap could cause this. Can you share your code? |
@aclements I can't share the entire code, the main part is in this line
I don't think (will double check) the c code will write to data beyond len(dst) |
@helinwang That code looks fine assuming there is no buffer overrun and assuming the C code does not try to retain a copy of the Go pointer. |
@ianlancetaylor @aclements thanks for the response, it's indeed a bug in my C code that overrun the c buffer that collapsed the heap memory. |
@helinwang Thanks for the follow up. This bug is still open for the original report by @thaustad. |
Got another one. Go 1.5.1 this time, with the same OS. The pointer decodes to ".com/p/a" which must be part of one of the "code.google.com/p/appengine-go" package names. I have added
|
@thaustad Can you post a copy of the output of $(go list ...) to get a sense of how many packages you have and therefore what the working set is for godoc? I'd like to see if I can reproduce this on my darwin/amd64 machine. Thanks. |
My
These are from the second (work) path:
I have removed 55 packages from the first path and 3 from the last. They are all written by me. Some random notes:
(I had another crash before the weekend that was different. I'll post it shortly.) |
Another, but different.
|
@thaustad, when you run godoc like this, do you just let it sit there completely idle, or is something actually accessing its web pages? |
Completely idle. I do have two Chrome browser tabs pointing at godoc, but those are also idle (at least from what I can tell from the development tools). By the way, Activity Monitor says godoc uses 5.59 GB. |
I'd like to find this, and I've got a godoc up in the background on my Mac to see what happens, but it's been days and so far nothing. I don't think a fix for this is going to make it into Go 1.5.2. Punting to Go 1.6. |
My gut feeling is that if it hasn't happened within 24 hours it won't happen. I restart godoc from time to time to include new packages. I am willing to run a custom godoc if you want to try that. |
This may be the same as #13372, which seems to be easier to reproduce. We'll try to chase that one for a little while. |
@bradfitz Actually, the bug has not happened since I last reported it. Don't know why. I still use the same Go and OS versions, but there has been some changes to the packages. I can checkout some old source and see if I can reproduce it again. |
I'm going to assume (hope) that this has been fixed somehow in the meantime. Please report if you find otherwise. |
MacOS 10.10.5
go version go1.5 darwin/amd64
Possible dup of #11411.
Please note the two comments marked with
//
.The text was updated successfully, but these errors were encountered: