[Valgrind-users] Helgrind on ARM: false positive on condition variable

[Schmidt, A. <adr...@si...>]

Hi all,

Running Helgrind (Valgrind 3.10.0) on ARM, I get a result I cannot explain, but which looks like a false positive to me. 
This is my sample code (cv.c):
----------
#include <pthread.h>
#include <unistd.h>
#include <stdio.h>

int flag;
pthread_cond_t cv;
pthread_mutex_t mutex;
pthread_t sender, receiver;

void *fn_send(void *arg)
{
  // "ensure" that the receiver is waiting before we signal
  usleep(1000000);

  pthread_mutex_lock(&mutex);
  printf(" *** sending ***\n");
  flag = 1;
  pthread_cond_signal(&cv);
  pthread_mutex_unlock(&mutex);
}

void *fn_receive(void *arg)
{
  pthread_mutex_lock(&mutex);
  printf(" *** waiting ***\n");
  while (!flag)
    pthread_cond_wait(&cv, &mutex);
  printf(" *** received ***\n");
  pthread_mutex_unlock(&mutex);
}

int main()
{
  flag = 0;
  pthread_mutex_init(&mutex, NULL);
  pthread_cond_init(&cv, NULL);

  pthread_create(&sender, NULL, fn_send, NULL);
  pthread_create(&receiver, NULL, fn_receive, NULL);

  pthread_join(sender, NULL);
  pthread_join(receiver, NULL);
	
  printf(" *** done. ***\n");
  return 0;
}
----------
I compile with:
$ gcc -g -c -o cv cv.c -lpthread

I'm running this on two different systems:
On x86 (Core i5), I see the expected result:
$ uname -a
Linux debian 3.16-2-amd64 #1 SMP Debian 3.16.3-2 (2014-09-20) x86_64 GNU/Linux
$ valgrind --tool=helgrind ./cv
==2636== Helgrind, a thread error detector
==2636== Copyright (C) 2007-2013, and GNU GPL'd, by OpenWorks LLP et al.
==2636== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==2636== Command: ./cv
==2636== 
 *** waiting ***
 *** sending ***
 *** received ***
 *** done. ***
==2636== 
==2636== For counts of detected and suppressed errors, rerun with: -v
==2636== Use --history-level=approx or =none to gain increased speed, at
==2636== the cost of reduced accuracy of conflicting-access information
==2636== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 20 from 20)

On armv7 (i.MX6), I see the following:
$ uname -a
Linux nitrogen 3.10.17-8-boundary-4t3 #8 SMP Wed Jul 30 00:42:25 CEST 2014 armv7l armv7l armv7l GNU/Linux
$ valgrind --tool=helgrind ./cv
==2069== Helgrind, a thread error detector
==2069== Copyright (C) 2007-2013, and GNU GPL'd, by OpenWorks LLP et al.
==2069== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==2069== Command: ./cv
==2069== 
 *** waiting ***
 *** sending ***
 *** received ***
==2069== ---Thread-Announcement------------------------------------------
==2069== 
==2069== Thread #3 was created
==2069==    at 0x4907946: clone (clone.S:62)
==2069== 
==2069== ----------------------------------------------------------------
==2069== 
==2069== Thread #3 unlocked a not-locked lock at 0x11058
==2069==    at 0x4835EB8: pthread_mutex_unlock (hg_intercepts.c:707)
==2069==    by 0x876F: fn_receive (cv.c:30)
==2069==    by 0x48348F3: mythread_wrapper (hg_intercepts.c:234)
==2069==    by 0x485EFBB: start_thread (pthread_create.c:314)
==2069==    by 0x490797B: ??? (clone.S:92)
==2069==  Lock at 0x11058 was first observed
==2069==    at 0x483577C: pthread_mutex_init (hg_intercepts.c:518)
==2069==    by 0x8795: main (cv.c:36)
==2069==  Address 0x11058 is 0 bytes inside data symbol "mutex"
==2069== 
==2069== 
==2069== ----------------------------------------------------------------
==2069== 
==2069== Thread #3: Exiting thread still holds 1 lock
==2069==    at 0x48665F6: __libc_do_syscall (libc-do-syscall.S:44)
==2069== 
 *** done. ***
==2069== 
==2069== For counts of detected and suppressed errors, rerun with: -v
==2069== Use --history-level=approx or =none to gain increased speed, at
==2069== the cost of reduced accuracy of conflicting-access information
==2069== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 22 from 19)


I did notice the section in the manual stating that condition variables can cause problems when running Helgrind (7.5, Section 3), but:
- in my example the waiting thread gets to the rendezvous first, and
- https://bugs.kde.org/show_bug.cgi?id=213383 says that the information is obsolete anyway, and
- this would not explain the different behavior on ARM vs. x86.

Am I missing something here?

Best regards,
Adriaan