Memory Leaks -- #3786 continued

This is a continue of #3786 (closed), as I noted there at the bottom... still seeing almost 4 GiB of memory usage after a bit more than two weeks :(

Hence, time to do more instrumentation of what is leaking.

Running the current nightly now, though I expect that to have similar issues in a while.

When it gets big please do this:

1. Determine the process ID of iTerm2. There will be multiple iTerm2 processes if you're on the beta version, so make sure to find the right one. This command should show you the right entry:

ps -aef | grep iTerm2 | grep -v launch_shell | grep -v server|grep -v grep

2. Run leaks pid > /tmp/leaks.txt, replacing pid with the process ID from step 1. This might take a long time.

3. Run heap pid -guessNonObjects -sumObjectFields -showSizes > /tmp/heap.txt, replacing pid with the process ID from step 2. This may take a very long time to run. Consider letting it go overnight.

4. Attach /tmp/leaks.txt and /tmp/heap.txt to this file.

Milestone changed to Ship 3.0

heap.txt

leak.txt was 212 MiB while gitlab only takes 10 MiB, but as it is repeating, I shortened it. Should be quite clear what was that leak, shortened version:

leaks.txt

or the info you need to really see:

Process 19327: 609892 nodes malloced for 179056 KB
Process 19327: 452852 leaks for 43594368 total leaked bytes.
Leak: 0x7fabc1402140  size=96  zone: DefaultMallocZone_0x10e7d5000   NSMutableParagraphStyle  ObjC  UIFoundation

Note that this was barely during a day of running in which it lost 43 MiB, hence why the near 4G after 17 days makes sense, and also why things get slow as those are 96 byte items... yep, I noticed it in typing speed ;)

Thanks, that was very helpful. Fixed in commit 40883ec4.

Status changed to closed

If you still get growth with tomorrow's nightly build, please repeat the above steps and re-open the issue.

mentioned in issue #372 (closed)