VirtualBox

Ticket #3510 (closed defect: fixed)

Opened 5 years ago

Last modified 5 years ago

Out of memory allocating the partition descriptor => fixed in svn

Reported by: TerryE Owned by:
Priority: major Component: virtual disk
Version: VirtualBox 2.1.4 Keywords:
Cc: Guest type: other
Host type: other

Description

 Forum Topic #14342 refers.

A couple of people have reported this error which seems to relate to a logic flaw in VBoxInternalManage.cpp routine CmdCreateRawVMDK. Looking at the code (search for the title to this report), this is in a loop which is checking that the partition is readable. The way it seems to do this is to malloc ...cPartDataSectors * 512 (that is the size of the entire partition and then reads the entire partition into into this buffer). Needless to say this will barf for anything other than small partition and result this error.

The confusing thing is that the field cPartDataSectors isn't what it's name implies. It is only computed in in the case of extended partitions, meaning that you will only get this error when trying to map logical partitions. This whole logic is definitely flawed.

Change History

comment:1 Changed 5 years ago by frank

You misunderstood the code. cPartDataSectors is not the number of sectors of the entire partition but the number of sectors of the partition table. Which is the area before the actual partition starts. A partition table usually starts at sector 1, and a partition usually starts at sector 1 as well. So, for example, if the hard disk has logically 240 heads, 63 sectors and 12921 cylinders, the MBR starts at CHS 0/0/1 but the actual partition starts at CHS 0/1/1 which is 63 sectors later. So in this case, cPartDataSectors is 63. Of course, the actual partition table will only occupy one sector and the remaining 62 sectors are reserved.

The question is why for the original reporters in the forum cPartDataSectors is apparently very big.

comment:2 Changed 5 years ago by TerryE

Frank, sorry but I think that we were both wrong. I agree that cPartDataSectors is computed from the EBRrecord.entry.size which defines the offset of the start of the extended partition relative to the EBRrecord itself. AFAIK, nowhere in any EBR definition (see [ http://en.wikipedia.org/wiki/Extended_Boot_Record EBR Descriptor for example) does it state that you can assume that this value will be small (e.g. less than a track).

Look at the two Partition listings in the reference topic. In both cases LP5 follows LP6. This can validly occur where you've been deleting and recreating extended partitions. Yet the EBR for LP5 is always at sector 0 of the Extended Partition, and hence this offset can validly be very large (73 and 143 Gbs respectively in these two examples).

Given that only the first 512 byte EBR record itself is used, I am also at a loss as to why you would want to allocate memory for and read into memory a chunk of dead disk space that could be tens of Gbytes long.

comment:3 Changed 5 years ago by TerryE

One of the reporters and I have updated the topic  Out of memory allocating the partition descriptor. This contains some useful data to support my previous analysis. Hope that this helps :-)

comment:4 Changed 5 years ago by klaus

  • Status changed from new to closed
  • Resolution set to fixed
  • Summary changed from Out of memory allocating the partition descriptor to Out of memory allocating the partition descriptor => fixed in svn

Finally found time to hunt this down. It indeed was a wrong assumption. Will be in the next release.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use