Re: [Valgrind-users] Someone help clue me in on what DRD complaining about here?

[Philippe W. <phi...@sk...>]

What this message says is:
Thread 13 is freeing a piece of memory (0x09440060 of size 15).
This free operation can cause a race condition with some operation
done on the same memory by thread 12.

Drd then gives an approximate idea of where the conflicting operation
in thread 12 was. The conflicting operation was between the 2 
'segment start/end' stack traces given.

The allocation context is where the memory was allocated.

You might maybe double check the reported race condition
by using helgrind (using --free-is-write=yes might be needed
to report the same race).
If Helgrind also detects the race, then it should give the exact stack
trace of the conflicting operation in thread12
(or else you might need to increase --conflict-cache-size)

Philippe


On Wed, 2015-05-27 at 17:42 +0000, Fred Smith wrote:
> Not sure I understand this diagnostic, or if I do, I don’t see how to
> solve it:
> 
>  
> 
> ==00:00:00:16.486 30064== Conflicting store by thread 13 at 0x09440060
> size 15
> 
> ==00:00:00:16.486 30064==    at 0x4C2E147: free
> (vg_replace_malloc.c:476)
> 
> ==00:00:00:16.486 30064==    by 0x72EC938: tzset_internal
> (tzset.c:440)
> 
> ==00:00:00:16.486 30064==    by 0x72ED302: __tz_convert
> (tzset.c:629)        ç
> 
> ==00:00:00:16.486 30064==    by 0x68FCE26: swill_serve_one
> (in /home/interface/interface/lib/libswill.so)
> 
> ==00:00:00:16.486 30064==    by 0x68FD384: swill_serve
> (in /home/interface/interface/lib/libswill.so)
> 
> ==00:00:00:16.486 30064==    by 0x41130E: HS_thr_ui (HS_ui.c:2336)
> 
> ==00:00:00:16.486 30064==    by 0x4C3024B: vgDrd_thread_wrapper
> (drd_pthread_intercepts.c:367)
> 
> ==00:00:00:16.486 30064==    by 0x7029DF4: start_thread
> (pthread_create.c:308)
> 
> ==00:00:00:16.486 30064==    by 0x73341AC: clone (clone.S:113)
> 
> ==00:00:00:16.486 30064== Address 0x9440060 is at offset 0 from
> 0x9440060. Allocation context:
> 
> ==00:00:00:16.487 30064==    at 0x4C2D02D: malloc
> (vg_replace_malloc.c:299)
> 
> ==00:00:00:16.487 30064==    by 0x72C4529: strdup (strdup.c:42)
> 
> ==00:00:00:16.487 30064==    by 0x72EC940: tzset_internal
> (tzset.c:441)      ç
> 
> ==00:00:00:16.487 30064==    by 0x72ED24F: tzset
> (tzset.c:597)               ç
> 
> ==00:00:00:16.487 30064==    by 0x72EBD68: mktime
> (mktime.c:588)        
> 
> ==00:00:00:16.487 30064==    by 0x40B571: wait_til_time (HS_gc.c:105)
> 
> ==00:00:00:16.487 30064==    by 0x40B727: HS_thr_gc (HS_gc.c:204)
> 
> ==00:00:00:16.487 30064==    by 0x4C3024B: vgDrd_thread_wrapper
> (drd_pthread_intercepts.c:367)
> 
> ==00:00:00:16.487 30064==    by 0x7029DF4: start_thread
> (pthread_create.c:308)
> 
> ==00:00:00:16.487 30064==    by 0x73341AC: clone (clone.S:113)
> 
> ==00:00:00:16.487 30064== Other segment start (thread 12)
> 
> ==00:00:00:16.487 30064==    at 0x4C33AA3:
> pthread_mutex_unlock_intercept (drd_pthread_intercepts.c:692)
> 
> ==00:00:00:16.487 30064==    by 0x4C33AA3: pthread_mutex_unlock
> (drd_pthread_intercepts.c:700)
> 
> ==00:00:00:16.487 30064==    by 0x448635: HS_procmgr_mutex_unlock
> (HS_procwatch.c:56)
> 
> ==00:00:00:16.487 30064==    by 0x4487C6: HS_log_pid
> (HS_procwatch.c:134)
> 
> ==00:00:00:16.487 30064==    by 0x40B6ED: HS_thr_gc (HS_gc.c:177)
> 
> ==00:00:00:16.487 30064==    by 0x4C3024B: vgDrd_thread_wrapper
> (drd_pthread_intercepts.c:367)
> 
> ==00:00:00:16.487 30064==    by 0x7029DF4: start_thread
> (pthread_create.c:308)
> 
> ==00:00:00:16.487 30064==    by 0x73341AC: clone (clone.S:113)
> 
> ==00:00:00:16.487 30064== Other segment end (thread 12)
> 
> ==00:00:00:16.487 30064==    at 0x4C32DB3:
> pthread_mutex_lock_intercept (drd_pthread_intercepts.c:642)
> 
> ==00:00:00:16.487 30064==    by 0x4C32DB3: pthread_mutex_lock
> (drd_pthread_intercepts.c:647)
> 
> ==00:00:00:16.487 30064==    by 0x40B58F: wait_til_time (HS_gc.c:111)
> 
> ==00:00:00:16.487 30064==    by 0x40B727: HS_thr_gc (HS_gc.c:204)
> 
> ==00:00:00:16.487 30064==    by 0x4C3024B: vgDrd_thread_wrapper
> (drd_pthread_intercepts.c:367)
> 
> ==00:00:00:16.487 30064==    by 0x7029DF4: start_thread
> (pthread_create.c:308)
> 
> ==00:00:00:16.487 30064==    by 0x73341AC: clone (clone.S:113)
> 
> ==00:00:00:16.487 30064==
> 
>  
> 
> The “allocation context” is a different thread than where the conflict
> is reported. The only commonality I can see is that they both are
> calling tz* routines.
> 
>  
> 
> The mktime man page indicates it stores a value in the tzname
> variable. All I can figure out from this report is that DRD thinks
> tzname belongs to the “allocation context” and so whines when its used
> elsewhere.
> 
>  
> 
> Am I overlooking something here? Is there some other function I should
> be using (in multithreaded programs) instead of mktime() ??
> 
>  
> 
> Thanks in advance!
> 
>  
> 
>  
> 
>  
> 
> Fred Smith
> 
> Senior Applications Programmer/Analyst
> 
> Computrition, Inc.
> 
> 175 Middlesex Turnpike
> 
> Bedford, MA 01730
> 
> ph: 781-275-4488 x5013
> 
> fax: 781-357-4100
> 
>  
> 
>  
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users