race condition reported in pthread_create

View: New views
2 Messages — Rating Filter:   Alert me  

race condition reported in pthread_create

by Brian Modra-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi,
in my Open Source project, The Karoo Project, I was rigorously testing
using helgrind, and consistently got a report of a possible race
condition in pthread_create. This seemed strange, and I checked out
the address it was reporting, which turned out to be a variable
allocated on the stack inside the call to pthread_create, or in a
function it called inside the pthreads library.

So I created a test program which does reproduce the same race
condition waring. (Attached)
To compile and test:
gcc -o z z.c -lpthread
valgrind --tool=helgrind ./z

Note that if I don't pass the pointer to the element in the data
array, then there is no race condition reported.
But this memory is not written or read anywhere in my program.

I wonder if anyone else has experienced this... I need to work out if
this is a valgrind bug, or a pthreads bug, or am I missing something?

Information about my system:
$ uname -a
Linux tigger 2.6.29-gentoo-r5 #1 SMP Tue Jul 14 14:56:15 SAST 2009
i686 Intel(R) Celeron(R) M CPU 530 @ 1.73GHz GenuineIntel GNU/Linux
$ ls -l /lib/libpthread*
-rwxr-xr-x 1 root root 113986 2009-07-14 19:45 /lib/libpthread-2.9.so
lrwxrwxrwx 1 root root     17 2009-07-14 19:45 /lib/libpthread.so.0 ->
libpthread-2.9.so

sys-libs/glibc  version installed: 2.9_p20081201-r2
dev-util/valgrind   version installed: 3.4.1-r1

Typical out put from testing the program with helgrind:

$ valgrind --tool=helgrind ./z
==30432== Helgrind, a thread error detector.
==30432== Copyright (C) 2007-2008, and GNU GPL'd, by OpenWorks LLP et al.
==30432== Using LibVEX rev 1884, a library for dynamic binary translation.
==30432== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
==30432== Using valgrind-3.4.1, a dynamic binary instrumentation framework.
==30432== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al.
==30432== For more details, rerun with: -v
==30432==
==30432== Thread #4 was created
==30432==    at 0x411E2A8: clone (in /lib/libc-2.9.so)
==30432==    by 0x4048729: pthread_create@@GLIBC_2.1 (in /lib/libpthread-2.9.so)
==30432==    by 0x4028175: pthread_create@* (in
/usr/lib/valgrind/x86-linux/vgpreload_helgrind.so)
==30432==    by 0x80485BE: main (in /home/bmodra/z)
==30432==
==30432== Thread #1 is the program's root thread
==30432==
==30432== Possible data race during write of size 4 at 0xbef00ecc by thread #4
==30432==    at 0x4028259: (within
/usr/lib/valgrind/x86-linux/vgpreload_helgrind.so)
==30432==    by 0x4048007: start_thread (in /lib/libpthread-2.9.so)
==30432==    by 0x411E2BD: clone (in /lib/libc-2.9.so)
==30432==  This conflicts with a previous read of size 4 by thread #1
==30432==    at 0x402818A: pthread_create@* (in
/usr/lib/valgrind/x86-linux/vgpreload_helgrind.so)
==30432==    by 0x80485BE: main (in /home/bmodra/z)
started all
Done
==30432==
==30432== ERROR SUMMARY: 16 errors from 1 contexts (suppressed: 43 from 2)



--
Brian Modra   Land line: +27 23 5411 462
Mobile: +27 79 69 77 082
5 Jan Louw Str, Prince Albert, 6930
Postal: P.O. Box 2, Prince Albert 6930
South Africa
http://www.zwartberg.com/

[z.c]

#include <time.h>
#include <stdio.h>
#include <pthread.h>

void* p_thread_func(void* data)
{
    int* p = (int*)data;
    unsigned i;
    for (i = 0; i < 1000000; i++) {}
    for (i = 0; i < 1000000; i++) {}
    for (i = 0; i < 1000000; i++) {}
    for (i = 0; i < 1000000; i++) {}
    return data;
}


int main(char** args, int argc) {
    int data[20];
    pthread_t thread[20];
    unsigned i;
    for (i = 0; i < 20; i++) {
        int errsv = pthread_create(&thread[i], NULL, p_thread_func, (void*)&data[i]);
        if (errsv) {
            printf("%d failed with %d: '%s'", i, errsv, strerror(errsv));
        }
    }
    printf("started all\n");
    for (i = 0; i < 20; i++) {
        pthread_join(thread[i], NULL);
    }
    printf("Done\n");

}


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Valgrind-users mailing list
Valgrind-users@...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: race condition reported in pthread_create

by Bugzilla from bart.vanassche@gmail.com :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Fri, Oct 9, 2009 at 1:54 PM, Brian Modra <brian@...> wrote:

> in my Open Source project, The Karoo Project, I was rigorously testing
> using helgrind, and consistently got a report of a possible race
> condition in pthread_create. This seemed strange, and I checked out
> the address it was reporting, which turned out to be a variable
> allocated on the stack inside the call to pthread_create, or in a
> function it called inside the pthreads library.
>
> So I created a test program which does reproduce the same race
> condition waring. (Attached)
> To compile and test:
> gcc -o z z.c -lpthread
> valgrind --tool=helgrind ./z
>
> Note that if I don't pass the pointer to the element in the data
> array, then there is no race condition reported.
> But this memory is not written or read anywhere in my program.
>
> I wonder if anyone else has experienced this... I need to work out if
> this is a valgrind bug, or a pthreads bug, or am I missing something?

The race reported by Helgrind might be one of the benign races
triggered by the NPTL during thread creation.

As you can see in glibc-2.34567-NPTL-helgrind.supp this file already
contains the following suppression pattern:

{
   helgrind-glibc2X-109
   Helgrind:Race
   fun:start_thread
}

What you can do is to add a suppression pattern for the output you
posted, create a bug report and include the new suppression pattern in
your bug report.

Bart.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Valgrind-users mailing list
Valgrind-users@...
https://lists.sourceforge.net/lists/listinfo/valgrind-users