Space violation mystery solved

Ever had this problem? If you haven't yet, you may in the future, so read carefully . . .

A procedure falls over with a space violation error, but no pointers to objects are being altered where the error occurs. The error is on an EVAL statement which looks like this:

Eval  g_ListEntryPtr =
      g_ListSpacePtr +
      g_ListOffset   -
      g_EntrySize    +
     (g_EntrySize * g_EntryNum)

g_ListSpacePtr is a space pointer addressing the start of a User Space, and the other terms are scalar (i.e. 'just numbers'). The receiving variable g_ListEntryPtr is another pointer variable, but it is not addressing anything. All variables are global (hence the 'g_' prefix) and may be referenced in other procedures in the same module (p_UsrSpc).

More Information

So, what is happening here for an error to occur?

In the EVAL statement, the value obtained after each term is evaluated will be stored in a compiler-supplied intermediate (working) variable.

The evaluation proceeds thus:

Step 1: Evaluate terms in parentheses

(g_EntrySize * g_EntryNum) = 1070 * 1 = 1070

(This result is stored in an internal compiler variable of scalar type.)

Step 2: Evaluate in order left to right

a) g_ListSpacePtr + g_ListOffset = [address] + 260 = [new address]

(This result is stored in an internal compiler variable of POINTER type.)

b) - g_EntrySize = [new address] – 1070 = [newer address]

(This result is stored in the SAME internal pointer variable as before.)

At this point the program fails, because when the compiler created the internal pointer variable, it created it so that it pointed to the object addressed by pointer g_ListSpacePtr. Since the internal variable's value is LESS THAN the value that is the actual base address of the object, the system determines that an address error (space violation) has taken place.

How do we get around this?

By re-arranging the arithmetic, we can prevent the address from being made effectively 'negative' with respect to the start of the addressed object:

Eval  g_ListEntryPtr =
      g_ListSpacePtr + 
      g_ListOffset   + 
     (g_EntrySize * g_EntryNum) -

As you see, the subtraction is now at the end of the set of terms and will be evaluated last. Another way would be to put ALL the non-pointer terms into parentheses so that the intermediate results would not be applied to the pointer variable until all their evaluations were complete:

Eval  g_ListEntryPtr =
      g_ListSpacePtr +
      ( g_ListOffset + (g_EntrySize * g_EntryNum) - g_EntrySize )

Of course, a better way would be for IBM to STOP allowing compiler-created internal variables to become involved in object addressing!

About the author: John Blenkinsop is a senior programmer at NYK Logistics & Megacarrier in London, and he is a site expert on Search400.com.

This was first published in November 2004

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.