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 Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
