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