pacparser_setmyip leaks memory

[regiMario]

that is because myip is alloced but never freed.
I'd send a patch, but github is being a bitch about it.

[olivn]

Is it related to this ?
Could you please publish your patch ?

==20235== HEAP SUMMARY:
==20235==     in use at exit: 163,640 bytes in 40 blocks
==20235==   total heap usage: 31,934 allocs, 31,894 frees, 67,595,642 bytes allocated
==20235== 
==20235== Searching for pointers to 40 not-freed blocks
==20235== Checked 124,178,624 bytes
==20235== 
==20235== Thread 1:
==20235== 13 bytes in 1 blocks are definitely lost in loss record 1 of 21
==20235==    at 0x4843794: malloc (vg_replace_malloc.c:431)
==20235==    by 0x486532C: pacparser_setmyip (pacparser.c:282)
==20235==    by 0x8CDDEC: _cgo_be3e44c5c32b_Cfunc_pacparser_setmyip (in /tmp/proxypac_exporter/proxypac_exporter)
==20235==    by 0x472A47: runtime.asmcgocall.abi0 (asm_amd64.s:872)
==20235==    by 0x4D429E1F: ???
==20235==    by 0x40B584: runtime.send.goready.func1 (proc.go:409)
==20235==    by 0xC000238E9F: ???
==20235== 
==20235== 13 bytes in 1 blocks are definitely lost in loss record 2 of 21
==20235==    at 0x4843794: malloc (vg_replace_malloc.c:431)
==20235==    by 0x486532C: pacparser_setmyip (pacparser.c:282)
==20235==    by 0x8CDDEC: _cgo_be3e44c5c32b_Cfunc_pacparser_setmyip (in /tmp/proxypac_exporter/proxypac_exporter)
==20235==    by 0x472A47: runtime.asmcgocall.abi0 (asm_amd64.s:872)
==20235==    by 0x4D429E1F: ???
==20235==    by 0x40B584: runtime.send.goready.func1 (proc.go:409)
==20235==    by 0xC0002844DF: ???
==20235== 
==20235== 13 bytes in 1 blocks are definitely lost in loss record 3 of 21
==20235==    at 0x4843794: malloc (vg_replace_malloc.c:431)
==20235==    by 0x486532C: pacparser_setmyip (pacparser.c:282)
==20235==    by 0x8CDDEC: _cgo_be3e44c5c32b_Cfunc_pacparser_setmyip (in /tmp/proxypac_exporter/proxypac_exporter)
==20235==    by 0x472A47: runtime.asmcgocall.abi0 (asm_amd64.s:872)
==20235==    by 0x50A42E1F: ???
==20235==    by 0x40B584: runtime.send.goready.func1 (proc.go:409)
==20235==    by 0xC0005449BF: ???
==20235== 
==20235== 13 bytes in 1 blocks are definitely lost in loss record 4 of 21
==20235==    at 0x4843794: malloc (vg_replace_malloc.c:431)
==20235==    by 0x486532C: pacparser_setmyip (pacparser.c:282)
==20235==    by 0x8CDDEC: _cgo_be3e44c5c32b_Cfunc_pacparser_setmyip (in /tmp/proxypac_exporter/proxypac_exporter)
==20235==    by 0x472A47: runtime.asmcgocall.abi0 (asm_amd64.s:872)
==20235==    by 0x4EDCCE1F: ???
==20235==    by 0x40B584: runtime.send.goready.func1 (proc.go:409)
==20235==    by 0xC00054537F: ???
==20235== 
==20235== 13 bytes in 1 blocks are definitely lost in loss record 5 of 21
==20235==    at 0x4843794: malloc (vg_replace_malloc.c:431)
==20235==    by 0x486532C: pacparser_setmyip (pacparser.c:282)
==20235==    by 0x8CDDEC: _cgo_be3e44c5c32b_Cfunc_pacparser_setmyip (in /tmp/proxypac_exporter/proxypac_exporter)
==20235==    by 0x472A47: runtime.asmcgocall.abi0 (asm_amd64.s:872)
==20235==    by 0x4DC6AE1F: ???
==20235==    by 0x40B584: runtime.send.goready.func1 (proc.go:409)
==20235==    by 0xC000545D3F: ???
==20235== 
==20235== 108 bytes in 1 blocks are definitely lost in loss record 7 of 21
==20235==    at 0x4843794: malloc (vg_replace_malloc.c:431)
==20235==    by 0x4A6B7B2: __libc_alloc_buffer_allocate (alloc_buffer_allocate.c:26)
==20235==    by 0x4B0B2D5: alloc_buffer_allocate (alloc_buffer.h:149)
==20235==    by 0x4B0B2D5: __resolv_conf_allocate (resolv_conf.c:394)
==20235==    by 0x4B06386: __resolv_conf_load (res_init.c:599)
==20235==    by 0x4B0AF4E: __resolv_conf_get_current (resolv_conf.c:143)
==20235==    by 0x4B06F24: __res_vinit (res_init.c:628)
==20235==    by 0x4B0BC7A: maybe_init (resolv_context.c:122)
==20235==    by 0x4B0BE02: context_get (resolv_context.c:184)
==20235==    by 0x4B0BE02: context_get (resolv_context.c:176)
==20235==    by 0x4B0BE02: __resolv_context_get (resolv_context.c:195)
==20235==    by 0x4AF294D: gethostbyname2_r@@GLIBC_2.2.5 (getXXbyYY_r.c:213)
==20235==    by 0x4AB02D0: try_simple_gethostbyname (getaddrinfo.c:979)
==20235==    by 0x4AB02D0: gaih_inet (getaddrinfo.c:1167)
==20235==    by 0x4AB02D0: getaddrinfo (getaddrinfo.c:2385)
==20235==    by 0x4864C37: resolve_host (pacparser.c:154)
==20235==    by 0x4864DEE: dns_resolve (pacparser.c:180)
==20235==    by 0x48BE407: js_Invoke (jsinterp.c:1375)
==20235==    by 0x48D1B95: js_Interpret (jsinterp.c:3944)
==20235==    by 0x48BE4AC: js_Invoke (jsinterp.c:1394)
==20235==    by 0x48BEA01: js_InternalInvoke (jsinterp.c:1469)
==20235==    by 0x487A723: JS_CallFunctionName (jsapi.c:4339)
==20235==    by 0x4865B28: pacparser_find_proxy (pacparser.c:458)
==20235==    by 0x8CDCF3: _cgo_be3e44c5c32b_Cfunc_pacparser_find_proxy (in /tmp/proxypac_exporter/proxypac_exporter)
==20235==    by 0x472A47: runtime.asmcgocall.abi0 (asm_amd64.s:872)
==20235==    by 0x4D429E1F: ???
==20235==    by 0x40B584: runtime.send.goready.func1 (proc.go:409)
==20235==    by 0xC000238E9F: ???
==20235== 

[regiMario]

diff --git a/src/pacparser.c b/src/pacparser.c
index 7f2e0a0..2ff26d5 100644
--- a/src/pacparser.c
+++ b/src/pacparser.c
@@ -47,6 +47,7 @@
 #  define UNUSED(x) UNUSED_ ## x
 #endif
 
+static char ipbuffer[INET6_ADDRSTRLEN+1];
 static char *myip = NULL;
 
 // Default error printer function.
@@ -279,8 +280,8 @@ pacparser_setmyip(const char *ip)
     return 0;
   }
 
-  myip = malloc(strlen(ip) +1);         // Allocate space just to be sure.
-  strcpy(myip, ip);
+  strcpy(ipbuffer, ip);
+  myip = &ipbuffer[0];
   return 1;
 }
 

[olivn]

Thanks

pacparser_setmyip does not appear any more in valgrind reports.

==32087== 
==32087== HEAP SUMMARY:
==32087==     in use at exit: 163,575 bytes in 35 blocks
==32087==   total heap usage: 31,929 allocs, 31,894 frees, 67,595,577 bytes allocated
==32087== 
==32087== Searching for pointers to 35 not-freed blocks
==32087== Checked 123,930,656 bytes
==32087== 
==32087== Thread 1:
==32087== 108 bytes in 1 blocks are definitely lost in loss record 2 of 17
==32087==    at 0x4843794: malloc (vg_replace_malloc.c:431)
==32087==    by 0x4A597B2: __libc_alloc_buffer_allocate (alloc_buffer_allocate.c:26)
==32087==    by 0x4AF92D5: alloc_buffer_allocate (alloc_buffer.h:149)
==32087==    by 0x4AF92D5: __resolv_conf_allocate (resolv_conf.c:394)
==32087==    by 0x4AF4386: __resolv_conf_load (res_init.c:599)
==32087==    by 0x4AF8F4E: __resolv_conf_get_current (resolv_conf.c:143)
==32087==    by 0x4AF4F24: __res_vinit (res_init.c:628)
==32087==    by 0x4AF9C7A: maybe_init (resolv_context.c:122)
==32087==    by 0x4AF9E02: context_get (resolv_context.c:184)
==32087==    by 0x4AF9E02: context_get (resolv_context.c:176)
==32087==    by 0x4AF9E02: __resolv_context_get (resolv_context.c:195)
==32087==    by 0x4AE094D: gethostbyname2_r@@GLIBC_2.2.5 (getXXbyYY_r.c:213)
==32087==    by 0x4A9E2D0: try_simple_gethostbyname (getaddrinfo.c:979)
==32087==    by 0x4A9E2D0: gaih_inet (getaddrinfo.c:1167)
==32087==    by 0x4A9E2D0: getaddrinfo (getaddrinfo.c:2385)
==32087==    by 0x48647E3: resolve_host (pacparser.c:159)
==32087==    by 0x486495F: dns_resolve (pacparser.c:185)
==32087==    by 0x48B7E3F: js_Invoke (jsinterp.c:1375)
==32087==    by 0x48C96AA: js_Interpret (jsinterp.c:3944)
==32087==    by 0x48B7ED8: js_Invoke (jsinterp.c:1394)
==32087==    by 0x48B837A: js_InternalInvoke (jsinterp.c:1469)
==32087==    by 0x4878CB6: JS_CallFunctionName (jsapi.c:4339)
==32087==    by 0x4865524: pacparser_find_proxy (pacparser.c:463)
==32087==    by 0x8CDCF3: _cgo_be3e44c5c32b_Cfunc_pacparser_find_proxy (in /data/Comp/go_env/src/snet/proxypac_exporter/proxypac_exporter)
==32087==    by 0x472A47: runtime.asmcgocall.abi0 (asm_amd64.s:872)
==32087==    by 0x4F63BE1F: ???
==32087==    by 0x40B584: runtime.send.goready.func1 (proc.go:409)
==32087==    by 0xC0002749BF: ???
==32087== 
==32087== 288 bytes in 1 blocks are possibly lost in loss record 3 of 17
==32087==    at 0x484874F: calloc (vg_replace_malloc.c:1554)

[manugarg]

Thanks @regiMario for reporting this and the patch suggestion and @olivn for verifying with valgrind before and after the change.

I've created #174 to fix this.

[manugarg]

Merged #174. It will go out in the next release.