Bug 51677 - OOM crash System.OutOfMemoryException different behaviour on linux vs windows for 64-bit process?
Summary: OOM crash System.OutOfMemoryException different behaviour on linux vs windows...
Status: RESOLVED DUPLICATE of bug 52437
Alias: None
Product: Runtime
Classification: Mono
Component: GC (show other bugs)
Version: 4.4.2 (C7SR1)
Hardware: PC Linux
: --- normal
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2017-01-20 23:40 UTC by Albert
Modified: 2017-02-28 15:32 UTC (History)
3 users (show)

See Also:
Tags:
Is this bug a regression?: ---
Last known good build:


Attachments

Description Albert 2017-01-20 23:40:41 UTC
I am having oom issues on linux/mono that i dont get on windows/net. I have created this console sample app to oom.

I run it in two 4GB VMs ( linux and windows )

If i compile as 32-bit and run it in 1-2 seconds i get OOM in both windows and linux although i have free memory i guess because is hitting 1,2GB limit process.

If i compile as 64-bit and run it in 1 second i get OOM in linux even there is free/cached memory and swap file unused (0).

In windows it just runs for lot more time 40-50secs and even when memory get to 100% it doesnt crash and starts to use cached by other programs and pagefile.

Why mono/linux cant use free memory/cached memory/swap in same way?

    class Program
    {
        static void Main(string[] args)
        {
            List<byte[]> test = new List<byte[]>();

            for (int i = 0; i < int.MaxValue; i++)
            {
                Console.Write(".");
                test.Add(new byte[10000]);
            }
        }
    }
Comment 1 Albert 2017-01-21 01:36:21 UTC
I have modified to use this to have time to monitor process on top:

            for (int i = 0; i < int.MaxValue; i++)
            {
                Thread.Sleep(10);
                Console.Write(".");
                test.Add(new byte[100000]);
            }


I run several times and I see process start growing memory but between 300-600MB it crash with oom, never goes more than that and as you see there is plenty of free memory.

[root@linux ~]# free -m
             total       used       free     shared    buffers     cached
Mem:          7872       6334       1538          0        261       4103
-/+ buffers/cache:       1968       5903
Swap:         2047          0       2047
Comment 2 Albert 2017-01-21 01:36:55 UTC
Output error is:

OutOfMemoryException
[ERROR] FATAL UNHANDLED EXCEPTION: System.OutOfMemoryException: Out of memory
  at (wrapper managed-to-native) System.Object:__icall_wrapper_mono_gc_alloc_vector (intptr,intptr,intptr)
  at (wrapper alloc) System.Object:AllocVector (intptr,intptr)
  at outofmem.Program.Main (System.String[] args) <0x40010df0 + 0x00073> in <filename unknown>:0
Comment 3 Vlad Brezae 2017-02-01 00:40:50 UTC
I can't help you here. This is not a mono issue. A memory related mono bug would be if memory leaks, or the amount of memory is considerably higher than it should be.

Swap is controlled by the operating system and is abstracted away from the application layer. On our end we just request memory from the OS and if the OS doesn't want to give it to us for whatever reason, there is nothing that we can do here.

I also ran your testcase on 2 ubuntu's and on a windows and in all situations memory is allocated all the way, until performance degrades and os is slowly allocating from swap, without crashing.

I suggest reproducing this issue outside mono, allocating memory in C using mmap, and passing the problem to linux guys if you are confident that you have unused memory.
Comment 4 Albert 2017-02-24 14:03:38 UTC
I tested on mono 4.8 with 32-bit or 64-bit the error s different and doesnt say out of memory. I think mono 4.4 error is more clear. this error is very difficult to know that is because out of memory!


Unhandled Exception:
System.ArgumentNullException: Value cannot be null.
Parameter name: destinationArray
  at System.Array.Copy (System.Array sourceArray, System.Int32 sourceIndex, System.Array destinationArray, System.Int32 destinationIndex, System.Int32 length) [0x00017] in <373b6e083d6e45e498c9082a8eebd27f>:0
  at System.Collections.Generic.List`1[T].set_Capacity (System.Int32 value) [0x0003d] in <373b6e083d6e45e498c9082a8eebd27f>:0
  at System.Collections.Generic.List`1[T].EnsureCapacity (System.Int32 min) [0x00046] in <373b6e083d6e45e498c9082a8eebd27f>:0
  at System.Collections.Generic.List`1[T].Add (T item) [0x00013] in <373b6e083d6e45e498c9082a8eebd27f>:0
  at outofmem.Program.Main (System.String[] args) [0x0001f] in <70597d68bd6143fba0965ef0ce60e392>:0
[ERROR] FATAL UNHANDLED EXCEPTION: System.ArgumentNullException: Value cannot be null.
Parameter name: destinationArray
  at System.Array.Copy (System.Array sourceArray, System.Int32 sourceIndex, System.Array destinationArray, System.Int32 destinationIndex, System.Int32 length) [0x00017] in <373b6e083d6e45e498c9082a8eebd27f>:0
  at System.Collections.Generic.List`1[T].set_Capacity (System.Int32 value) [0x0003d] in <373b6e083d6e45e498c9082a8eebd27f>:0
  at System.Collections.Generic.List`1[T].EnsureCapacity (System.Int32 min) [0x00046] in <373b6e083d6e45e498c9082a8eebd27f>:0
  at System.Collections.Generic.List`1[T].Add (T item) [0x00013] in <373b6e083d6e45e498c9082a8eebd27f>:0
  at outofmem.Program.Main (System.String[] args) [0x0001f] in <70597d68bd6143fba0965ef0ce60e392>:0
Comment 5 Albert 2017-02-24 14:51:48 UTC
after discussing on gitter, @akoeplinger asked me to reopen because oom error  should be printed on mono 4.8 also.
Comment 6 Vlad Brezae 2017-02-28 13:43:43 UTC
Hello Albert,

  Thanks for the report. This was fixed on master and it is currently in the process of being backported to 4.8. You can follow the progress on bug #52437.

*** This bug has been marked as a duplicate of bug 52437 ***
Comment 7 Albert 2017-02-28 15:32:35 UTC
Thanks Vlad

Note You need to log in before you can comment on or make changes to this bug.