|
From: Schmidt, A. <adr...@si...> - 2014-11-20 14:16:35
|
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
|