0

I've tried the following code on GeoIP 1.4.8 and 1.6.6 and it's only freeing 5 allocs out of 40 allocs reported by valgrind.

I'm aware of the "still reachable" according to this post, but I want to make sure that's the case in here. It does seem odd to me is only freeing 5 allocs. Any ideas?

==1687== HEAP SUMMARY:
==1687==     in use at exit: 35,128 bytes in 35 blocks
==1687==   total heap usage: 40 allocs, 5 frees, 36,847 bytes allocated
==1687== 
==1687== 312 bytes in 1 blocks are still reachable in loss record 1 of 35
==1687==    at 0x4C2C947: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1687==    by 0x4E3DA5E: _GeoIP_setup_dbfilename (in /usr/lib/libGeoIP.so.1.6.6)
==1687==    by 0x4E3E789: GeoIP_new (in /usr/lib/libGeoIP.so.1.6.6)
==1687==    by 0x40075E: main (in /home/pixie/a.out)
==1687== 
==1687== 1,024 bytes in 1 blocks are still reachable in loss record 2 of 35
==1687==    at 0x4C2C947: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1687==    by 0x4E3D9A5: _GeoIP_full_path_to (in /usr/lib/libGeoIP.so.1.6.6)
==1687==    by 0x4E3DA70: _GeoIP_setup_dbfilename (in /usr/lib/libGeoIP.so.1.6.6)
==1687==    by 0x4E3E789: GeoIP_new (in /usr/lib/libGeoIP.so.1.6.6)
==1687==    by 0x40075E: main (in /home/pixie/a.out)
==1687== 
==1687== 1,024 bytes in 1 blocks are still reachable in loss record 3 of 35
==1687==    at 0x4C2C947: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1687==    by 0x4E3D9A5: _GeoIP_full_path_to (in /usr/lib/libGeoIP.so.1.6.6)
==1687==    by 0x4E3DA83: _GeoIP_setup_dbfilename (in /usr/lib/libGeoIP.so.1.6.6)
==1687==    by 0x4E3E789: GeoIP_new (in /usr/lib/libGeoIP.so.1.6.6)
==1687==    by 0x40075E: main (in /home/pixie/a.out)
==1687== 
==1687== 1,024 bytes in 1 blocks are still reachable in loss record 4 of 35
==1687==    at 0x4C2C947: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1687==    by 0x4E3D9A5: _GeoIP_full_path_to (in /usr/lib/libGeoIP.so.1.6.6)
==1687==    by 0x4E3DA96: _GeoIP_setup_dbfilename (in /usr/lib/libGeoIP.so.1.6.6)
==1687==    by 0x4E3E789: GeoIP_new (in /usr/lib/libGeoIP.so.1.6.6)
==1687==    by 0x40075E: main (in /home/pixie/a.out)
...

Code

#include <GeoIP.h>

int main (int argc, char **argv) {
  GeoIP * gp; 

  gp = GeoIP_new(GEOIP_STANDARD);
  printf("%s\n", GeoIP_country_code_by_addr(gp, "216.58.216.238"));
  GeoIP_delete(gp);

  return 0;
}
Community
  • 1
  • 1
Pete Darrow
  • 455
  • 5
  • 20
  • You must be careful using libraries, as some allocate blocks of memory for use by the library itself and are not particular about freeing the memory relying on program exit to handle it. For the larger, more well know libraries, there are published exclusion lists for `valgrind` to account for this type of allocation (e.g `GTK+`, etc.). I don't know enough about geoip to tell you if that is what is occurring, but judging from your code, it looks like the classic symptoms of memory allocated that is not within your control. – David C. Rankin May 14 '16 at 03:23
  • Thanks for pointing that out. I'm starting to think that's probably the case. – Pete Darrow May 14 '16 at 03:33
  • If you call GeoIP_new and GeoIP_delete again (so twice each in total), then does it increase to 10 blocks? – user253751 May 14 '16 at 03:40
  • @immibis Calling it twice yields to `in use at exit: 35,128 bytes in 35 blocks total heap usage: 44 allocs, 9 frees, 37,542 bytes allocate` – Pete Darrow May 14 '16 at 04:02

1 Answers1

1

Apparently the following call does the job (not documented).

GeoIP_cleanup();
Pete Darrow
  • 455
  • 5
  • 20