Re: [Valgrind-users] Someone help clue me in on what DRD complaining about here?
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
[Valgrind-users] Someone help clue me in on what DRD complaining about here?
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
Re: [Valgrind-users] Someone help clue me in on what DRD complaining about here?
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 +, 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
