[linrad] Re: Memory leakage.

[Robert McGwier <comcast.net; rwmcgwier@xxxxxxxxxxxxxxxx>]

For those who have to move up with gcc as it is released,   in order to 
compile lir206a  (xlinrad),  you must remove the following command line 
argument from the Makefile (after you run configure).

-fforce-mem

which is intended to force any operands for an operation into a register 
before manipulating it numerically or bitwise.    This is deprecated in 
gcc and while the man page claims it will just be a NOP until gcc 4.2,  
it in fact generates an error and causes xlinrad make to fail with gcc 4.1.0

With the removal of -fforce-mem , I have xlinrad lir0206a running. 

I did not run as root.  On the other hand,  I have

chmod a+rwx

on the parallel port device.  However, to do real-time or other than 
default thread scheduling and prioritization (which is much more 
important),  root privileges or "wheel" privileges are needed so now I 
will  run

sudo xlinrad

my linrad user is in the "wheel" group and in /etc/sudoers so this 
starts xlinrad with root privileges.  I fear logging in as root.  Anyone 
who has done as much damage as I have with root as my login will no 
why.  Just a couple of weeks ago I managed to rm everything in 
/usr/bin.  Believe it or not I managed to recover without having to 
reboot.  Running SUSE on that laptop and having a local image of the 
install DVD,  I told it to force reload all packages.   An hour later, 
things were back to normal after one Yast update.  My advice: do not log 
in as root if you can run sudo.

On valgrind,  a warning.  If you have memory allocated and for whatever 
programmatic or operational reason  you have not yet visited that memory 
yet,  valgrind can mark it as a POTENTIAL memory leak on exit.  I do not 
heed these warnings until they lead some place useful as in faulty 
operation, segment violations, or I can prove positively I have a memory 
leak.  A clue that xlinrad has array bounds issues and not necessarily 
memory leaks could be gleaned from the memory not increasing steadily as 
the program runs.  If the program steadily increases in memory allocated 
from the heap, this may be viewed easily by running

top


where you may view the running processes.  I recently found a nasty leak 
in wxPython by running gnuradio under top and watching its allocated 
memory grow linearly for hours from 1 MB to 60 MB.  I ran the non-gui 
version of the same thing and the memory did not increase (I use this as 
an example of how this might be done).

For looking for violations of array bounds,  I also use electric 
fence.   Authored by the quite famous Bruce Perens,  it is an invaluable 
tool.  Many of your systems will have electric fence on it already.

man efence

Otherwise you may get it here:

http://perens.com/FreeSoftware/ElectricFence/

a fork of it that many like is called DUMA and has a sourceforge page here:

http://duma.sourceforge.net/


Bob

--
AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats,
NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman
Laziness is the number one inspiration for ingenuity.  Guilty as charged!


#############################################################
This message is sent to you because you are subscribed to
 the mailing list <linrad@xxxxxxxxxxxxxxxxxxxxx>.
To unsubscribe, E-mail to: <linrad-off@xxxxxxxxxxxxxxxxxxxxx>
To switch to the DIGEST mode, E-mail to <linrad-digest@xxxxxxxxxxxxxxxxxxxxx>
To switch to the INDEX mode, E-mail to <linrad-index@xxxxxxxxxxxxxxxxxxxxx>
Send administrative queries to  <linrad-request@xxxxxxxxxxxxxxxxxxxxx>


LINRADDARNIL