Microsoft KB Archive/100175

From BetaArchive Wiki

ACC1x: GP Fault When Allocating Huge Arrays


The information in this article applies to:

  • Microsoft Access versions 1.0, 1.1


When you try to allocate a huge array, you may receive a general protection (GP) fault. The following error message appears:

An error has occurred in your application. If you choose Ignore, you should save your work in a new file. If you choose Close, your application will terminate.


If you have allocated an array element that includes a string or variant data type and the size of the array exceeds 64K, you may receive the error message described above, if the following criteria are met:

  • The array must be huge and span two or more data segments.
  • Each array element must contain at least one dynamic string or variant.
  • The number and size of the array elements must cause the last segment of data to be exactly the same size as the first segment of data.


Declare the array so that the last data segment contains a different number of elements from the first data segment.


Microsoft has confirmed this to be a problem in Microsoft Access versions 1.0 and 1.1. This problem no longer occurs in Microsoft Access version 2.0.


Access Basic has the ability to define huge arrays, larger than the normal 64K data segment. Any element or index of a huge array may not extend across the 64K-segment boundary. If all elements of the array cannot be allocated within the 64K segment, only the elements of the array that fit evenly in the segment are allocated. Microsoft Access then allocates another 64K segment to the array and continues to fill the new segment with the remaining elements.

If the size of the data type defined in the array is a power of 2, the 64K segment is completely full. If the size is not a power of 2, the segment contains wasted space, since Microsoft Access cannot place a portion of one element in one segment and the rest of that element in the next segment.


   Type Foosball

      A(3000) As double
      d As String

   End Type 

The size of this structure is 24,012 bytes (3000 * 8 bytes/double + 12 bytes/string). If you declare this array with three elements, you have two data segments, as follows:

   Data Segment  #1      Data Segment  #2
   -----------------     -----------------
   Free space 17512      Free space 41524
   Array(1)   24012      Array(3)   24012
   Array(2)   24012 

In Microsoft Access, you may receive a GP fault if the number of elements in the first segment is equal to the number of elements in the last segment and the data structure used to define the array is made up of either a string or variant data type. If you define the data structure above with six elements, your memory map looks like the following:

   Data Segment  #1      Data Segment  #2        Data Segment  #3
   -----------------     -----------------       -----------------
   Free space 17512      Free space 17512        Free space 17512
   Array(1)   24012      Array(3)   24012        Array(5)   24012
   Array(2)   24012      Array(4)   24012        Array(6)   24012 

The actual dimension statement looks like the following:

   Function Sample()
      Redim Array(6) As Foosball
   End Function 

To work around this problem, declare the array so that the last data segment does not contain the same number of elements as the first data segment. In addition to the example above, you may choose to define the array with seven elements instead of six. This causes Microsoft Access to allocate four data segments, in which the first data segment contains two elements of the array and the last data segment contains only one element.

This example is very easy to duplicate with large data structures, but is more difficult to duplicate with smaller data structures. With an element size of 24,012 bytes, 4, 6, or 8 elements may cause a problem. With a data size of 1K, numbers of elements that duplicate this problem are 128, 192, 256, and so forth.

Additional query words: GP fault GPF array

Keywords : kbprg
Issue type : kbbug
Technology :

Last Reviewed: November 4, 2000
© 2001 Microsoft Corporation. All rights reserved. Terms of Use.