16-Bit error message

[Mel Bishop]

I was writing a test program in PB/DOS and I came up with the
following error.

[b]
16 bit MS-DOS Subsystem (title of the error box)

Command Prompt -..\pb filename
The NTVDM CPU has encountered an illegal instruction
CS:3246 IP:4F3A OP:63 94 68 94 71 Choose 'close.....'
[/b]

I have never seen this before. I F8 single stepped it and the
code segment that it bombed out on is:

open "somefile.dat" for binary as #1
for i = 1 to n
get$ #1,256,a$(i) '<-----It bombed out here on the 3rd loop
next i
close #1

Anybody know what's happening here?

Forgot to add: I'm using XP/pro.
------------------


[This message has been edited by Mel Bishop (edited April 29, 2003).]

[Michael Mattias]

An "illegal instruction error" is what occurs when you corrupt memory which <U>does</U> belong to your application. (Corruption of code segment; or corruption of the return address on your stack).

If you try to corrupt memory which does <U>not</U> belong to your application, you get a "page fault" error.

In other words, search the usual suspects: array bounds overrun/underrun, PEEK, POKE and PTR usage.

Your specific code? I'd double check the OPEN status by interrogating ERR immediately after the OPEN; and probably checj the LBOUND and UBOUND of that array before you enter the loop.

MCM



[This message has been edited by Michael Mattias (edited April 29, 2003).]

[Lance Edmonds]

To expand on Michaels answer slightly, lets review some array theory:

When you access any kind of array element, the runtime library looks up the element data by calculating the offset of the data from the base array address by multiplying the element number by the data size. The memory at that address is then considered to be the element data, provided the element is within the bounds of the array.

However, when boundary error testing ($ERROR BOUNDS ON or $ERROR ALL ON, etc) is not being used, then the target address of any given array element is not verified and is simply assumed to be valid.

At best this will simply cause a memory corruption at the target address if the array element is written to, or it might just return garbage if the array element is read. With memory corruption, the problem might not be discovered until later in the program when the "damaged" area of memory is being used by some other (and unrelated) portion of the program... this kind of bug can be very difficult to track down as it could be occurring anywhere in the program, not just where the symptom appears.

This is true for all data types, but the case of dynamic strings makes it a little more complex.

Importantly, dynamic strings use handles to "link" or point to the array element to the address/location of it's string data. Therefore, a dynamic string array is foremostly an array of string handles.

With this in mind, you'll see that if you try to reference an array element that is outside of the array boundary, the calculated element address will be read and assumed to be a valid string handle.

So if that handle is simply garbage or the data from some other variable in the program, what happens? All kinds of bizarre things are possible...

Firstly, the results will be totally unpredicable. At best you might read a garbage string if the handle just happened to point to an address in memory that is owned by your program, but at the worst case, it could damage other data or trigger an OS crash.

In summary, simply trying to read or write to any array outside of its boundaries can produce unexpected results, data corruption that wont be discovered until later in the program, and more often, spectacular app and/or OS crashes.

So how does this apply to Mel's code above? Since only a snippet of code was posted, we can only guess at the cause, but given than the app causes Windows to intercept memory access to a region of memory that it should not have done, the most likely cause is that the array was being accessed... yes you guessed it... outside of its boundaries!

Alternatively, there might be a data corruption elsewhere in the program that is damaging the string handle table, which is leading to a crash when the array is referenced in the code above.


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Michael Mattias]

True story:

Using a "competitive BASIC compiler for MS-DOS" I was getting a sporadic "string space corrupt" error which for the life of me I could not find for about two weeks. I spent a lot of time just trying to duplicate it.

I looked at all the usual suspects: array violations, POKE, some memory copies I had in there, VARSEG and VARPTR, STRSEG and STRPTR (hmm, youprobably know who the 'competitor' was now)...

Finally found the problem. Yes, the string space was corrupt, but it was corrupt because the STACK was corrupt. Why? I was passing the wrong number of parameters to an external (*.OBJ) module about 300 lines of code previously.

Lesson: When memory corruption occurs, the real error is not necessarily "right after the last line which executed correctly." Same is true of Windows.


MCM