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, 11 July 2003 19:45:21 UTC
The same thing happens to me on my 512MB box. My first failure happens at 41943020 bytes:

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

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

Friday, 11 July 2003 20:46:24 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, 11 July 2003 21:13:55 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, 11 July 2003 21:13:59 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, 11 July 2003 21:14:04 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, 11 July 2003 21:14:19 UTC
3 posts? weird...
Tuesday, 15 July 2003 14:24:00 UTC
There is more memory holes:

Wednesday, 13 October 2004 16:13:49 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.