smiExit() fails to free one allocation ?
Hi libsmi team, This is to report two issues with regards to : libsmi-0.4.8-16.fc23.x86_64
Issue #1Although smiExit() does good job of freeing memory blocks allocated by smiInit, it misses one. To be precise, 44 out of 45 allocated memory block are freed. (Details of the experiment at the end of this mail)
Issue #2The libsmi examples here^ do not call smiExit():^ https://www.ibr.cs.tu-bs.de/projects/libsmi/example.html%5E https://www.ibr.cs.tu-bs.de/projects/libsmi/libsmi.html
Details of the memory leak:To investigate this issue, first noted by 'tcpdump' project, I wrote two simple programs; one calls smiExit(), and the other does not.(Platform: Fedora Core 23 (64 bit))
The following sample program does not call smiExit();$ cat libsmi_noexit.c #include <smi.h> void main(){ smiInit(NULL);} Relevant parts of Valgrind Output:==10291== HEAP SUMMARY:==10291== in use at exit: 3,834 bytes in 45 blocks==10291== total heap usage: 45 allocs, 0 frees, 3,834 bytes allocated ==10291== LEAK SUMMARY:==10291== definitely lost: 80 bytes in 1 blocks==10291== indirectly lost: 0 bytes in 0 blocks==10291== possibly lost: 0 bytes in 0 blocks==10291== still reachable: 3,754 bytes in 44 blocks==10291== suppressed: 0 bytes in 0 blocks
The following sample program calls smiExit();$ cat libsmi_exit.c#include <smi.h> void main(){ smiInit(NULL); smiExit();} Relevant parts of Valgrind Output:==10299== HEAP SUMMARY:==10299== in use at exit: 80 bytes in 1 blocks==10299== total heap usage: 45 allocs, 44 frees, 3,834 bytes allocated==10299== ==10299== 80 bytes in 1 blocks are definitely lost in loss record 1 of 1==10299== at 0x4C2A988: calloc (vg_replace_malloc.c:711)==10299== by 0x4E48A9D: smiMalloc (in /usr/lib64/libsmi.so.2.0.27)==10299== by 0x4E448E5: smiInitData (in /usr/lib64/libsmi.so.2.0.27)==10299== by 0x4E4B8B2: smiInit (in /usr/lib64/libsmi.so.2.0.27)==10299== by 0x4006F3: main (in /home/bijal/projects/libsmi_leaktest/libsmi_exit) ==10299== LEAK SUMMARY:==10299== definitely lost: 80 bytes in 1 blocks ==10299== indirectly lost: 0 bytes in 0 blocks==10299== possibly lost: 0 bytes in 0 blocks==10299== still reachable: 0 bytes in 0 blocks==10299== suppressed: 0 bytes in 0 blocks`
I have just begun to contribute to tcpdump project, and have no experience of using libsmi,but glad to participate in discussion with regards to this.
ThanksBijal
On Thu, Jul 28, 2016 at 01:29:41PM +0000, Bijal Thanawala wrote:
Hi libsmi team, This is to report two issues with regards to : libsmi-0.4.8-16.fc23.x86_64
Issue #1Although smiExit() does good job of freeing memory blocks allocated by smiInit, it misses one. To be precise, 44 out of 45 allocated memory block are freed. (Details of the experiment at the end of this mail)
I see 80 bytes not freed on my Debian system but this does not make me really concerned; that said I am happy to accept a patch if someone manages to track this down.
Issue #2The libsmi examples here^ do not call smiExit():^ https://www.ibr.cs.tu-bs.de/projects/libsmi/example.html%5E https://www.ibr.cs.tu-bs.de/projects/libsmi/libsmi.html
Yes, the example would be nicer if it would show how to call smiExit() but then a decent OS will cleanup anyway when the process exits. I can't easily change the example since I have no direct way to access the web page anymore.
Details of the memory leak:To investigate this issue, first noted by 'tcpdump' project, I wrote two simple programs; one calls smiExit(), and the other does not.(Platform: Fedora Core 23 (64 bit))
[...]
I have just begun to contribute to tcpdump project, and have no experience of using libsmi,but glad to participate in discussion with regards to this.
I do not think the ~80 bytes lost really affect tcpdump; libsmi initially did not really care about freeing anything since most applications load MIB data and then they use it until completion (and I think tcpdump falls into this category). We started being more concerned about freeing memory when we added the ability to maintain multiple MIB trees and applications wanted to load and unload MIB trees dynamically.
/js
----- Original Message ----- From: Juergen Schoenwaelder j.schoenwaelder@jacobs-university.de
To: Bijal Thanawala bijal.thanawala@yahoo.com Cc: "libsmi@ibr.cs.tu-bs.de" libsmi@ibr.cs.tu-bs.de Sent: Friday, 29 July 2016, 0:36 Subject: Re: [libsmi] smiExit() fails to free one allocation ?
On Thu, Jul 28, 2016 at 01:29:41PM +0000, Bijal Thanawala wrote:>> Hi libsmi team, This is to report two issues with regards to : libsmi-0.4.8-16.fc23.x86_64
Issue #1Although smiExit() does good job of freeing memory blocks allocated by smiInit, it misses one. To be precise, 44 out of 45 >>allocated memory block are freed. (Details of the experiment at the end of this mail)
I see 80 bytes not freed on my Debian system but this does not make me really concerned; that said I am happy to accept a patch if someone manages to track this down.
Issue #2The libsmi examples here^ do not call smiExit():^ https://www.ibr.cs.tu-bs.de/projects/libsmi/example.html%5E https://www.ibr.cs.tu-bs.de/projects/libsmi/libsmi.html
Yes, the example would be nicer if it would show how to call smiExit() but then a decent OS will cleanup anyway when the process exits. I can't easily change the example since I have no direct way to access the web page anymore.
Details of the memory leak:To investigate this issue, first noted by 'tcpdump' project, I wrote two simple programs; one calls smiExit(), and the other does not.(Platform: Fedora Core 23 (64 bit)) [...]
I have just begun to contribute to tcpdump project, and have no experience of using libsmi,but glad to participate in discussion with regards to this.
I do not think the ~80 bytes lost really affect tcpdump; libsmi initially did not really care about freeing anything since most applications load MIB data and then they use it until completion (and I think tcpdump falls into this category). We started being more concerned about freeing memory when we added the ability to maintain multiple MIB trees and applications wanted to load and unload MIB trees dynamically.
/js
-- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/
Thanks for the quick response.
I managed to build the libsmi and find the allocated block that is not freed.
(There were some autoconf issues on my system that I had to solve before I could build - I shall post details in a separate thread)
The cause for memory leak (one block, 80 bytes): File: lib/smi-data.c parser.pendingNodePtr allocated in smiInitData() (through addNode()) is never freed.
In the same file, elsewhere this comments appear twice (within #ifdefs) /* * These nodes seem to be referenced in certain situations and * thus freeing them causes problems. So we better do not free * until we have sorted out how to free safely. . . . */
After traversing code several times, I conclude that someone with more knowledge and experience of libsmi is better suited to handle this.
Glad to provide any testing/assistance on this matter.
Regards Bijal
(There were some autoconf issues on my system that I had to solve before I could build - I shall post details in a separate thread)
I take that back. I did not notice ./autogen.sh the first time. Running that script on a fresh checkout worked perfect.
----- Original Message ----- From: Bijal Thanawala bijal.thanawala@yahoo.com To: "libsmi@ibr.cs.tu-bs.de" libsmi@ibr.cs.tu-bs.de Sent: Monday, 1 August 2016, 22:29 Subject: Re: [libsmi] smiExit() fails to free one allocation ?
----- Original Message ----- From: Juergen Schoenwaelder j.schoenwaelder@jacobs-university.de
To: Bijal Thanawala bijal.thanawala@yahoo.com Cc: "libsmi@ibr.cs.tu-bs.de" libsmi@ibr.cs.tu-bs.de Sent: Friday, 29 July 2016, 0:36 Subject: Re: [libsmi] smiExit() fails to free one allocation ?
On Thu, Jul 28, 2016 at 01:29:41PM +0000, Bijal Thanawala wrote:>> Hi libsmi team, This is to report two issues with regards to : libsmi-0.4.8-16.fc23.x86_64
Issue #1Although smiExit() does good job of freeing memory blocks allocated by smiInit, it misses one. To be precise, 44 out of 45 >>allocated memory block are freed. (Details of the experiment at the end of this mail)
I see 80 bytes not freed on my Debian system but this does not make me really concerned; that said I am happy to accept a patch if someone manages to track this down.
Issue #2The libsmi examples here^ do not call smiExit():^ https://www.ibr.cs.tu-bs.de/projects/libsmi/example.html%5E https://www.ibr.cs.tu-bs.de/projects/libsmi/libsmi.html
Yes, the example would be nicer if it would show how to call smiExit() but then a decent OS will cleanup anyway when the process exits. I can't easily change the example since I have no direct way to access the web page anymore.
Details of the memory leak:To investigate this issue, first noted by 'tcpdump' project, I wrote two simple programs; one calls smiExit(), and the other does not.(Platform: Fedora Core 23 (64 bit)) [...]
I have just begun to contribute to tcpdump project, and have no experience of using libsmi,but glad to participate in discussion with regards to this.
I do not think the ~80 bytes lost really affect tcpdump; libsmi initially did not really care about freeing anything since most applications load MIB data and then they use it until completion (and I think tcpdump falls into this category). We started being more concerned about freeing memory when we added the ability to maintain multiple MIB trees and applications wanted to load and unload MIB trees dynamically.
/js
-- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/
Thanks for the quick response.
I managed to build the libsmi and find the allocated block that is not freed.
(There were some autoconf issues on my system that I had to solve before I could build - I shall post details in a separate thread)
The cause for memory leak (one block, 80 bytes): File: lib/smi-data.c parser.pendingNodePtr allocated in smiInitData() (through addNode()) is never freed.
In the same file, elsewhere this comments appear twice (within #ifdefs) /* * These nodes seem to be referenced in certain situations and * thus freeing them causes problems. So we better do not free * until we have sorted out how to free safely. . . . */
After traversing code several times, I conclude that someone with more knowledge and experience of libsmi is better suited to handle this.
Glad to provide any testing/assistance on this matter.
Regards
Bijal
participants (2)
-
Bijal Thanawala -
Juergen Schoenwaelder