0

I'm getting a very strange behaviour in my application resulting in OutOfMemoryException. I din't find any clue in the several other posts I found on this matter (e.g., 1, 2, 3).

I have my app compiled in 64bit, my system has 16GB ram and when doing the following tests I had always around 8-10GB of free memory.

I have a version of this app (A) that works perfectly and allocates regularly a total of 5GB of data. Then in the last weeks I've worked to a new version (B). When I try to run or to debug version B, I consistently get OutOfMemoryException every time my process (or the host one) is about to exceed 2GB.

Please note that I'm not using a single object larger than 2GB (even if I've tried also to include gcAllowVeryLargeObjects in app.config).

The most notably difference with respect to memory usage is that version B allocates in a row a quite large number of List[] arrays (here is where I get the exception). More precisely:

List<T>[] lists = new List<T>[N];
for (int i = 0; i < n; i++)
    lists [i] = new List<T>(S);

With: 

N=16k
S~=20k
typeof(T)=Int64

This means that I'm allocating about 16k arrays, each one of 160KB (total 2.5GB ram). So initially I thought that maybe the problem was memory fragmentation and that it was not possible to find 16k holes of 160KB contiguous memory each. But what is not clear at all to me is that on Task Manager my process never exceed 2GB when there are still 6GB or more of free memory. Can be the memory so fragmented? Can someone explain this?

UPDATE

I found another block of ram and now my system has 20GB. I do not get anymore the problem. The total memory taken by my process is 4GB. Still I do not understand what I was observing before with 16GB installed memory and with my process not exceeding 2GB...

UPDATE 2

I went back to 16GB of ram and I do not have the OutOfMemoryException. I do not think the installed memory was the problem. Between the installation of memory I went into the Project > Build properties to check the target Platform (see comments from Hans Passant). I verified the platform was x64 and I never changed this. I have the sensation that VS was targeting in 32bit for some reason or bug and that by going to the settings, the correct platform is now targeted. All the story is still obscure to me, but this is the only thing I'm able to guess.

Mauro Ganswer
  • 1,379
  • 1
  • 19
  • 33
  • Sounds like 32 bit process to me.. can you [check it](https://superuser.com/q/85054/547545) ? – Sinatr May 24 '17 at 11:47
  • 1
    Does that only happen when you run the application through VS? It could be the VS process (which in my case I've never seen a x64 version) – Camilo Terevinto May 24 '17 at 11:48
  • The traditional mistake is to pay too much attention to the solution platform name. In a C# project, the only setting that matters is the jitter forcing on the EXE project. Right-click > Properties > Build tab. Double check with Task Manager, Processes tab. Add the "Platform" column. – Hans Passant May 24 '17 at 11:53
  • @HansPassant Platform target on Properties > Build is x64 – Mauro Ganswer May 24 '17 at 11:55
  • 1
    That is exactly what I meant, that setting is irrelevant for C# projects. It does not use special tooling to produce a x64 build, only C++ projects care about that. Do what I recommended instead. In the property page ensure that Platform target = AnyCPU and the "Prefer 32-bit" checkbox is unchecked. – Hans Passant May 24 '17 at 12:00
  • @HansPassant I think your idea helped. See my last update – Mauro Ganswer May 24 '17 at 12:11

0 Answers0