tlf-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Tlf-devel] Possible memory leak


From: Nate Bargmann
Subject: [Tlf-devel] Possible memory leak
Date: Sat, 23 Jan 2016 09:12:25 -0600
User-agent: Mutt/1.5.23 (2014-03-12)

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:

==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.

73, Nate

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Ham radio, Linux, bikes, and more: http://www.n0nb.us

Attachment: sockserv.c.diff
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]