On Mon, 2013-09-30 at 15:25 +0000, Phil Longstaff wrote:
> I just got the following report:
> 
> ==83343== Possible data race during read of size 2 at 0xA38C41A by
> thread #2
> 
> ==83343== Locks held: 3, at addresses 0x2ED6EA0 0x999FD38 0xA389AB8
> 
> ==83343==    at 0x62911E7: strcpy (in /lib/libc.so.7)
> 
> ==83343==    by 0x1F52C97: spr_socket_get_addr (spr_socket.c:87)
> 
> ==83343==    by 0x1F4D787:
> spr_evsportnw_sync_connect_ready_event_handler (spr_evsportnw.c:507)
> 
> ==83343==    by 0x1F4C48C: spr_evsdisp_dispatch (spr_evsdisp.c:736)
> 
> ==83343==    by 0x1F601C7: io_connection_connect (ioc.c:629)
> 
> ==83343==
> 
> ==83343== This conflicts with a previous write of size 8 by thread #47
> 
> ==83343== Locks held: 3, at addresses 0x63E4308 0x8B97D50 0x6FA5420
> 
> ==83343==    at 0x629717C: __sys_read (in /lib/libc.so.7)
> 
> ==83343==    by 0x6296BFF: __sread (in /lib/libc.so.7)
> 
> ==83343==    by 0x6296952: _sread (in /lib/libc.so.7)
> 
> ==83343==    by 0x627FF35: __srefill (in /lib/libc.so.7)
> 
> ==83343==    by 0x6263B83: __svfscanf (in /lib/libc.so.7)
> 
> ==83343==    by 0x6262C88: fscanf (in /lib/libc.so.7)
> 
> ==83343==    by 0x1BFD4BB: doModuleMapping(unsigned int, int*, bool)
> (hardware.cpp:406)
> 
>  
> 
> The code in spr_socket.c is:
> 
>   char * _this_addr;
> 
>   char * t = …;
> 
>  
> 
>   _this_addr = strcpy((char*)malloc(strlen(t)+1),t);
> 
>   sprintf(r,"%s",_this_addr);                                ç This is
> line 87
The stack trace of the error above shows a call to strcpy, not a call to
sprintf ?
Are you sure the read problem is not caused by reading bytes behind
char *t as part of the strcpy call ?

> 
>   free(_this_addr);
> 
>  
> 
> So, it’s complaining about a read from memory which has been newly
> malloc’ed.  Bug?  Could the other piece of code this has a conflict
> with still be holding on to it and therefore helgrind hasn’t cleared
> its history for these bytes in the heap?
> 
>  
> 
> This is with valgrind 3.8.0 on freebsd.
If the code works on linux, maybe double check on a linux system ?
And/or double check with drd ?

Philippe




------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Reply via email to