rifor ruby documentation, and recently
gdbdocs (or in my case https://github.com/vim-scripts/info.vim ))
You could try using malloc stack logging on MacOS. It logs every malloc / free and the stack for that malloc / free.
if you set the MallocStackLogging environment variable, you can use the
I would either 1) wait until memory grows really huge, then run
malloc_history -callTreeand find the offender, or 2) take a snapshot before, then run for a bit, and take a second snapshot and compare
@Fryguy the call stack is the inverse of what I was showing here in my screenshot:
well, mine specifically is one invocation of
malloc and the stacktrace at the point of the
malloc call, and that shows that it is mostly happening in
c. @jrafanie's screen shot at least shows that he is getting the same callstack as well.
What that means, to me at least, is that it is somehow how the strings and our environment is setup that is messing with the ruby internals to cause the leak. At least that is the conclusion that I am at currently