[EMAIL PROTECTED] wrote: > My array of 36 doubles is initialized at program start by writing a > valid value to each and every one of the 52 cells (Note that I wrote to > 52 cells, but the array was only 36 in size!) > > That worked fine and has done so for about a year! > Range Checking is off for speed purposes. I could turn it on, but may > forget to turn it off later, and I do need quite a lot of real-time > power elsewhere. > (The array in question is, on the other hand, only accessed once a > second or so.)
If you turn range checking on with the intention of later turning it off because it makes your program slow, but then you forget to turn it off, does it really make your program slow? Whatever speed change there was clearly wasn't bad enough to remind you to do something about it, after all. > The error occured at close down, however, NOT during writing to any > one of those 16 non-existing cells.. Yep. In the C and C++ worlds, it's formally known as undefined behavior. Writing to memory that doesn't belong to you can cause anything to happen, and it will still be considered something reasonable to expect from your program. You might get an exception. You might corrupt other data in your program. Your toilet might explode. Demons might fly out your nose. Or your program might appear to work exactly as you intended. And it doesn't have to be consistent, either. It might work today, and you might get nasal demons tomorrow. > Yes, the question is somewhat retoric now, that I have solved the > problem, but I (and others?) may still learn something from this. > Why do I not get an error during a write to an illegal memory > location, but only get it maybe hours later when I try to free up the > same (or some other?) location? > > I know, memory may be assigned in chunks of 4 kB at a time, which > could have something to do with it. Yes. The operating system, in combination with the CPU, is what triggers an exception when your program writes to memory that the OS has not given your program permission to write to. The Delphi memory manager allocates a large block of memory from the OS and the suballocates from that block when your program calls GetMem. As far as the OS is concerned, the entire block belongs to your program. The OS doesn't know anything about variables or arrays in your program, so it can't detect that your program has used a particular variable to write to memory that isn't allocated to that variable. Now, suppose the OS didn't allocate memory in 4 KB blocks, so it's no longer necessary for the Delphi memory to exist at all -- we can just allocate memory directly from the OS for exactly the number of bytes we need with no wasted space. You could _still_ run into the problem you're seeing. Just because you didn't allocate extra memory for the array doesn't mean the space won't be allocated to your program from some _other_ memory operation. You might have 288 bytes for that 36-element array of Double, and the next 128 bytes (for the "elements" between 36 and 52) might have already been allocated to something else, like a string. When you write to that memory, the OS does not and cannot know whether you're accessing it through the string or through the array variable -- it doesn't know the meaning of strings, variables, or arrays in your program. For all it knows, the array and string are _supposed_ to be adjacent to each other, and it's _supposed_ to be valid to use one to write to the other. -- Rob _______________________________________________ Delphi mailing list -> Delphi@elists.org http://www.elists.org/mailman/listinfo/delphi
