You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
mod_webmail: Fix memory leak when using SORT/SEARCH.
When using our custom libetpan function for SORT/SEARCH,
the clist of results was not being freed afterwards since
neither of the conditions to free was true. These conditions
were correct, since the corresponding free functions cannot
be used, but we still need to manually free the list.
Basic tests have also been added for mod_webmail that captured
this memory leak (and now pass).
Related fixes:
* mod_http: Don't compare Connection header value case-sensitively.
Per RFC 7230, this value is not case-sensitive. The mod_webmail
test uses it in a different case intentionally to test this.
* net_ws: Remove dependency on net_http. Although you would probably
want this module loaded, it is not actually a hard dependency,
i.e. net_http exports no symbols required by net_ws to load.
This eliminates some otherwise confusing error messages about
dependencies failing to load, since it's not actually one.
* tests/Makefile: Use $^ instead of *.o as the inputs for the test
binary. I'm not sure how it ever worked the old way, since the
object files for the test modules shouldn't get linked in.
LBBS-99 #close
client_set_status(ws, "Your IMAP server does not support SORT");
2044
2045
sort=NULL; /* If server doesn't support sort, we can't sort */
2045
2046
}
2047
+
2048
+
/* The else case is to handle frees when LIBETPAN_SEARCH_KEYS_BROKEN_ABI is true (which it currently is).
2049
+
* In this case, neither searchlist or sortlist will be set to 1, because mailimap_sort_result_free
2050
+
* and mailimap_search_result_free are not the correct functions to use.
2051
+
* In that case, we can just manually free the list and everything in it. */
2052
+
#defineFREE_SORT_SEARCH_LISTS() \
2053
+
if (sortlist) { \
2054
+
mailimap_sort_result_free(sorted); \
2055
+
sorted = NULL; \
2056
+
} else if (searchlist) { \
2057
+
mailimap_search_result_free(sorted); \
2058
+
sorted = NULL; \
2059
+
} else { \
2060
+
for (cur = clist_begin(sorted); cur; cur = clist_next(cur)) { \
2061
+
uint32_t *s = clist_content(cur); \
2062
+
free(s); \
2063
+
} \
2064
+
clist_free(sorted); \
2065
+
sorted = NULL; \
2066
+
}
2067
+
2046
2068
/* Thankfully, SEARCH is not an extension, it should be supported by all IMAP servers */
2047
2069
if (sort||filter) {
2048
2070
intindex=1;
2049
2071
intsearchlist, sortlist;
2050
2072
/*! \todo Cache this between FETCHLIST calls */
2051
-
clist*sorted=sortall(client, sort, filter, &searchlist, &sortlist); /* This could be somewhat slow, since we have sort the ENTIRE mailbox every time */
2073
+
sorted=sortall(client, sort, filter, &searchlist, &sortlist); /* This could be somewhat slow, since we have sort the ENTIRE mailbox every time */
Copy file name to clipboardExpand all lines: tests/test.c
+2-2Lines changed: 2 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -374,7 +374,7 @@ int test_client_expect_eventually_buf(int fd, int ms, const char *restrict s, in
374
374
}
375
375
buf[bytes] ='\0'; /* Safe */
376
376
/* Probably ends in LF, so skip one here */
377
-
bbs_debug(10, "Analyzing output: %s", buf); /* Particularly under valgrind, we'll end up reading individual lines more than chunks, so using CLIENT_DRAIN is especially important */
377
+
bbs_debug(10, "Analyzing output(%d): %s", line, buf); /* Particularly under valgrind, we'll end up reading individual lines more than chunks, so using CLIENT_DRAIN is especially important */
378
378
/* XXX Should use bbs_readline_append for reliability */
379
379
if (strstr(buf, s)) {
380
380
return0;
@@ -1000,7 +1000,7 @@ static int run_test(const char *filename, int multiple)
1000
1000
res=-1;
1001
1001
goto cleanup;
1002
1002
}
1003
-
bbs_debug(3, "Spawned child process %d\n", childpid);
0 commit comments