Re: [Tlf-devel] Possible memory leak

[Thomas Beierlein]

Hi Nate, 

thanks for the report.

Am Sat, 23 Jan 2016 09:12:25 -0600
schrieb Nate Bargmann <address@hidden>:

> I may have found a memory leak in Tlf.  I have noticed that since
> enabling the cluster for testing that if I left Tlf run overnight that
> by morning the Hamlib TRX line would be reporting 0.0 and there would
> be no more spots in the bandmap.  I chose to run Tlf under valgrind
> last night and this is what it reported:
> 
I did a check of the code in question. As I see it, what you found is
no memory leak. But it is wrong anyway. Good catch.

The code just copies the back part of a buffer to the front (just as
some kind of FIFO) after the front part has been copied out and
delivered to another buffer.

No memory will leak and no other data structures will be damaged. But
the moved data can be garbage afterwards.

The empty bandmap can happen if for some reasons the connection to
the net goes down (maybe in result of the problem you found). That
leaves still the question why you observed problems with the rig
connection. Please have an eye on that.

> ==31899== Memcheck, a memory error detector
> ==31899== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et
> al. ==31899== Using Valgrind-3.10.0 and LibVEX; rerun with -h for
> copyright info ==31899== Command: /home/nate/local/bin/tlf
> ==31899==
> ==31899== Thread 2:
> ==31899== Source and destination overlap in memcpy(0xb9ce2a0,
> 0xb9ce39f, 256) ==31899==    at 0x4C2D75D: memcpy@@GLIBC_2.14
> (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==31899==
> by 0x43958B: recvline (sockserv.c:415) ==31899==    by 0x43CD4F:
> receive_packet (splitscreen.c:1221) ==31899==    by 0x4098DE:
> background_process (background_process.c:100) ==31899==    by
> 0x65E20A3: start_thread (pthread_create.c:309) ==31899==    by
> 0x68DD04C: clone (clone.S:111) ==31899==
> ==31899== Thread 1:
> ==31899== Source and destination overlap in memcpy(0xb9ce2a0,
> 0xb9ce39f, 256) ==31899==    at 0x4C2D75D: memcpy@@GLIBC_2.14
> (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==31899==
> by 0x43958B: recvline (sockserv.c:415) ==31899==    by 0x43C936:
> packet (splitscreen.c:1099) ==31899==    by 0x410014: changepars
> (changepars.c:777) ==31899==    by 0x40D42B: callinput
> (callinput.c:572) ==31899==    by 0x41E014: logit (logit.c:92)
> ==31899==    by 0x41F73E: main (main.c:945)
> 
> The code in question is:
> 
>                       memcpy(sockbuf[ifds].buf, sockbuf[ifds].buf +
> len, sockbuf[ifds].buflen - len);
> 
> Looking over the Glibc documentation it advises that if the source and
> destination locations overlap, then memmove() is the safe function to
> use.
> 
> I modified the call to memmove() and ran Tlf for several hours through
> the night and it was functioning normally until I closed it to work
> K5P using CQRlog.
> 
> I've attached a patch and will commit this to the master branch later.
> 
Please go ahead with the patch.

73, de Tom.



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--