You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
1
(4) |
2
(6) |
3
(6) |
4
(4) |
5
(3) |
|
6
(1) |
7
(9) |
8
(1) |
9
(2) |
10
(7) |
11
(9) |
12
|
|
13
(1) |
14
(1) |
15
(6) |
16
(6) |
17
(4) |
18
(8) |
19
(2) |
|
20
(4) |
21
(3) |
22
(3) |
23
(2) |
24
(1) |
25
(7) |
26
|
|
27
(1) |
28
(4) |
|
|
|
|
|
|
From: John R. <jr...@bi...> - 2011-02-07 15:11:37
|
On 02/07/2011 06:10 AM, Wan Mohd Fairuz Wan Ismail wrote: > Since Valgrind use synthetic CPU, can it analyze a cross compiled programs? eg: an ARM compiled programs tested with Valgrind installed on a x86 machine. No. The host and the target must have the same basic architecture. The setting of the CPU integer flags (Negative, Zero, Overflow, Carry), the details of floating point computation, and the system call interface are not so easily emulated as are FETCH, STORE, ADD, OR. For the particular case of ARM vs x86, ARM has the Carry flag backwards on all subtract operations. (ARM subtract-with-borrow does not interoperate with ARM add-with-carry.) -- |
|
From: Wan M. F. W. I. <wan...@mc...> - 2011-02-07 14:10:16
|
Since Valgrind use synthetic CPU, can it analyze a cross compiled programs? eg: an ARM compiled programs tested with Valgrind installed on a x86 machine. Thanks -- Wan Mohd Fairuz WAN ISMAIL |
|
From: Konstantin S. <kon...@gm...> - 2011-02-07 13:05:46
|
On Mon, Feb 7, 2011 at 2:59 PM, Bart Van Assche <bva...@ac...> wrote: > On Mon, Feb 7, 2011 at 9:28 AM, Konstantin Serebryany < > kon...@gm...> wrote: > >> >> On Sun, Feb 6, 2011 at 10:14 PM, Bart Van Assche <bva...@ac...>wrote: >> >>> On Sat, Feb 5, 2011 at 5:54 PM, Konstantin Serebryany < >>> kon...@gm...> wrote: >>> >>>> >>>> On Sat, Feb 5, 2011 at 7:36 PM, Bart Van Assche <bva...@ac...>wrote: >>>> >>>>> On Sat, Feb 5, 2011 at 2:22 PM, Konstantin Serebryany < >>>>> kon...@gm...> wrote: >>>>> >>>>>> FYI >>>>>> ThreadSanitizer will not report anything on this test, even with >>>>>> --free-is-write (which is on by default) because this tool assumes the >>>>>> malloc implementation to be correct and ignores every access inside malloc >>>>>> and friends. >>>>>> I haven't seen any false positives due to --free-is-write (in >>>>>> ThreadSanitizer) over last ~6 months, but we found tons of real races with >>>>>> this flag. Just a fresh example: >>>>>> http://code.google.com/p/chromium/issues/detail?id=72042 >>>>>> >>>>> >>>>> Hello Konstantin, >>>>> >>>>> Has that --free-is-write feature already been tested in combination >>>>> with custom memory allocators ? >>>>> >>>> What kind of custom memory allocators? >>>> We regularly run it with programs linked against tcmalloc. >>>> >>> >>> Hello Konstantin, >>> >>> With "custom memory allocators" I was referring to those using the >>> VG_USERREQ__MALLOCLIKE_BLOCK and VG_USERREQ__FREELIKE_BLOCK client requests >>> and not to those that replace malloc() like e.g. tcmalloc. >>> >> >> ThreadSanitizer does not support VG_USERREQ__FREELIKE_BLOCK -- never >> found a use for it yet. >> However if a program uses a lot of custom free lists it could be useful >> (and it will be trivial to implement). >> > > Hello Konstantin, > > Sure, I don't doubt that implementing support for > VG_USERREQ__FREELIKE_BLOCK in TS would be trivial to implement. What might > be hard to implement regarding --free-is-write is to ignore the memory > accesses inside the custom allocator. Why? Just use ANNOTATE_IGNORE_READS_AND_WRITES_BEGIN/END This will of course hide races if the custom allocator itself is buggy. --kcc > This is because such a custom allocator issues VG_USERREQ__MALLOCLIKE_BLOCK > after it has finished updating its internal data structures and because the > tool is not informed when the custom memory allocator in the client starts > updating its internal data structures. > > Bart. > |
|
From: Bart V. A. <bva...@ac...> - 2011-02-07 12:00:02
|
On Mon, Feb 7, 2011 at 9:28 AM, Konstantin Serebryany < kon...@gm...> wrote: > > On Sun, Feb 6, 2011 at 10:14 PM, Bart Van Assche <bva...@ac...>wrote: > >> On Sat, Feb 5, 2011 at 5:54 PM, Konstantin Serebryany < >> kon...@gm...> wrote: >> >>> >>> On Sat, Feb 5, 2011 at 7:36 PM, Bart Van Assche <bva...@ac...>wrote: >>> >>>> On Sat, Feb 5, 2011 at 2:22 PM, Konstantin Serebryany < >>>> kon...@gm...> wrote: >>>> >>>>> FYI >>>>> ThreadSanitizer will not report anything on this test, even with >>>>> --free-is-write (which is on by default) because this tool assumes the >>>>> malloc implementation to be correct and ignores every access inside malloc >>>>> and friends. >>>>> I haven't seen any false positives due to --free-is-write (in >>>>> ThreadSanitizer) over last ~6 months, but we found tons of real races with >>>>> this flag. Just a fresh example: >>>>> http://code.google.com/p/chromium/issues/detail?id=72042 >>>>> >>>> >>>> Hello Konstantin, >>>> >>>> Has that --free-is-write feature already been tested in combination with >>>> custom memory allocators ? >>>> >>> What kind of custom memory allocators? >>> We regularly run it with programs linked against tcmalloc. >>> >> >> Hello Konstantin, >> >> With "custom memory allocators" I was referring to those using the >> VG_USERREQ__MALLOCLIKE_BLOCK and VG_USERREQ__FREELIKE_BLOCK client requests >> and not to those that replace malloc() like e.g. tcmalloc. >> > > ThreadSanitizer does not support VG_USERREQ__FREELIKE_BLOCK -- never found > a use for it yet. > However if a program uses a lot of custom free lists it could be useful > (and it will be trivial to implement). > Hello Konstantin, Sure, I don't doubt that implementing support for VG_USERREQ__FREELIKE_BLOCK in TS would be trivial to implement. What might be hard to implement regarding --free-is-write is to ignore the memory accesses inside the custom allocator. This is because such a custom allocator issues VG_USERREQ__MALLOCLIKE_BLOCK after it has finished updating its internal data structures and because the tool is not informed when the custom memory allocator in the client starts updating its internal data structures. Bart. |
|
From: Wan M. F. W. I. <wan...@mc...> - 2011-02-07 09:15:27
|
Hi, I'm getting this error while trying to cross compile valgrind for PandaBoard (armv7 architecture). m_debuglog.c: In function ‘add_to_buf’: m_debuglog.c:242: error: unknown register name ‘r7’ in ‘asm’ m_debuglog.c:242: error: unknown register name ‘r2’ in ‘asm’ m_debuglog.c:242: error: unknown register name ‘r1’ in ‘asm’ m_debuglog.c:242: error: unknown register name ‘r0’ in ‘asm’ m_debuglog.c: In function ‘vgPlain_debugLog’: m_debuglog.c:261: error: unknown register name ‘r7’ in ‘asm’ m_debuglog.c:261: error: unknown register name ‘r0’ in ‘asm’ m_debuglog.c:242: error: unknown register name ‘r7’ in ‘asm’ m_debuglog.c:242: error: unknown register name ‘r2’ in ‘asm’ m_debuglog.c:242: error: unknown register name ‘r1’ in ‘asm’ m_debuglog.c:242: error: unknown register name ‘r0’ in ‘asm’ This is my configure options: ./configure --prefix=/opt/valgrind --host=armv7-none-linux-gnueabi --target=arm-none-linux-gnueabi It failed in the make process. Does anyone have some ideas about these errors? Thanks a lot. -- Wan Mohd Fairuz WAN ISMAIL |
|
From: Konstantin S. <kon...@gm...> - 2011-02-07 08:32:29
|
On Sun, Feb 6, 2011 at 10:14 PM, Bart Van Assche <bva...@ac...> wrote: > On Sat, Feb 5, 2011 at 5:54 PM, Konstantin Serebryany < > kon...@gm...> wrote: > >> >> On Sat, Feb 5, 2011 at 7:36 PM, Bart Van Assche <bva...@ac...>wrote: >> >>> On Sat, Feb 5, 2011 at 2:22 PM, Konstantin Serebryany < >>> kon...@gm...> wrote: >>> >>>> FYI >>>> ThreadSanitizer will not report anything on this test, even with >>>> --free-is-write (which is on by default) because this tool assumes the >>>> malloc implementation to be correct and ignores every access inside malloc >>>> and friends. >>>> I haven't seen any false positives due to --free-is-write (in >>>> ThreadSanitizer) over last ~6 months, but we found tons of real races with >>>> this flag. Just a fresh example: >>>> http://code.google.com/p/chromium/issues/detail?id=72042 >>>> >>> >>> Hello Konstantin, >>> >>> Has that --free-is-write feature already been tested in combination with >>> custom memory allocators ? >>> >> What kind of custom memory allocators? >> We regularly run it with programs linked against tcmalloc. >> > > Hello Konstantin, > > With "custom memory allocators" I was referring to those using the > VG_USERREQ__MALLOCLIKE_BLOCK and VG_USERREQ__FREELIKE_BLOCK client requests > and not to those that replace malloc() like e.g. tcmalloc. > ThreadSanitizer does not support VG_USERREQ__FREELIKE_BLOCK -- never found a use for it yet. However if a program uses a lot of custom free lists it could be useful (and it will be trivial to implement). --kcc > Bart. > > > |
|
From: Bart V. A. <bva...@ac...> - 2011-02-06 19:15:09
|
On Sat, Feb 5, 2011 at 5:54 PM, Konstantin Serebryany < kon...@gm...> wrote: > > On Sat, Feb 5, 2011 at 7:36 PM, Bart Van Assche <bva...@ac...>wrote: > >> On Sat, Feb 5, 2011 at 2:22 PM, Konstantin Serebryany < >> kon...@gm...> wrote: >> >>> FYI >>> ThreadSanitizer will not report anything on this test, even with >>> --free-is-write (which is on by default) because this tool assumes the >>> malloc implementation to be correct and ignores every access inside malloc >>> and friends. >>> I haven't seen any false positives due to --free-is-write (in >>> ThreadSanitizer) over last ~6 months, but we found tons of real races with >>> this flag. Just a fresh example: >>> http://code.google.com/p/chromium/issues/detail?id=72042 >>> >> >> Hello Konstantin, >> >> Has that --free-is-write feature already been tested in combination with >> custom memory allocators ? >> > What kind of custom memory allocators? > We regularly run it with programs linked against tcmalloc. > Hello Konstantin, With "custom memory allocators" I was referring to those using the VG_USERREQ__MALLOCLIKE_BLOCK and VG_USERREQ__FREELIKE_BLOCK client requests and not to those that replace malloc() like e.g. tcmalloc. Bart. |
|
From: Konstantin S. <kon...@gm...> - 2011-02-05 16:55:23
|
On Sat, Feb 5, 2011 at 7:36 PM, Bart Van Assche <bva...@ac...> wrote: > On Sat, Feb 5, 2011 at 2:22 PM, Konstantin Serebryany < > kon...@gm...> wrote: > >> FYI >> ThreadSanitizer will not report anything on this test, even with >> --free-is-write (which is on by default) because this tool assumes the >> malloc implementation to be correct and ignores every access inside malloc >> and friends. >> I haven't seen any false positives due to --free-is-write (in >> ThreadSanitizer) over last ~6 months, but we found tons of real races with >> this flag. Just a fresh example: >> http://code.google.com/p/chromium/issues/detail?id=72042 >> > > Hello Konstantin, > > Has that --free-is-write feature already been tested in combination with > custom memory allocators ? > What kind of custom memory allocators? We regularly run it with programs linked against tcmalloc. --kcc > Bart. > |
|
From: Bart V. A. <bva...@ac...> - 2011-02-05 16:36:39
|
On Sat, Feb 5, 2011 at 2:22 PM, Konstantin Serebryany < kon...@gm...> wrote: > FYI > ThreadSanitizer will not report anything on this test, even with > --free-is-write (which is on by default) because this tool assumes the > malloc implementation to be correct and ignores every access inside malloc > and friends. > I haven't seen any false positives due to --free-is-write (in > ThreadSanitizer) over last ~6 months, but we found tons of real races with > this flag. Just a fresh example: > http://code.google.com/p/chromium/issues/detail?id=72042 > Hello Konstantin, Has that --free-is-write feature already been tested in combination with custom memory allocators ? Bart. |
|
From: Konstantin S. <kon...@gm...> - 2011-02-05 13:22:53
|
FYI ThreadSanitizer will not report anything on this test, even with --free-is-write (which is on by default) because this tool assumes the malloc implementation to be correct and ignores every access inside malloc and friends. I haven't seen any false positives due to --free-is-write (in ThreadSanitizer) over last ~6 months, but we found tons of real races with this flag. Just a fresh example: http://code.google.com/p/chromium/issues/detail?id=72042 --kcc On Fri, Feb 4, 2011 at 10:16 PM, Bart Van Assche <bva...@ac...> wrote: > On Fri, Feb 4, 2011 at 12:16 PM, Andrea Mazzoleni <ama...@gm...> > wrote: > > > > I likely found a problem in the DRD when using the --free-is-write > > option. The following test case reports an huge amount of errors that > > are not expected. > > > > Valgrind and helgrind report no error. > > > > The machine is a Ubuntu 10.4 x86 with valgrind 3.6.0 compiled from > source. > > > > The program is compiled with: gcc -O1 -g -D_REENTRANT multi.c -o > > multi -lpthread > > > > In a big application I have similar strange reports, even without > > using --free-is-write, so maybe --free-is-write is only a way to > > expose the bug. > > The implementation of --free-is-write in DRD is based on the > assumption that all modifications of memory after a call to free() and > before a new malloc() call returns it again are errors. I'm afraid > this assumption is wrong (the memory allocator may touch such memory) > so I have removed the --free-is-write option again. > > Regarding the behavior of DRD with --free-is-write=no: DRD in this > configuration is working reliably for many people since considerable > time. So the issues reported with this configuration are most likely > either application errors or false positives triggered by the > distro-specific libthread or libc implementation. One should keep in > mind that the data race detection algorithms in DRD and Helgrind are > different and hence that both tools may report different data races or > false positives. > > Further feedback for the behavior of DRD with --free-is-write=no is > welcome. > > Bart. > > > ------------------------------------------------------------------------------ > The modern datacenter depends on network connectivity to access resources > and provide services. The best practices for maximizing a physical server's > connectivity to a physical network are well understood - see how these > rules translate into the virtual world? > http://p.sf.net/sfu/oracle-sfdevnlfb > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > > > |
|
From: Bart V. A. <bva...@ac...> - 2011-02-04 19:16:35
|
On Fri, Feb 4, 2011 at 12:16 PM, Andrea Mazzoleni <ama...@gm...> wrote: > > I likely found a problem in the DRD when using the --free-is-write > option. The following test case reports an huge amount of errors that > are not expected. > > Valgrind and helgrind report no error. > > The machine is a Ubuntu 10.4 x86 with valgrind 3.6.0 compiled from source. > > The program is compiled with: gcc -O1 -g -D_REENTRANT multi.c -o > multi -lpthread > > In a big application I have similar strange reports, even without > using --free-is-write, so maybe --free-is-write is only a way to > expose the bug. The implementation of --free-is-write in DRD is based on the assumption that all modifications of memory after a call to free() and before a new malloc() call returns it again are errors. I'm afraid this assumption is wrong (the memory allocator may touch such memory) so I have removed the --free-is-write option again. Regarding the behavior of DRD with --free-is-write=no: DRD in this configuration is working reliably for many people since considerable time. So the issues reported with this configuration are most likely either application errors or false positives triggered by the distro-specific libthread or libc implementation. One should keep in mind that the data race detection algorithms in DRD and Helgrind are different and hence that both tools may report different data races or false positives. Further feedback for the behavior of DRD with --free-is-write=no is welcome. Bart. |
|
From: Steve S. <ste...@gm...> - 2011-02-04 17:27:15
|
On Thu, Feb 3, 2011 at 6:43 AM, Julian Seward <js...@ac...> wrote: > > >> No, he is passing that struct as mtext. > > >> > > >> The problem is that the struct has padding, which he won't be > > >> initialising. > > > > > > I assume he memsets the whole struct, so padding should also be > > > initialized? > > > > Why would you presume that? I would say that it's pretty clear that he > > isn't, or he wouldn't get the warning from valgrind! > > Well, he did say that in the original msg, although it's ambiguous. > If the whole struct is memset-0'd then the padding should all be > initialised. memset-0-ing the fields individually obviously won't > help. > > Steve, try (1) memset-0-ing the entire structure, and (2) using > --track-origins=yes Thanks for the replies everyone! To answer the earlier questions, yes I am passing the struct as mtext and yes I am memset-ing to 0 the entire structure so any padding should be automatically zero'd out. Here's a code fragment: memset (&my_message, 0x00, sizeof (f_msg)); my_message.mtype = 1; my_message.quit_type = quitID; my_message.quit_msg = NULL; my_message.prolong = 7; my_message.prolong_count = get_p_ct (local_prolong); my_message.prolong_type = get_p_type (local_prolong); Running with track-origins=yes results in a line number that points to the static declaration of my_message at the beginning of the function. ==2662== Uninitialised value was created by a stack allocation Now for the interesting part! It looks like the problem is restricted to the older version of my cross compiler. When I switch to a newer version, I don't see the same warning from valgrind. Thanks again for all your help! |
|
From: Andrea M. <ama...@gm...> - 2011-02-04 11:17:00
|
Hi,
I likely found a problem in the DRD when using the --free-is-write
option. The following test case reports an huge amount of errors that
are not expected.
Valgrind and helgrind report no error.
The machine is a Ubuntu 10.4 x86 with valgrind 3.6.0 compiled from source.
The program is compiled with: gcc -O1 -g -D_REENTRANT multi.c -o
multi -lpthread
In a big application I have similar strange reports, even without
using --free-is-write, so maybe --free-is-write is only a way to
expose the bug.
Here the C program:
#include <pthread.h>
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <pthread.h>
#include <string.h>
static pthread_mutex_t thread_mutex = PTHREAD_MUTEX_INITIALIZER;
unsigned term_count;
#define SIZE 22816
#define N 10
#define M 1000
void* thread_func(void* arg)
{
unsigned i;
for(i=0;i<M;++i) {
void* ptr;
printf("a");
ptr = malloc(SIZE);
printf("s");
memset(ptr, 0, SIZE);
printf("f");
free(ptr);
}
pthread_mutex_lock(&thread_mutex);
++term_count;
pthread_mutex_unlock(&thread_mutex);
pthread_exit(NULL);
return 0;
}
int main(int argc, char **argv)
{
pthread_t thread;
int i;
for (i=0;i<N; i++ ) {
if (pthread_create(&thread, 0, thread_func, 0) != 0) {
abort();
}
}
while (1) {
unsigned curr_term;
pthread_mutex_lock(&thread_mutex);
curr_term = term_count;
pthread_mutex_unlock(&thread_mutex);
if (curr_term == N)
break;
sleep(1);
}
return 0;
}
Here the DRD report:
==391== drd, a thread error detector
==391== Copyright (C) 2006-2010, and GNU GPL'd, by Bart Van Assche.
==391== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
==391== Command: ./multi
==391==
--391-- Valgrind options:
--391-- --tool=drd
--391-- --free-is-write=yes
--391-- -v
--391-- Contents of /proc/version:
--391-- Linux version 2.6.32-27-generic (buildd@roseapple) (gcc
version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) ) #49-Ubuntu SMP Wed Dec 1
23:52:12 UTC 2010
--391-- Arch and hwcaps: X86, x86-sse1-sse2
--391-- Page sizes: currently 4096, max supported 4096
--391-- Valgrind library directory: /usr/local/lib/valgrind
--391-- Reading syms from /lib/ld-2.11.1.so (0x4000000)
--391-- Considering /lib/ld-2.11.1.so ..
--391-- .. CRC mismatch (computed d005eb74 wanted 53dc8daf)
--391-- Considering /usr/lib/debug/lib/ld-2.11.1.so ..
--391-- .. CRC is valid
--391-- Reading syms from
/home/am/Desktop/drm/api/debugnix/test_drd/multi (0x8048000)
--391-- Reading syms from /usr/local/lib/valgrind/drd-x86-linux (0x38000000)
--391-- object doesn't have a dynamic symbol table
--391-- Reading suppressions file: /usr/local/lib/valgrind/default.supp
--391-- Reading syms from
/usr/local/lib/valgrind/vgpreload_core-x86-linux.so (0x401f000)
--391-- Reading syms from
/usr/local/lib/valgrind/vgpreload_drd-x86-linux.so (0x4022000)
--391-- REDIR: 0x4016290 (strlen) redirected to 0x402ff60 (strlen)
--391-- Reading syms from /lib/tls/i686/cmov/libpthread-2.11.1.so (0x4050000)
--391-- Considering /lib/tls/i686/cmov/libpthread-2.11.1.so ..
--391-- .. CRC mismatch (computed 38da17dd wanted d3835c81)
--391-- Considering /usr/lib/debug/lib/tls/i686/cmov/libpthread-2.11.1.so ..
--391-- .. CRC is valid
--391-- Reading syms from /lib/tls/i686/cmov/libc-2.11.1.so (0x406a000)
--391-- Considering /lib/tls/i686/cmov/libc-2.11.1.so ..
--391-- .. CRC mismatch (computed da84aea3 wanted 8ac7aa97)
--391-- Considering /usr/lib/debug/lib/tls/i686/cmov/libc-2.11.1.so ..
--391-- .. CRC is valid
--391-- REDIR: 0x4055d70 (pthread_create@@GLIBC_2.1) redirected to
0x402d5a0 (pthread_create@*)
--391-- REDIR: 0x40d9660 (calloc) redirected to 0x402610f (calloc)
--391-- REDIR: 0x40d9f40 (malloc) redirected to 0x4026e2b (malloc)
--391-- REDIR: 0x40d9e60 (free) redirected to 0x4026a45 (free)
--391-- REDIR: 0x4057f10 (pthread_mutex_lock) redirected to 0x402e0b0
(pthread_mutex_lock)
--391-- REDIR: 0x4059400 (pthread_mutex_unlock) redirected to
0x402eb60 (pthread_mutex_unlock)
--391-- Reading syms from /lib/libgcc_s.so.1 (0x47e3000)
--391-- Considering /lib/libgcc_s.so.1 ..
--391-- .. CRC mismatch (computed 75b2cc22 wanted fffc9534)
--391-- object doesn't have a symbol table
--391-- REDIR: 0x40dd730 (strlen) redirected to 0x401f44c (_vgnU_ifunc_wrapper)
--391-- REDIR: 0x40dd770 (__strlen_sse2) redirected to 0x402ff40 (strlen)
--391-- REDIR: 0x405b3a0 (pthread_once) redirected to 0x4027f70 (pthread_once)
==391== Thread 3:
==391== Conflicting store by thread 3 at 0x043c6550 size 22816
==391== at 0x4026ACA: free (vg_replace_malloc.c:366)
==391== by 0x804878A: thread_func (multi.c:33)
==391== by 0x402DAAB: vgDrd_thread_wrapper (drd_pthread_intercepts.c:281)
==391== by 0x405596D: start_thread (pthread_create.c:300)
==391== by 0x4137A4D: clone (clone.S:130)
==391== Allocation context: unknown.
==391== Other segment start (thread 2)
==391== (thread finished, call stack no longer available)
==391== Other segment end (thread 2)
==391== (thread finished, call stack no longer available)
==391==
==391==
==391== ERROR SUMMARY: 8000 errors from 1 contexts (suppressed:
12190873 from 195)
==391==
==391== 8000 errors in context 1 of 1:
==391== Conflicting store by thread 3 at 0x043c6550 size 22816
==391== at 0x4026ACA: free (vg_replace_malloc.c:366)
==391== by 0x804878A: thread_func (multi.c:33)
==391== by 0x402DAAB: vgDrd_thread_wrapper (drd_pthread_intercepts.c:281)
==391== by 0x405596D: start_thread (pthread_create.c:300)
==391== by 0x4137A4D: clone (clone.S:130)
==391== Address 0x43c6550 is at offset 0 from 0x43c6550. Allocation context:
==391== at 0x40261EF: calloc (vg_replace_malloc.c:467)
==391== by 0x4010CDB: _dl_allocate_tls (dl-tls.c:300)
==391== by 0x40562E2: pthread_create@@GLIBC_2.1 (allocatestack.c:561)
==391== by 0x402D6D4: pthread_create@* (drd_pthread_intercepts.c:416)
==391== by 0x80486C3: main (multi.c:51)
==391== Other segment start (thread 1)
==391== (thread finished, call stack no longer available)
==391== Other segment end (thread 1)
==391== (thread finished, call stack no longer available)
==391== Other segment start (thread 1)
==391== (thread finished, call stack no longer available)
==391== Other segment end (thread 1)
==391== (thread finished, call stack no longer available)
==391== Other segment start (thread 1)
==391== (thread finished, call stack no longer available)
==391== Other segment end (thread 1)
==391== (thread finished, call stack no longer available)
==391== Other segment start (thread 1)
==391== (thread finished, call stack no longer available)
==391== Other segment end (thread 1)
==391== (thread finished, call stack no longer available)
==391== Other segment start (thread 1)
==391== (thread finished, call stack no longer available)
==391== Other segment end (thread 1)
==391== (thread finished, call stack no longer available)
==391== Other segment start (thread 2)
==391== (thread finished, call stack no longer available)
==391== Other segment end (thread 2)
==391== (thread finished, call stack no longer available)
==391== Other segment start (thread 4)
==391== (thread finished, call stack no longer available)
==391== Other segment end (thread 4)
==391== (thread finished, call stack no longer available)
==391== Other segment start (thread 5)
==391== (thread finished, call stack no longer available)
==391== Other segment end (thread 5)
==391== (thread finished, call stack no longer available)
==391== Other segment start (thread 6)
==391== (thread finished, call stack no longer available)
==391== Other segment end (thread 6)
==391== (thread finished, call stack no longer available)
==391== Other segment start (thread 7)
==391== (thread finished, call stack no longer available)
==391== Other segment end (thread 7)
==391== (thread finished, call stack no longer available)
==391== Other segment start (thread 8)
==391== (thread finished, call stack no longer available)
==391== Other segment end (thread 8)
==391== (thread finished, call stack no longer available)
==391== Other segment start (thread 9)
==391== (thread finished, call stack no longer available)
==391== Other segment end (thread 9)
==391== (thread finished, call stack no longer available)
==391==
--391--
--391-- used_suppression: 66 drd-ld
--391-- used_suppression: 12190789 drd-libc-stdio
--391-- used_suppression: 18 drd-libpthread-_Unwind_ForcedUnwind
==391==
==391== ERROR SUMMARY: 8000 errors from 1 contexts (suppressed:
12190873 from 195)
Ciao,
Andrea
|
|
From: Konstantin S. <kon...@gm...> - 2011-02-04 10:46:03
|
Hi,
I've been running 'valgrind --smc-check=all' on a C++ program which has a
Java plugin, i.e. at some point valgrind executes the JVM (OpenJDK).
Some of the warnings coming from memcheck look like this:
==25756== Invalid write of size 4
==25756== at 0x23E95648: ???
==25756== by 0x23EFF137: ???
==25756== Address 0x7ffeffade8 is not stack'd, malloc'd or (recently)
free'd
==25756==
{
<insert_a_suppression_name_here>
Memcheck:Addr4
obj:*
obj:*
}
This is most likely some jited code executed by the JVM, but since valgrind
did not manage to unwind the stack I can't even suppress it.
Did anyone ever run into similar problem?
Any idea how to suppress such warnings?
Thanks,
--kcc
|
|
From: Julian S. <js...@ac...> - 2011-02-03 14:43:59
|
On Thursday, February 03, 2011, Tom Hughes wrote: > On 03/02/11 10:13, Baurzhan Ismagulov wrote: > > On Thu, Feb 03, 2011 at 09:13:56AM +0000, Tom Hughes wrote: > >>>> In my function, I definitely initialize every value in the structure > >>>> (both by clearing with memset and also individually), but I still get > >>>> this message. > >>> > >>> Assuming that msgp is f_msg *, I fail to see mtext in f_msg. Is it the > >>> right struct? > >> > >> No, he is passing that struct as mtext. > >> > >> The problem is that the struct has padding, which he won't be > >> initialising. > > > > I assume he memsets the whole struct, so padding should also be > > initialized? > > Why would you presume that? I would say that it's pretty clear that he > isn't, or he wouldn't get the warning from valgrind! Well, he did say that in the original msg, although it's ambiguous. If the whole struct is memset-0'd then the padding should all be initialised. memset-0-ing the fields individually obviously won't help. Steve, try (1) memset-0-ing the entire structure, and (2) using --track-origins=yes. J |
|
From: Tom H. <to...@co...> - 2011-02-03 10:41:01
|
On 03/02/11 10:13, Baurzhan Ismagulov wrote: > On Thu, Feb 03, 2011 at 09:13:56AM +0000, Tom Hughes wrote: >>>> In my function, I definitely initialize every value in the structure (both >>>> by clearing with memset and also individually), but I still get this >>>> message. >>> >>> Assuming that msgp is f_msg *, I fail to see mtext in f_msg. Is it the >>> right struct? >> >> No, he is passing that struct as mtext. >> >> The problem is that the struct has padding, which he won't be initialising. > > I assume he memsets the whole struct, so padding should also be initialized? Why would you presume that? I would say that it's pretty clear that he isn't, or he wouldn't get the warning from valgrind! Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Baurzhan I. <ib...@ra...> - 2011-02-03 10:13:44
|
On Thu, Feb 03, 2011 at 09:13:56AM +0000, Tom Hughes wrote: > >> In my function, I definitely initialize every value in the structure (both > >> by clearing with memset and also individually), but I still get this > >> message. > > > > Assuming that msgp is f_msg *, I fail to see mtext in f_msg. Is it the > > right struct? > > No, he is passing that struct as mtext. > > The problem is that the struct has padding, which he won't be initialising. I assume he memsets the whole struct, so padding should also be initialized? With kind regards, -- Baurzhan Ismagulov http://www.kz-easy.com/ |
|
From: Tom H. <to...@co...> - 2011-02-03 09:14:10
|
On 03/02/11 08:47, Baurzhan Ismagulov wrote:
> On Wed, Feb 02, 2011 at 05:55:30PM -0800, Steve Singh wrote:
>> ==28571== Syscall param msgsnd(msgp->mtext) points to uninitialised byte(s)
> ...
>> typedef _f_msg {
>> long mtype;
>> unsigned int quit_type;
>> char *quit_msg;
>> int prolong;
>> unsigned long prolong_count;
>> unsigned short prolong_type;
>> } f_msg;
>>
>> In my function, I definitely initialize every value in the structure (both
>> by clearing with memset and also individually), but I still get this
>> message.
>
> Assuming that msgp is f_msg *, I fail to see mtext in f_msg. Is it the
> right struct?
No, he is passing that struct as mtext.
The problem is that the struct has padding, which he won't be initialising.
That's not generally a major problem, so long as the machine receiving
the message is expecting padding in the same place, but as valgrind
knows nothing about his application's message structure it can't tell
that the uninitialised bytes are just structure padding.
It may also be a security issue because you don't know what information
may be in those padding bytes which are then transferred from the
message sender to the message receiver.
Tom
--
Tom Hughes (to...@co...)
http://compton.nu/
|
|
From: Baurzhan I. <ib...@ra...> - 2011-02-03 09:06:38
|
On Wed, Feb 02, 2011 at 05:55:30PM -0800, Steve Singh wrote:
> ==28571== Syscall param msgsnd(msgp->mtext) points to uninitialised byte(s)
...
> typedef _f_msg {
> long mtype;
> unsigned int quit_type;
> char *quit_msg;
> int prolong;
> unsigned long prolong_count;
> unsigned short prolong_type;
> } f_msg;
>
> In my function, I definitely initialize every value in the structure (both
> by clearing with memset and also individually), but I still get this
> message.
Assuming that msgp is f_msg *, I fail to see mtext in f_msg. Is it the
right struct?
With kind regards,
--
Baurzhan Ismagulov
http://www.kz-easy.com/
|
|
From: Steve S. <ste...@gm...> - 2011-02-03 01:55:37
|
Hello,
First of all, thanks for all who've worked on valgrind, it's a very useful
tool!
I frequently get an error message that I don't understand:
==28571== Thread 2:
==28571== Syscall param msgsnd(msgp->mtext) points to uninitialised byte(s)
==28571== at 0x437F66F: msgsnd (msgsnd.c:43)
==28571== by 0x804D166: send_final_message (processor.c:5043)
My message structure is something like this:
typedef _f_msg {
long mtype;
unsigned int quit_type;
char *quit_msg;
int prolong;
unsigned long prolong_count;
unsigned short prolong_type;
} f_msg;
In my function, I definitely initialize every value in the structure (both
by clearing with memset and also individually), but I still get this
message. Is it because I'm using individual types instead of a mtext
structure or array? Sorry if this is a newbie question.
Thanks for reading.
SS
|
|
From: Cédric L. <la...@ok...> - 2011-02-02 13:58:17
|
Hi, On 02/02/2011 02:32 PM, Julian Seward wrote: > On Wednesday, February 02, 2011, Josef Weidendorfer wrote: > >> It looks like GCC parses "3i" as complex integer literal, and implicitly >> casts to a regular integer without warning, which then would become "size >> == 0", which obviously is not the right thing here. > Makes sense, except that what it appears to cast it to is "size == 3" > not "size == 0". Trying "size == 0" causes vassert(0) to happen a few > lines later when running the NEON instruction set tests, whereas > "size == 3" works. (See guest_arm_toIR.c:10988 and the two switches > just after that). > > Cédric, thanks for finding that! > > J You're welcome :-) I found it by chance. Cédric. |
|
From: Julian S. <js...@ac...> - 2011-02-02 13:32:17
|
On Wednesday, February 02, 2011, Josef Weidendorfer wrote: > It looks like GCC parses "3i" as complex integer literal, and implicitly > casts to a regular integer without warning, which then would become "size > == 0", which obviously is not the right thing here. Makes sense, except that what it appears to cast it to is "size == 3" not "size == 0". Trying "size == 0" causes vassert(0) to happen a few lines later when running the NEON instruction set tests, whereas "size == 3" works. (See guest_arm_toIR.c:10988 and the two switches just after that). Cédric, thanks for finding that! J |
|
From: Josef W. <Jos...@gm...> - 2011-02-02 12:53:29
|
Hi, On Wednesday 02 February 2011, Julian Seward wrote: > On Wednesday, February 02, 2011, Cédric Lachat wrote: > > > > It's the "size == 3i" bit. I guess that's a typo, but why gcc accepts > > > it, who knows. (Well, not me, anyway). > > > > > > What happens if you change "3i" to "3" ? > > > > The file compiles but is it correct ? > > Well, size is a 32-bit unsigned int, so it's just trying to > compute "size == 3". The question is why does gcc accept this > trailing "i" on the 3. I was curious and looked it up. Complex float numbers are C99, so "3.0i" is a complex literal with real value 0.0 and imaginary value 3.0. As GCC extension, gcc accepts complex integer numbers with the same notation. It looks like GCC parses "3i" as complex integer literal, and implicitly casts to a regular integer without warning, which then would become "size == 0", which obviously is not the right thing here. Josef > > J > > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Tom H. <to...@co...> - 2011-02-02 12:47:41
|
On 02/02/11 11:57, Julian Seward wrote: > Well, size is a 32-bit unsigned int, so it's just trying to > compute "size == 3". The question is why does gcc accept this > trailing "i" on the 3. Easy, it's a complex constant ;-) See: http://gcc.gnu.org/onlinedocs/gcc/Complex.html Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Julian S. <js...@ac...> - 2011-02-02 11:56:51
|
On Wednesday, February 02, 2011, Cédric Lachat wrote: > > It's the "size == 3i" bit. I guess that's a typo, but why gcc accepts > > it, who knows. (Well, not me, anyway). > > > > What happens if you change "3i" to "3" ? > > The file compiles but is it correct ? Well, size is a 32-bit unsigned int, so it's just trying to compute "size == 3". The question is why does gcc accept this trailing "i" on the 3. J |