Hi Jonas, > First of all, you set the global system unit variable > 'ReturnNilIfGrowHeapFails' to true, so that instead of a run time > error (or exception) you will simply get nil if a memory allocation > fails. This is a very good tip! I have read about 'ReturnNilIfGrowHeapFails' but I forget it. I think, it is a good solution for my problem.
> Secondly, not being able to allocate an array of 2GB is unrelated to > FPC, but due to the fact that you are (most likely) working on a 32 > bit OS. While the theoretical maximum limit for 32 bit systems is 4GB, > it is impossible to ever allocate that much memory in a s single block. Yes, it finally sunk in. I see clearlier the context of memomry management. Thanks. > The reason is that while your program runs in its own virtual memory > space, it is not the only thing in that space. The kernel usually > takes part of the memory (512MB to 1GB), your program code, data and > stack take part of it (and not contiguously; e.g., the code and data > usually start somewhere around address 0x804000, while the stack > starts at 0xC0000000 and grows downwards from there), and then there > are shared libraries which can be mapped all over the place. Ok, thats new for me. It is very interesting. > As a result, the virtual memory space is fragmented already right > after your program starts, and on most 32 bit systems you seldom can > allocate more than 1.5GB of contiguous memory (simply because other > things are in the way otherwise), and sometimes even less. My experience with the topic coincides with your sentences. Finally, I think i understand some thinks better. Including with your first very good tip, I can fix the problem. Thank you, Jonas, for your help. Also Thank's to Marco. Bye, Markus _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal