TenTec
[Top] [All Lists]

Re: [TenTec] NEW Orion II/2.041XL Bug? RedScanWith VerticalLinePatterns

To: Discussion of Ten-Tec Equipment <tentec@contesting.com>
Subject: Re: [TenTec] NEW Orion II/2.041XL Bug? RedScanWith VerticalLinePatterns
From: Augie Hansen <augie.hansen@comcast.net>
Reply-to: Discussion of Ten-Tec Equipment <tentec@contesting.com>
Date: Mon, 09 Mar 2009 18:24:13 -0600
List-post: <tentec@contesting.com">mailto:tentec@contesting.com>
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



_______________________________________________
TenTec mailing list
TenTec@contesting.com
http://lists.contesting.com/mailman/listinfo/tentec

<Prev in Thread] Current Thread [Next in Thread>