VirtualBox

Opened 15 years ago

Closed 15 years ago

#3510 closed defect (fixed)

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

Reported by: Terry Ellison Owned by:
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 (4)

comment:1 by Frank Mehnert, 15 years ago

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 by Terry Ellison, 15 years ago

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 by Terry Ellison, 15 years ago

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 by Klaus Espenlaub, 15 years ago

Resolution: fixed
Status: newclosed
Summary: Out of memory allocating the partition descriptorOut 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.

© 2023 Oracle
ContactPrivacy policyTerms of Use