Scott Hanselman

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

July 11, 2003 Comment on this post [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
Hosting By
Hosted in an Azure App Service
July 11, 2003 19:45
The same thing happens to me on my 512MB box. My first failure happens at 41943020 bytes:

July 11, 2003 19:49
Same failure here on a 2GB box, but the first error message was at 41943019 bytes.
July 11, 2003 20:03
Not sure what it means, but task manager shows the following memory usage in each case....

July 11, 2003 20:06
Formatting got messed up there, sorry..
July 11, 2003 20:08
Look at the Virtual Memory Size (extra hidden column) in Task Manager...
July 11, 2003 20:15
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.
July 11, 2003 20:19
Right...good to know. In this case though, you can just have one line:

July 11, 2003 20:46
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.
July 11, 2003 21:13
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"...
July 11, 2003 21:13
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"...
July 11, 2003 21:14
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"...
July 11, 2003 21:14
3 posts? weird...
July 15, 2003 14:24
There is more memory holes:

October 13, 2004 16:13
Could not reproduce in .NET 1.1 SP1, looks like its fixed.

Comments are closed.

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