Valgrand was not happy with the order in which pthread_cond_signal() and pthread_mutex_unlock() were being called. Also see https://docs.oracle.com/cd/E19455-01/806-5257/6je9h032r/index.html which states "Call pthread_cond_signal() under the protection of the same mutex used with the condition variable being signaled. Otherwise, the condition variable could be signaled between the test of the associated condition and blocking in pthread_cond_wait(), which can cause an infinite wait."
Patch also available at: https://github.com/wknickless/iftop/commit/4c2fc858dc90b497819f0580fa4723a23...
Signed-off-by: Bill Nickless bill@nonick.org --- resolver.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/resolver.c b/resolver.c index 6c4c21d..70394c2 100644 --- a/resolver.c +++ b/resolver.c @@ -508,12 +508,13 @@ void resolve(int af, void* addr, char* result, int buflen) { added = 1; } } - pthread_mutex_unlock(&resolver_queue_mutex);
if(added == 1) { pthread_cond_signal(&resolver_queue_cond); }
+ pthread_mutex_unlock(&resolver_queue_mutex); + if(result != NULL && buflen > 1) { strncpy(result, hostname, buflen - 1); result[buflen - 1] = '\0'; -- 2.25.1