Kismet Wireless

Kismet Forums

 

Posted by:mrhctr
Subject:Memory leak on kismet_server
Date:09:15:08 09/04/2015

Also, I have been able to reproduce a similar overall behaviour on the stable release (2013-03-R1b), but the leaks happen mainly on
Netracker::netracker_chain_handler. I can provide the valgrind information for this release also.

Regards,

--H├ęctor


> Hi,
>
> This has been raised before at https://www.kismetwireless.net/Forum/General/Messages/1410545417.427636 but haven't been addressed yet. I'll try to add some more info.
>
> I'm using the latest git revision.
>
> The scenario is a manual launch of kismet_server with suid root so kismet_capture is launched as root, using a TPLink dongle with ath9k_htc driver (although with other dongles such as RT it happens just the same). We also connect via telnet to the kismet_server and 'ENABLE client mac,signal_dbm'.
>
> The memory usage increases linearly with time. I compiled everything again so I could make use of the symbols and line numbers. Using valgrind (with "valgrind --leak-check=full --track-origins=yes kismet_server -s -n --no-plugins"), this is what I get after 155s:
>
>
> ==26839== LEAK SUMMARY:
> ==26839== definitely lost: 756,552 bytes in 30,110 blocks
> ==26839== indirectly lost: 13,630,610 bytes in 376,765 blocks
> ==26839== possibly lost: 52,286 bytes in 1,538 blocks
> ==26839== still reachable: 102,519 bytes in 1,344 blocks
> ==26839== suppressed: 0 bytes in 0 blocks
>
> These are the three most severe leaks found:
>
> ==26839== 14,242,024 (711,816 direct, 13,530,208 indirect) bytes in 29,659 blocks are definitely lost in loss record 1,066 of 1,066
> ==26839== at 0x4C2B0E0: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==26839== by 0x499A65: Protocol_PACKET_hook(GlobalRegistry*, void*, kis_packet*) (kis_netframe.cc:251)
> ==26839== by 0x4B4661: Packetchain::ProcessPacket(kis_packet*) (packetchain.cc:159)
> ==26839== by 0x47B058: PacketSource_Pcap::Poll() (packetsource_pcap.cc:319)
> ==26839== by 0x464D1E: Packetsourcetracker::Poll(fd_set&, fd_set&) (packetsourcetracker.cc:629)
> ==26839== by 0x42EE5C: main (kismet_server.cc:1327)
>
> ==26839== 82,355 (4,344 direct, 78,011 indirect) bytes in 181 blocks are definitely lost in loss record 1,052 of 1,066
> ==26839== at 0x4C2B0E0: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==26839== by 0x499A65: Protocol_PACKET_hook(GlobalRegistry*, void*, kis_packet*) (kis_netframe.cc:251)
> ==26839== by 0x4B4661: Packetchain::ProcessPacket(kis_packet*) (packetchain.cc:159)
> ==26839== by 0x4A8D34: GPSCore::Timer() (gpscore.cc:305)
> ==26839== by 0x4AB4AD: GPSDClient::Timer() (gpsdclient.cc:184)
> ==26839== by 0x4C3CDE: Timetracker::Tick() (timetracker.cc:64)
> ==26839== by 0x42EDF8: main (kismet_server.cc:1324)
>
> ==26839== 47,115 (35,280 direct, 11,835 indirect) bytes in 245 blocks are definitely lost in loss record 1,051 of 1,066
> ==26839== at 0x4C2B0E0: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==26839== by 0x4EF4F0: Netracker::BuildAdvSSID(unsigned int, dot11_packinfo*, kis_packet*) (netracker.cc:3370)
> ==26839== by 0x4F1D9F: Netracker::netracker_chain_handler(kis_packet*) (netracker.cc:2637)
> ==26839== by 0x4B45A1: Packetchain::ProcessPacket(kis_packet*) (packetchain.cc:151)
> ==26839== by 0x47B058: PacketSource_Pcap::Poll() (packetsource_pcap.cc:319)
> ==26839== by 0x464D1E: Packetsourcetracker::Poll(fd_set&, fd_set&) (packetsourcetracker.cc:629)
> ==26839== by 0x42EE5C: main (kismet_server.cc:1327)
>
>
> The line numbers indicate the lost-object creation. I'm not used to develop kismet and I'm afraid I would break things if I start to free objects indiscriminately. It would be nice if somebody could take a look!
>
>
> Regards


Reply to this message