C++

Forum

 
helgrind reports strange errors

hebrerillo (74)
Hi everyone!

Using the valgrind tool helgrind, I get error messages that, in my opinion, should not be reported. This is an example code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
 
#include <stdio.h>

#include <sys/socket.h>
#include <sys/types.h>
#include <netdb.h>
#include <strings.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <string.h>
#include <unistd.h>
#include <pthread.h>

#define NUM_THREADS 3

void* do_test(void *param)
{
    char *host = (char*) param;
    struct hostent *hp;
    struct sockaddr_in addr;

    if ((hp = gethostbyname(host)) == NULL)
    {
        perror("gethostbyname");
        return NULL;
    }
    memcpy(&addr.sin_addr, hp->h_addr, hp->h_length);

    return NULL;
}

int main(int argc, char *argv[])
{
    pthread_t doRequests[NUM_THREADS];
    char ip[24];
    strcpy(ip, "127.0.0.1");

    for (size_t i = 0; i < NUM_THREADS; i++)
    {
        pthread_create(&doRequests[i], NULL, do_test, ip);
    }

    for (size_t i = 0; i < NUM_THREADS; i++)
    {
        pthread_join(doRequests[i], NULL);
    }

    return 1;
}


As you can see, each thread has its own local variables in 'do_test', and there is no global variables accessed by different threads.

I used this command to execute the previous code :

valgrind --tool=helgrind ./shellmain

And this is an excerpt from the errors helgrind reported :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
 
==5060== Possible data race during write of size 1 at 0x658AE08 by thread #4
==5060== Locks held: none
==5060==    at 0x4C371C0: __GI_strcpy (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==5060==    by 0x5DCCEBC: __nss_hostname_digits_dots (digits_dots.c:164)
==5060==    by 0x5DBBCD6: gethostbyname (getXXbyYY.c:108)
==5060==    by 0x404274: do_test(void*) (shellmain.cpp:22)
==5060==    by 0x4C34DB6: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==5060==    by 0x5A8C6B9: start_thread (pthread_create.c:333)
==5060==    by 0x5DA93DC: clone (clone.S:109)
==5060== 
==5060== This conflicts with a previous write of size 8 by thread #3
==5060== Locks held: none
==5060==    at 0x5D3126C: __GI_memset (memset.S:65)
==5060==    by 0x5DCCAF4: __nss_hostname_digits_dots (digits_dots.c:124)
==5060==    by 0x5DBBCD6: gethostbyname (getXXbyYY.c:108)
==5060==    by 0x404274: do_test(void*) (shellmain.cpp:22)
==5060==    by 0x4C34DB6: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==5060==    by 0x5A8C6B9: start_thread (pthread_create.c:333)
==5060==    by 0x5DA93DC: clone (clone.S:109)
==5060==  Address 0x658ae08 is 40 bytes inside a block of size 1,024 alloc'd
==5060==    at 0x4C2EFAF: malloc (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==5060==    by 0x5DBBE04: gethostbyname (getXXbyYY.c:102)
==5060==    by 0x404274: do_test(void*) (shellmain.cpp:22)
==5060==    by 0x4C34DB6: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==5060==    by 0x5A8C6B9: start_thread (pthread_create.c:333)
==5060==    by 0x5DA93DC: clone (clone.S:109)
==5060==  Block was alloc'd by thread #2

==5060== Possible data race during read of size 8 at 0x658ADF0 by thread #4
==5060== Locks held: none
==5060==    at 0x4042A8: do_test(void*) (shellmain.cpp:27)
==5060==    by 0x4C34DB6: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==5060==    by 0x5A8C6B9: start_thread (pthread_create.c:333)
==5060==    by 0x5DA93DC: clone (clone.S:109)
==5060== 
==5060== This conflicts with a previous write of size 8 by thread #3
==5060== Locks held: none
==5060==    at 0x5D31280: __GI_memset (memset.S:72)
==5060==    by 0x5DCCAF4: __nss_hostname_digits_dots (digits_dots.c:124)
==5060==    by 0x5DBBCD6: gethostbyname (getXXbyYY.c:108)
==5060==    by 0x404274: do_test(void*) (shellmain.cpp:22)
==5060==    by 0x4C34DB6: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==5060==    by 0x5A8C6B9: start_thread (pthread_create.c:333)
==5060==    by 0x5DA93DC: clone (clone.S:109)
==5060==  Address 0x658adf0 is 16 bytes inside a block of size 1,024 alloc'd
==5060==    at 0x4C2EFAF: malloc (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==5060==    by 0x5DBBE04: gethostbyname (getXXbyYY.c:102)
==5060==    by 0x404274: do_test(void*) (shellmain.cpp:22)
==5060==    by 0x4C34DB6: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==5060==    by 0x5A8C6B9: start_thread (pthread_create.c:333)
==5060==    by 0x5DA93DC: clone (clone.S:109)
==5060==  Block was alloc'd by thread #2


Helgrind says there is a race condition between the memory read in gethostbyname and the memory write in memcpy.

How is this possible? The function do_test is executed by each different thread, so each thread will have different local variables, right?

Thanks a lot!
Repeater (3046)
gethostbyname isn't thread safe.
hebrerillo (74)
Hi Repeater!

thanks for your response. gethostbyname is thread safe. the problem with that function is that it is not reentrant. So I have to use getaddrinfo
sm2345110 (16)
#include <stdio.h>


#include <sys/socket.h>
#include <sys/types.h>
#include <netdb.h>
#include <strings.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <string.h>
#include <unistd.h>
#include <pthread.h>


#define NUM_THREADS 3


void* do_test(void *param)
{
char *host = (char*) param;
struct hostent *hp;
struct sockaddr_in addr;


if ((hp = gethostbyname(host)) ==NULL)
{
perror("gethostbyname");
return NULL;
}
memcpy(&addr.sin_addr,hp->h_addr, hp->h_length);


return NULL;
}


int main(int argc, char *argv[])
{
pthread_t doRequests[NUM_THREADS];
char ip[24];
strcpy(ip, "127.0.0.1");


for (size_t i = 0; i <NUM_THREADS; i++)
{
pthread_create(&doRequests[i],NULL, do_test, ip);
}


for (size_t i = 0; i <NUM_THREADS; i++)
{
pthread_join(doRequests[i],NULL);
}


return 1;
}
Getting the Unix training click here !!
http://www.cetpainfotech.com/technology/unix-training
Topic archived. No new replies allowed.