Scott Hanselman

browse by category or date

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
Comment on this post [14]
Share on Twitter or Facebook or use the
July 11, 2003 23:45
The same thing happens to me on my 512MB box. My first failure happens at 41943020 bytes:

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

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

Scott Hanselman
July 12, 2003 0: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.
Drew Robbins
July 12, 2003 1: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"...
Scott Hanselman
July 12, 2003 1: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"...
Scott Hanselman
July 12, 2003 1: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"...
Scott Hanselman
July 12, 2003 1:14
3 posts? weird...
Scott Hanselman
July 15, 2003 18:24
There is more memory holes:

Slobodan Filipovic
October 13, 2004 20:13
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.