Scott Hanselman

Strange but True...weird allocation problem with .NET?

July 11, '03 Comments [14] Posted in Web Services | Bugs
Sponsored By

From Patrick Hynds (repro in link above):

If you try to allocate an array with a size range between 0x027fefbd and 0x027fffec, the framework throws exceptions. This range corresponds to memory block of little under 40MB. But if allocate a buffer smaller than or larger than this range, then every thing is fine. So the following call will fail.

Byte[] test = new Byte[0x027ffc22];

It looks like there are different algorithms for big memory block allocation. Is there something special about this range?  Anyone?  Note: I'm running this on a box with 512megs.  Does this behave different on a box with more or less?

UPDATE: Until someone gives an good explaination, Dejan has added this to the .NET Bugs Registry...

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb
Friday, July 11, 2003 7:45:21 PM UTC
The same thing happens to me on my 512MB box. My first failure happens at 41943020 bytes:

Friday, July 11, 2003 7:49:17 PM UTC
Same failure here on a 2GB box, but the first error message was at 41943019 bytes.
Rob Walker
Friday, July 11, 2003 8:03:55 PM UTC
Not sure what it means, but task manager shows the following memory usage in each case....

Friday, July 11, 2003 8:06:44 PM UTC
Formatting got messed up there, sorry..
Friday, July 11, 2003 8:08:33 PM UTC
Look at the Virtual Memory Size (extra hidden column) in Task Manager...
Friday, July 11, 2003 8:15:22 PM UTC
Not only that but last I checked there was also a big in the large object heap that allocations over 8MB aren't freed. Don't know if this was fixed in 1.1. I seem to rememeber some indication when I asked that it wasn't.
Friday, July 11, 2003 8:19:36 PM UTC
Right...good to know. In this case though, you can just have one line:

Friday, July 11, 2003 8:46:24 PM UTC
In the test cases that do not produce an error (on either side of the range you provided), the VM size is ~45,000k. In the test cases that do produce an error, the VM size is ~465,000k.
Friday, July 11, 2003 9:13:55 PM UTC
Exactly...that is also reflected in the code when I grab the size of the process...it also seems that once whatever has gone wrong HAS gone wrong, you're screwed....I can't find a way to "reset it"...
Friday, July 11, 2003 9:13:59 PM UTC
Exactly...that is also reflected in the code when I grab the size of the process...it also seems that once whatever has gone wrong HAS gone wrong, you're screwed....I can't find a way to "reset it"...
Friday, July 11, 2003 9:14:04 PM UTC
Exactly...that is also reflected in the code when I grab the size of the process...it also seems that once whatever has gone wrong HAS gone wrong, you're screwed....I can't find a way to "reset it"...
Friday, July 11, 2003 9:14:19 PM UTC
3 posts? weird...
Tuesday, July 15, 2003 2:24:00 PM UTC
There is more memory holes:

Wednesday, October 13, 2004 4:13:49 PM UTC
Could not reproduce in .NET 1.1 SP1, looks like its fixed.
Mark
Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.