Random out of memory exceptions

[ArneOrtlinghaus]

We have/had random out of memory exceptions when handling with bigger RTF-documents of about 30 MB in our program together with the TEControl for formatted text
One of the places for the exceptions was the transferring of the textcontrol contents to a string. Here the X#-function Mem2String is used which internally calls the function Memalloc for unmanaged memory. The reason may be a fragmentation of the memory or temporary limits of the 2 GB for 32-bit programs.
Based on the idea from Chris I have made the function mem2string_static as attached, that allocates only memory once and does not always allocate and de-allocate memory.
There is another function in our programs with random exceptions: a complex function RTFToText with many strtrans and string decompositions/compositions. Here I had also random exceptions in the Dotnet String-replace-functions called by strtran, although it is managed memory.
I think that the reasons are similar to the above errors. I believe that Dotnet does not directly call the GC if needed, because it runs as a separate thread, whereas in VO the GC may be called in every memory allocating function. The VO GC makes the program slow, but may save the program before reaching the limits. Here I have added an explicit calling of the garbage collector in case of big documents:
if slen(cRes) > 10_000_000
System.GC.Collect()
System.GC.WaitForPendingFinalizers()
end if
I tried also using the 3GB Large address aware changing of the exe file Wolfgang proposed for Win32 programs. But I had errors in the memory handling when exceeding 2 GB when using with Dotnet in contrast to Win32 where it works very well. On the other hand the X#-programs do not use so much space for the dlls/program code, so that the Dotnet programs in general have more reserves compared to Win32 programs.

[Terry]

Arne

Not sure if this has got anything to do with it, but your post immediately flags up the fact that you are converting things to strings.

Strings are immutable and will quickly fill up memory if not disposed of: a fact you have taken into account by calling the Garbage Collector explicitly.

I do wonder if enforcing Garbage Collection more frequently throughout the program, thereby preventing cumulative build-up, is possible?

Just a thought

Terry.

[Chris]

Hi Arne,

So ,after calling the GC manually, did those problems disappear entirely now?
Btw, is making your app comparable under AnyCPU/64bit mode totally out of the question? I know that you are using your own versions of GUI, DB etc classes, so at least those should not be a blocking problem.

[ArneOrtlinghaus]

> So ,after calling the GC manually, did those problems disappear entirely now?
Yes, calling the GC manually seems to resolve these errors.

> Btw, is making your app comparable under AnyCPU/64bit mode totally out of the question? I know that you are using your own versions of GUI, DB etc classes, so at least those should not be a blocking problem.
No, it is not totally out of question. We are already discussing that topic - should be quite a lot of work changing the GUI. We hope that there will AnyCPU-Classes for GUI/Browser from you or other programmers that we can use. But I believe that it will take 2 other years for us to be there.