We briefly discussed adding CURLDEBUG functionality to c-ares before.
I had something like this in mind:
--- ares_init.c 3 May 2006 06:11:44 -0000 1.36
+++ ares_init.c 20 Jul 2006 16:00:31 -0000
@@ -93,6 +93,16 @@
struct server_state *server;
struct timeval tv;
+#ifdef CURLDEBUG
+ const char *env = getenv("CARES_MEMDEBUG");
+
+ if (env)
+ curl_memdebug(env);
+ env = getenv("CARES_MEMLIMIT");
+ if (env)
+ curl_memlimit(atoi(env));
+#endif
+
channel = malloc(sizeof(struct ares_channeldata));
if (!channel)
return ARES_ENOMEM;
Okay to commit?
BTW. With the above patch (and CURLDEBUG in effect in libcurl), curl.exe
shows some mysterious memory leaks:
The report for curl.exe:
> \tests\memanalyze.pl memdebug
FREE ERROR: No memory allocated: MEM main.c:3226 free(0x3d2538) << this is okay
Leak detected: memory still allocated: 33970 bytes
At a388a8, there's 72 bytes.
allocated by main.c:628
At a387a0, there's 2 bytes.
allocated by main.c:628
At a38878, there's 20 bytes.
allocated by main.c:715
At a38858, there's 2 bytes.
allocated by main.c:628
At 3d2508, there's 23 bytes.
allocated by main.c:628
At a38908, there's 33808 bytes.
allocated by url.c:302
At 3d8258, there's 43 bytes.
allocated by main.c:628
------------------
The report for libcares.dll:
> tests\memanalyze.pl memdebug.cares
FREE ERROR: No memory allocated: MEM main.c:4225 free(0xa388a8)
FREE ERROR: No memory allocated: MEM main.c:4233 free(0xa38878)
FREE ERROR: No memory allocated: MEM url.c:285 free(0xa38908)
FREE ERROR: No memory allocated: MEM main.c:3069 free(0x3d2508)
FREE ERROR: No memory allocated: MEM main.c:3073 free(0xa38858)
FREE ERROR: No memory allocated: MEM main.c:3093 free(0xa387a0)
FREE ERROR: No memory allocated: MEM main.c:3103 free(0x3d8258)
--gv
Received on 2006-07-20