Hi Jim,
... A
phenomenon known as "memory leak" can happen when one program module does
not manage its memory spaces well and inadvertently writes data on top of
other data as I have described. No, the memory isn't actually leaking, but
the programmer "leaked" data where it shouldn't be. When signal data is
used to calculate indices, or when processed spectral data is similarly
used, as it probably is in the Orion DSP, then you can easily overwrite data
where you shouldn't.
A memory leak refers to a condition caused by the dynamic allocation of
memory resources on the "heap" which are then not released and returned
to the free list after use. Over time memory gets used up until there is
none left to be allocated to a request for a new block of data storage.
There are automated ways to test for this condition, but programmers
under deadline pressure often fail to run the available tools. It always
comes back to bite on the ass after first irritating their customers.
The fact that C in particular uses an indexing base of 0 and does not
check array bounds results in many programming errors that can go
undetected until a critical moment in the heat of battle. The usual
result is data corruption when nearby memory locations are overwritten
in the program's data space. Program code corruption is not likely
because code space is usually protected in modern operating system
environments. Even in microcontrollers running programs in unhosted
environments there are means of protecting code space. (I develop
firmware for security systems using C on PIC and other
microcontroller-based remote systems and have dealt with these issues in
my designs.)
An overflow condition occurs when a register or other memory location is
used to store a value that gets incremented or set to a value that
exceeds its ability to correctly represent the value. No harm is done to
nearby memory locations when the overflow occurs. However, the value no
longer represents the data correctly and any attempt to use or display
the value will produce erroneous results.
Another possible programming error is overflowing the stack. Function
calls and calculations use the stack for saving/recalling state, passing
parameters, and for temporary local data storage. Microcontrollers
typically have small fixed stack allocations that can be easily overrun.
Again, there are techniques for testing this condition that are too
often neglected when new features are added or when existing procedures
are modified to correct bugs or enhance behavior.
Now to the Ten-Tec content. I don't know what programming tools the TT
folks are using, but the symptoms that have been described in this and
related threads lead me to believe that either an indexing error or a
data overflow is the likely culprit. Simply turning the sweep off and on
might reinitialize memory locations, but would likely not recover
unreleased dynamic memory.
I'm confident that a simple solution to this problem will be found soon.
Gus Hansen
KB0YH
|