[Mono-bugs] [Bug 70992][Blo] Changed - Segment fault instead of OutOfMemoryException
Sun, 9 Jan 2005 12:28:14 -0500 (EST)
Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.
Changed by email@example.com.
--- shadow/70992 2005-01-08 12:40:24.000000000 -0500
+++ shadow/70992.tmp.16166 2005-01-09 12:28:14.000000000 -0500
@@ -93,6 +93,23 @@
I meant to ask whenever you are using a 32 bit OS on an amd64 cpu, or
a 64 bit OS ?
------- Additional Comments From firstname.lastname@example.org 2005-01-08 12:40 -------
I am using a 64bit OS (I have checked that I am able to allocate more
than 2Gb in a C program, and IntPtr.Size == 8).
+------- Additional Comments From email@example.com 2005-01-09 12:28 -------
+Note: the spec doesn't give the Uint32.MaxValue limit: the limit is
+based on a intptr. Mono currently uses a uint32 even on 64 bit
+architectures: we need to fix that.
+Then, there is also the practical limit: most C# code uses int to
+index into the array, so that code would break:-(.
+The issue could be easily solved if IntPtr/UIntPtr were useful types
+in C#. So, in practice, you want the arrays you use to be limited to
+Int32.MaxValue in length.
+That said, 266000000*4 is lower than that and it should work on 64 bit
+architectures (on 32 bit archs it depends on the memory layout setup
+by the operating system for malloc and mmap space).
+So if the app was running in 64 bit mode with a 64 bit mono, it's
+likely a libgc or mono bug: it should work just fine with 2 GB of RAM,
+unless you have tons of other programs running and overcommit disabled
+and no swap etc.