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: MADVISE syscall seems not to be called when using signal.Notify according to strace #42231
Comments
Thank you @leighhopcroft for filing this issue, and welcome to the Go project! I shall kindly rope in some experts @mknyszek @aclements @ianlancetaylor. |
FWIW the runtime does think it's releasing memory to the OS (try running with The fact that it's inconsistent suggests to me that for some reason By default If you include the |
Yes, you must always use Optimistically closing. Please comment if there is still a problem here. |
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 env
OutputWhat did you do?
I built three different go programs:
"direct" https://play.golang.org/p/JN6OdiiGLzn
Define a function to
makeGarbage
in an infinate loop, call direct frommain
."background" https://play.golang.org/p/8RuVoEdudbW
Define a channel of
os.Signal
, callmakeGarbage
in a goroutine and wait forever on empty channel inmain
."notify" https://play.golang.org/p/CXPOnvefgvQ
Define a channel of
os.Signal
, callsignal.Notify
to catch SIGINT, callmakeGarbage
in a goroutine and wait on chan recv for SIGINT to occur.I then ran all three binaries using
strace -q -e trace=memory ./${BINARY_NAME}
What did you expect to see?
All three programs showing relevant
mmap
andmadvise
syscalls corresponding to the allocation and freeing of OS memory.What did you see instead?
"direct" and "background" behave as expected with the following typical output (ignoring SIGURG lines):
grep -v SIGURG direct.strace.log
Outputwhereas "notify" shows the
mmap
calls but does not show anymadvise
calls. See the following typical output (ignoring SIGURG lines):grep -v SIGURG notify.strace.log
OutputDoes this mean that the memory is not actually being released back to the OS, or is it just that there is some interaction with
signal.Notify
andstrace
visibility of themadvise
syscalls?The text was updated successfully, but these errors were encountered: