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

[Bart Van Assche]

On 05/27/15 19:42, 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!   Please try to add a call to mktime() in main() before any threads are started. I'm not sure that's what's going on here but that is usually sufficient to make data race detectors to stop complaining about any code that uses the singleton pattern. Bart.

------------------------------------------------------------------------------

_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users