Is there a memory leak in TextMate? I was running Activity Monitor and saw a memory usage spike. The application also became unresponsive, so I sampled it before doing a force quit. Here's what it came back with:
Not sure if it's relevant, but I was using a custom assembly language bundle at the time. The odd thing is I don't think TextMate was even the active application at the time the memory spiked. Very weird.
Ted
A bad bundle can give you this sort of behavior. Typically the cause is an incorrect regular expression in the bundle's parser. m.
On Apr 14, 2015, at 1:32 PM, Edward K. Chew ekchew@gmail.com wrote:
I was running Activity Monitor and saw a memory usage spike. The application also became unresponsive, so I sampled it before doing a force quit.
-- matt neuburg, phd = http://www.apeth.net/matt/ pantes anthropoi tou eidenai oregontai phusei Programming iOS 8! http://shop.oreilly.com/product/0636920034261.do iOS 8 Fundamentals! http://shop.oreilly.com/product/0636920034278.do RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html
Thanks. I was thinking there is another possibility too. The assembler I use generates a listing file. It's possible I might have had that open in TextMate when I ran the assembler again which would overwrite the open file. Could that lead to some kind of racing condition maybe? I'll take care not to do that from now on.
Ted
On Apr 14, 2015, at 6:54 PM, Matt Neuburg matt@tidbits.com wrote:
A bad bundle can give you this sort of behavior. Typically the cause is an incorrect regular expression in the bundle's parser. m.
On Apr 14, 2015, at 1:32 PM, Edward K. Chew ekchew@gmail.com wrote:
I was running Activity Monitor and saw a memory usage spike. The application also became unresponsive, so I sampled it before doing a force quit.
-- matt neuburg, phd = http://www.apeth.net/matt/ pantes anthropoi tou eidenai oregontai phusei Programming iOS 8! http://shop.oreilly.com/product/0636920034261.do iOS 8 Fundamentals! http://shop.oreilly.com/product/0636920034278.do RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
After some further testing, I think I can confirm that this is the case. Long story short, I would recommend against using TextMate to open any lengthy file that is programmatically updated on a frequent basis (e.g. a log file or compiler output file of some sort). TextMate may allocate huge memory resources to keep its display up-to-date. I can also confirm that if you manage to catch the runaway memory consumption before it locks up your whole system and close the offending file, the memory will be released. So it's not a memory leak in the conventional sense (i.e. where an application loses track of past allocations).
Ted
On Tue, Apr 14, 2015 at 7:28 PM, Edward K. Chew ekchew@gmail.com wrote:
Thanks. I was thinking there is another possibility too. The assembler I use generates a listing file. It's possible I might have had that open in TextMate when I ran the assembler again which would overwrite the open file. Could that lead to some kind of racing condition maybe? I'll take care not to do that from now on. Ted
On Apr 14, 2015, at 6:54 PM, Matt Neuburg matt@tidbits.com wrote:
A bad bundle can give you this sort of behavior. Typically the cause is an incorrect regular expression in the bundle's parser. m.
On Apr 14, 2015, at 1:32 PM, Edward K. Chew ekchew@gmail.com wrote:
I was running Activity Monitor and saw a memory usage spike. The application also became unresponsive, so I sampled it before doing a force quit.
-- matt neuburg, phd = http://www.apeth.net/matt/ pantes anthropoi tou eidenai oregontai phusei Programming iOS 8! http://shop.oreilly.com/product/0636920034261.do iOS 8 Fundamentals! http://shop.oreilly.com/product/0636920034278.do RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
On 15 Apr 2015, at 1:28, Edward K. Chew wrote:
Thanks. I was thinking there is another possibility too. The assembler I use generates a listing file. It's possible I might have had that open in TextMate when I ran the assembler again which would overwrite the open file. Could that lead to some kind of racing condition maybe?
It shouldn’t, but there could be an issue where a file is appended to/overwritten faster than TextMate can reload it (the file monitoring and reload is an area that I would like to improve upon).
As for potential memory leaks, the best way to measure this is to run “leaks TextMate” in a terminal; when TextMate allocates memory, it goes via malloc(3) that allocates pages from the OS and manages these. So the amount of memory allocated from the OS (shown in Activity Monitor) will be higher than actal malloc’ed memory, as it’ll be rounded up to full page sizes, and while TextMate may free memory totalling more than a page, it might not be possible to give back a page to the OS due to fragmentation or allocator implementation details.
Posted some diagnostics here:
http://geophysics.kos.net/~ted/misc/TextMateMemoryIssue.zip
The memory consumption went from maybe 170 MB for the files I had open at the time to over 1 GB in the time a new version of the file I had open was being written out by the assembler. This file itself is approximately 6 MB at its full length.
A few other things to note. The memory footprint does not increase if you are viewing the beginning of the file at the time of writing the new version. You need to be somewhere in the middle or end of it to see the effect. The memory allocation starts to grow -- sometimes quite rapidly -- as the new file contents are getting written, but nothing seems to get released after it's done. Closing the file in TextMate, however, will release the memory.
Anyway, I wouldn't get too worked up over this. I should just add some script function to my bundle that launches the assembler after closing the listing and reopens it again later. Hmm.... :)
Ted
On Apr 28, 2015, at 11:00 AM, Allan Odgaard mailinglist@textmate.org wrote:
On 15 Apr 2015, at 1:28, Edward K. Chew wrote:
Thanks. I was thinking there is another possibility too. The assembler I use generates a listing file. It's possible I might have had that open in TextMate when I ran the assembler again which would overwrite the open file. Could that lead to some kind of racing condition maybe?
It shouldn’t, but there could be an issue where a file is appended to/overwritten faster than TextMate can reload it (the file monitoring and reload is an area that I would like to improve upon).
As for potential memory leaks, the best way to measure this is to run “leaks TextMate” in a terminal; when TextMate allocates memory, it goes via malloc(3) that allocates pages from the OS and manages these. So the amount of memory allocated from the OS (shown in Activity Monitor) will be higher than actal malloc’ed memory, as it’ll be rounded up to full page sizes, and while TextMate may free memory totalling more than a page, it might not be possible to give back a page to the OS due to fragmentation or allocator implementation details.
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
-
Allan Odgaard -
Edward K. Chew -
Matt Neuburg -
Ted Chew