You’re hitting the process’ memory limit when building such a gigantic string. Also, if you’re trying to concatenate many strings together efficiently, I’d recommend using an array that holds each item to be concatenated and using Join at the end.
Right - but I cant trap the error. Thats the point. It just crashes. (see sample project)
I know its a dumb thing to do, but Id think an exception should be raised. I actually discovered this trying to write an example of a WRONG way to do things.
It seems to me that if your app has gobbled up all the available memory then there is no memory available to do anything else within that app other than to crash.
When things die unceremoniously in the C++ your app is in a state that catching the error quite literally isn’t possible as that would require memory & you’re process has none to allocate
So what youre saying is that I should have read the Notes for the OutOfMemoryException :P.
This exception is mostly useful with MemoryBlock and Picture when attempting to allocate large blocks of memory that would exceed the remaining available memory.
Low-level memory situations are inherently problematic, especially if you are frequently requesting small blocks of memory (using MemoryBlock or Picture). Because of this, there is no guarantee that an OutOfMemoryException can even be raised. If the system memory has gotten critically low, the process itself may crash as it attempts to reserve memory in order to display an exception message.
In this situation, you might consider reserving a large block of memory up front and using that within your application rather than repeatedly requesting smaller blocks.
I’ve got a couple of Feedback reports on this topic, too. Parsing an email requires multiple slicing and dicing. Works quite well with a 10 MB email. But a 300 MB email made my application crash very quickly. This is one reason why I really want 64bit apps.
@Christian: you are so totally funny. Do you want to tell that to my customers? And with Yosemite coming I’ll need to be prepared for GB of attachments.
This discussion about an app that crashes silently because it has exhausted all memory resources prompt me to ask : is there any way in Xojo to know the amount of memory still available to the app ? Knowing that would allow stopping operations before rabbits have filled all cages.
There is a range when low-memory crashes happen. The problem is when to check. Take the string appending for instance. Do you want to check before every string is appended for free memory? Not a good idea for fast algorithms.
When moving data to Filemaker via AppleScript I have a memory leak in Filemaker. I monitor Filemaker’s memory and simply restart Filemaker when the memory gets over a threshhold. But I have it easy there because this is only one routine, which is responsible for managing the data transfer.
[quote=99376:@Beatrix Willius]There is a range when low-memory crashes happen. The problem is when to check. Take the string appending for instance. Do you want to check before every string is appended for free memory? Not a good idea for fast algorithms.
When moving data to Filemaker via AppleScript I have a memory leak in Filemaker. I monitor Filemaker’s memory and simply restart Filemaker when the memory gets over a threshhold. But I have it easy there because this is only one routine, which is responsible for managing the data transfer.[/quote]
As for when to check, I would believe that it is better to check the threshold before the append, as when memory is maxed, nothing is left to check anything. The crash has already occurred and code will not execute.
