- Joined
- May 26, 2007
- Messages
- 5,545
- Reaction score
- 1,315
I doubt that the "read" operation which caused the exception will be the instruction at fault, or even anything you would change.
These kind of crashes are usually what old Basic interpreters would report as "Array index out of bounds". I C terms it's like you allocated an array of char[16] and tried to read, either the -1th element or the 17th element.
Commonly catastrophic is when you have a loop which reads from 0FE00 to 0FF00, and you modify the WHILE loop_count < &h0FF0 to WHILE loop_count > &h0FF0 or such, causing the loop to never end.
It's often that you miscalculate the size of an array element, and your new size can be as little as 1 byte more or less if the terminator is a != (cmp EBX,EndElement : JNZ LoopStart) and the error will present.
The Kernel doesn't actually catch this as an "exception" until you have not only passed the array (table) you where trying to read, but proceeded through all other possible memory allocated to your program, and reach an address which does not belong to your program. (unallocated address, or reserved for the system)
It also happens when you mismatch POP and PUSH statements in the machine code. When you try to POP from an empty stack, or PUSH when the stack has already filled the memory the RTL has allocated for it, bad things happen. (it's another read, or write to illegal memory address)
Address 0x664 seems very, very low in memory to me. I'm not sure what you could do to produce that. :/: You can't loop around from 0xffffffff because address 0x0 is always reserved.
These kind of crashes are usually what old Basic interpreters would report as "Array index out of bounds". I C terms it's like you allocated an array of char[16] and tried to read, either the -1th element or the 17th element.
Commonly catastrophic is when you have a loop which reads from 0FE00 to 0FF00, and you modify the WHILE loop_count < &h0FF0 to WHILE loop_count > &h0FF0 or such, causing the loop to never end.
It's often that you miscalculate the size of an array element, and your new size can be as little as 1 byte more or less if the terminator is a != (cmp EBX,EndElement : JNZ LoopStart) and the error will present.
The Kernel doesn't actually catch this as an "exception" until you have not only passed the array (table) you where trying to read, but proceeded through all other possible memory allocated to your program, and reach an address which does not belong to your program. (unallocated address, or reserved for the system)
It also happens when you mismatch POP and PUSH statements in the machine code. When you try to POP from an empty stack, or PUSH when the stack has already filled the memory the RTL has allocated for it, bad things happen. (it's another read, or write to illegal memory address)
Address 0x664 seems very, very low in memory to me. I'm not sure what you could do to produce that. :/: You can't loop around from 0xffffffff because address 0x0 is always reserved.
I've mixed and matched languages a lot in this post. That's to try and make it obvious what this crash is all about for everyone who understands program code, regardless of the language background they come from.
It's *very* common, even in unmodified programs, because of the large amounts of data programs hold in memory and the dynamic way they access it with techniques like OOP and 4GLs. It's impossible for the compiler to spot this error when the program is built, and very hard for programmers to see the potential for it.
It's *very* common, even in unmodified programs, because of the large amounts of data programs hold in memory and the dynamic way they access it with techniques like OOP and 4GLs. It's impossible for the compiler to spot this error when the program is built, and very hard for programmers to see the potential for it.
Last edited: