You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
1
(1) |
2
(13) |
3
(1) |
|
4
(1) |
5
(11) |
6
|
7
|
8
(3) |
9
(18) |
10
(7) |
|
11
(21) |
12
(26) |
13
(16) |
14
(17) |
15
(14) |
16
(6) |
17
(6) |
|
18
(17) |
19
(1) |
20
(16) |
21
(1) |
22
(2) |
23
(14) |
24
(7) |
|
25
(6) |
26
(3) |
27
(11) |
28
(9) |
29
(2) |
30
(7) |
31
(3) |
|
From: Philippe W. <phi...@sk...> - 2011-12-16 18:47:25
|
> # gcc -lpthread -o threads threads.c Not too sure the license of this code allows it to be posted .... but ok, I just compiled it, did not read it and have zero intention to use it for any purpose :). > Question the sample has the issues like > 1)accessing like uninitialsed variable. There is a deliberate choice in memcheck (to avoid too many false positive) that just accessing uninit variable does not cause an error. To report an error, the uninit variable access must modify the "external behaviour" of the program. E.g. if you do a "jump" based on this uninit data or use it in a syscall (e.g. write) or use it to compute another address (e.g. when as index in an array), then you will get an error. > 2)write overflow. The tool exp-sgcheck is checking write overflow of stack or global arrays. Philippe |
|
From: Alexander P. <gl...@go...> - 2011-12-16 12:35:57
|
On Fri, Dec 16, 2011 at 4:15 PM, Umesh Kalappa <ume...@gm...> wrote: > Hi All , > > Please attachment(threads.c) for the thread sample ,where sample is > multithread and below is the gcc switches used to compile the sample . > > # gcc -lpthread -o threads threads.c > > Question the sample has the issues like > 1)accessing like uninitialsed variable. > 2)write overflow. > . > why valgrind tools like helgrind/drd or memcheck unable to detect those > errors and here the o.p from them for the attached sample . As far as I can tell, there are no synchronization issues in this program, thus Helgrind and DRD aren't very helpful here (they don't implement the Memcheck functionality, otherwise the instrumentation should've become too heavy). The third and fourth threads contain out of bound accesses to stack and global variables. In the general case it is impossible to handle those using dynamic instrumentation. Sometimes such errors can be caught statically with Clang (http://clang.llvm.org), for more complex cases you can take a look at AddressSanitizer (http://code.google.com/p/address-sanitizer), which instruments the code at compile time and then detects the errors at runtime. The second thread contains a leak which is correctly detected by Memcheck. Regarding the first thread -- are you sure the variable wasn't optimized out? (the volatile keyword should help to make sure) HTH, Alex |
|
From: Umesh K. <ume...@gm...> - 2011-12-16 12:16:01
|
Hi All ,
Please attachment(threads.c) for the thread sample ,where sample is
multithread and below is the gcc switches used to compile the sample .
# gcc -lpthread -o threads threads.c
Question the sample has the issues like
1)accessing like uninitialsed variable.
2)write overflow.
.
why valgrind tools like helgrind/drd or memcheck unable to detect those
errors and here the o.p from them for the attached sample .
==7969== Memcheck, a memory error detector
==7969== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==7969== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==7969== Command: ./threads
==7969==
*
**
****
***
==7969==
==7969== HEAP SUMMARY:
==7969== in use at exit: 1 bytes in 1 blocks
==7969== total heap usage: 5 allocs, 4 frees, 1,089 bytes allocated
==7969==
==7969== 1 bytes in 1 blocks are definitely lost in loss record 1 of 1
==7969== at 0x4A0610C: malloc (vg_replace_malloc.c:195)
==7969== by 0x4006D5: second_thread (in
/home/umesh/valgrind/c/datarace/threads)
==7969== by 0x33F90062E6: start_thread (in /lib64/libpthread-2.5.so)
==7969== by 0x33F84CE3BC: clone (in /lib64/libc-2.5.so)
==7969==
==7969== LEAK SUMMARY:
==7969== definitely lost: 1 bytes in 1 blocks
==7969== indirectly lost: 0 bytes in 0 blocks
==7969== possibly lost: 0 bytes in 0 blocks
==7969== still reachable: 0 bytes in 0 blocks
==7969== suppressed: 0 bytes in 0 blocks
==7969==
==7969== For counts of detected and suppressed errors, rerun with: -v
==7969== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)
Helgrind output
[umesh@localhost datarace]$ vi threads.c
[umesh@localhost datarace]$ valgrind --tool=helgrind ./threads
==7979== Helgrind, a thread error detector
==7979== Copyright (C) 2007-2009, and GNU GPL'd, by OpenWorks LLP et al.
==7979== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==7979== Command: ./threads
==7979==
*
**
***
****
==7979==
==7979== For counts of detected and suppressed errors, rerun with: -v
==7979== Use --history-level=approx or =none to gain increased speed, at
==7979== the cost of reduced accuracy of conflicting-access information
==7979== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 79 from 70)
Did i missing something here ,Please any comments are welcomed
Thanks
~Umesh
|
|
From: Umesh K. <ume...@gm...> - 2011-12-16 12:03:13
|
Hi Bjoern,
That make sense and thanks for your valuable inputs ..
Thanks
~Umesh
On Fri, Dec 16, 2011 at 4:30 PM, Bjoern Doebel <bjo...@go...
> wrote:
> > #include <pthread.h>
> > #include<stdio.h>
> > int food =0 ;
> > pthread_mutex_t foodlock;
> >
> > int child_fn ( ) {
> > pthread_mutex_lock(&foodlock);
> > if (food>=0) {
> > food++;
> > }
> > pthread_mutex_unlock(&foodlock);
> > return food; //Read without lock ...Which may return with
> > un-predictable value here ....
> >
> > }
> >
> >
> > int main ( void ) {
> > pthread_t child;
> > pthread_create(&child, NULL, child_fn, NULL);
> > pthread_join(child, NULL);
> > return 0;
> > }
> >
> >
> > Did you guys find any datarace issue in the above code ,If so why is
> > valgrind with helgrind or drd tool unable to find the same ..please
> find
> > the below report from valgrind
>
> Your program only runs the racy function in a single thread. There is
> by definition no data race in such execution. A slight modification
> yields the valid race error:
>
>
> #include <pthread.h>
> #include<stdio.h>
> int food =0 ;
> pthread_mutex_t foodlock;
>
> void* child_fn ( void*) {
> pthread_mutex_lock(&foodlock);
> if (food>=0) {
> food++;
> }
> pthread_mutex_unlock(&foodlock);
> return (void*)food; //Read without lock ...Which may return
> with un-predictable value here ....
>
> }
>
>
> int main ( void ) {
> pthread_t child, child2;
> pthread_create(&child, NULL, child_fn, NULL);
> pthread_create(&child2, NULL, child_fn, NULL);
> pthread_join(child, NULL);
> pthread_join(child2, NULL);
> return 0;
> }
>
>
>
> ==30866== Helgrind, a thread error detector
> ==30866== Copyright (C) 2007-2011, and GNU GPL'd, by OpenWorks LLP et al.
> ==30866== Using Valgrind-3.8.0.SVN and LibVEX; rerun with -h for copyright
> info
> ==30866== Command: ./t
> ==30866==
> ==30866== ---Thread-Announcement------------------------------------------
> ==30866==
> ==30866== Thread #3 was created
> ==30866== at 0x413E0B8: clone (clone.S:111)
> ==30866==
> ==30866== ---Thread-Announcement------------------------------------------
> ==30866==
> ==30866== Thread #2 was created
> ==30866== at 0x413E0B8: clone (clone.S:111)
> ==30866==
> ==30866== ----------------------------------------------------------------
> ==30866==
> ==30866== Lock at 0x804A02C was first observed
> ==30866== at 0x402BAE6: pthread_mutex_lock (hg_intercepts.c:495)
> ==30866== by 0x8048515: child_fn(void*) (test.cc:7)
> ==30866== by 0x402B7B0: mythread_wrapper (hg_intercepts.c:219)
> ==30866== by 0x4057D30: s==30866== This conflicts with a previous
> read of size 4 by thread #2
> ==30866== Locks held: none
> ==30866== at 0x8048538: child_fn(void*) (test.cc:12)
> ==30866== by 0x402B7B0: mythread_wrapper (hg_intercepts.c:219)
> ==30866== by 0x4057D30: start_thread (pthread_create.c:304)
> ==30866== by 0x413E0CD: clone (clone.S:130)
> ==30866==
> ==30866==
> ==30866== For counts of detected and suppressed errors, rerun with: -v
> ==30866== Use --history-level=approx or =none to gain increased speed, at
> ==30866== the cost of reduced accuracy of conflicting-access information
> ==30866== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 9 from 9)
> tart_thread (pthread_create.c:304)
> ==30866== by 0x413E0CD: clone (clone.S:130)
> ==30866==
> ==30866== Possible data race during write of size 4 at 0x804A028 by thread
> #3
> ==30866== Locks held: 1, at address 0x804A02C
> ==30866== at 0x8048527: child_fn(void*) (test.cc:9)
> ==30866== by 0x402B7B0: mythread_wrapper (hg_intercepts.c:219)
> ==30866== by 0x4057D30: start_thread (pthread_create.c:304)
> ==30866== by 0x413E0CD: clone (clone.S:130)
> ==30866==
>
|
|
From: Bart V. A. <bva...@ac...> - 2011-12-16 11:28:06
|
On Thu, Dec 15, 2011 at 1:45 PM, Umesh Kalappa <ume...@gm...> wrote:
> I'm newbie to valgrind and was trying my hands on the tool "helgrind" with
> below samples .
>
> #include <pthread.h>
> #include<stdio.h>
> int food =0 ;
> pthread_mutex_t foodlock;
>
> int child_fn ( ) {
> pthread_mutex_lock(&foodlock);
> if (food>=0) {
> food++;
> }
> pthread_mutex_unlock(&foodlock);
> return food; //Read without lock ...Which may return with
> un-predictable value here ....
>
> }
>
> int main ( void ) {
> pthread_t child;
> pthread_create(&child, NULL, child_fn, NULL);
> pthread_join(child, NULL);
> return 0;
> }
>
>
> Did you guys find any datarace issue in the above code ,If so why is
> valgrind with helgrind or drd tool unable to find the same ..please find
> the below report from valgrind
Helgrind and DRD check for unordered accesses issued by different
threads. Your program does not trigger any such unordered accesses and
that is why neither Helgrind nor DRD complains.
There exists another class of data-race detection tools that reports
all accesses of shared variables that are not consistently protected
by locking. A disadvantage of these tools is that these can report a
large number of false positive reports.
More information can be found here:
http://valgrind.org/docs/manual/drd-manual.html#drd-manual.data-race-detection.
Bart.
|
|
From: Bjoern D. <bjo...@go...> - 2011-12-16 11:00:54
|
> #include <pthread.h>
> #include<stdio.h>
> int food =0 ;
> pthread_mutex_t foodlock;
>
> int child_fn ( ) {
> pthread_mutex_lock(&foodlock);
> if (food>=0) {
> food++;
> }
> pthread_mutex_unlock(&foodlock);
> return food; //Read without lock ...Which may return with
> un-predictable value here ....
>
> }
>
>
> int main ( void ) {
> pthread_t child;
> pthread_create(&child, NULL, child_fn, NULL);
> pthread_join(child, NULL);
> return 0;
> }
>
>
> Did you guys find any datarace issue in the above code ,If so why is
> valgrind with helgrind or drd tool unable to find the same ..please find
> the below report from valgrind
Your program only runs the racy function in a single thread. There is
by definition no data race in such execution. A slight modification
yields the valid race error:
#include <pthread.h>
#include<stdio.h>
int food =0 ;
pthread_mutex_t foodlock;
void* child_fn ( void*) {
pthread_mutex_lock(&foodlock);
if (food>=0) {
food++;
}
pthread_mutex_unlock(&foodlock);
return (void*)food; //Read without lock ...Which may return
with un-predictable value here ....
}
int main ( void ) {
pthread_t child, child2;
pthread_create(&child, NULL, child_fn, NULL);
pthread_create(&child2, NULL, child_fn, NULL);
pthread_join(child, NULL);
pthread_join(child2, NULL);
return 0;
}
==30866== Helgrind, a thread error detector
==30866== Copyright (C) 2007-2011, and GNU GPL'd, by OpenWorks LLP et al.
==30866== Using Valgrind-3.8.0.SVN and LibVEX; rerun with -h for copyright info
==30866== Command: ./t
==30866==
==30866== ---Thread-Announcement------------------------------------------
==30866==
==30866== Thread #3 was created
==30866== at 0x413E0B8: clone (clone.S:111)
==30866==
==30866== ---Thread-Announcement------------------------------------------
==30866==
==30866== Thread #2 was created
==30866== at 0x413E0B8: clone (clone.S:111)
==30866==
==30866== ----------------------------------------------------------------
==30866==
==30866== Lock at 0x804A02C was first observed
==30866== at 0x402BAE6: pthread_mutex_lock (hg_intercepts.c:495)
==30866== by 0x8048515: child_fn(void*) (test.cc:7)
==30866== by 0x402B7B0: mythread_wrapper (hg_intercepts.c:219)
==30866== by 0x4057D30: s==30866== This conflicts with a previous
read of size 4 by thread #2
==30866== Locks held: none
==30866== at 0x8048538: child_fn(void*) (test.cc:12)
==30866== by 0x402B7B0: mythread_wrapper (hg_intercepts.c:219)
==30866== by 0x4057D30: start_thread (pthread_create.c:304)
==30866== by 0x413E0CD: clone (clone.S:130)
==30866==
==30866==
==30866== For counts of detected and suppressed errors, rerun with: -v
==30866== Use --history-level=approx or =none to gain increased speed, at
==30866== the cost of reduced accuracy of conflicting-access information
==30866== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 9 from 9)
tart_thread (pthread_create.c:304)
==30866== by 0x413E0CD: clone (clone.S:130)
==30866==
==30866== Possible data race during write of size 4 at 0x804A028 by thread #3
==30866== Locks held: 1, at address 0x804A02C
==30866== at 0x8048527: child_fn(void*) (test.cc:9)
==30866== by 0x402B7B0: mythread_wrapper (hg_intercepts.c:219)
==30866== by 0x4057D30: start_thread (pthread_create.c:304)
==30866== by 0x413E0CD: clone (clone.S:130)
==30866==
|