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
(22) |
2
(24) |
|
3
(19) |
4
(20) |
5
(17) |
6
(20) |
7
(13) |
8
|
9
|
|
10
(10) |
11
(35) |
12
(20) |
13
(6) |
14
(19) |
15
|
16
|
|
17
(2) |
18
(3) |
19
(12) |
20
(1) |
21
(14) |
22
(2) |
23
(13) |
|
24
(2) |
25
(16) |
26
(17) |
27
(21) |
28
(17) |
29
(17) |
30
(14) |
|
31
(15) |
|
|
|
|
|
|
|
From: Matt W. <mw...@al...> - 2013-03-11 23:09:04
|
The xprof tool I proposed several weeks ago is available as a patch to valgrind-3.8.1. https://code.google.com/p/valgrind-xprof/downloads/list I'm assuming the chance of this being rolled into the valgrind distribution is near-zero. Date: Wed, 20 Feb 2013 19:48:18 -0800 From: Matthew Wette <mw...@al...> Subject: [Valgrind-developers] proposed new tool: xprof To: val...@li... Message-ID: <4D3...@al...> Content-Type: text/plain; charset=us-ascii Hi Folks, I have been working on a new valgrind tool and want to get feedback on approach and chances for getting this rolled into the distribution. If this has potential, I'd like to get feedback on ideas for user options, etc. I'm calling the tool "xprof" (prefix "xp"). It is an execution profiler. The context for tool use is the following: The user develops code on his desktop computer, but the downstream target is an embedded real-time application. He develops the code in a (physics based) simulation of the target environment. For example, he develops a a fuel-injection algorithm for an automobile engine. Early in the project the embedded real-time group wants an estimate of the CPU utilization of his algorithm. The algorithm is difficult to run without the context of the enviroment simulation, so he has trouble answering this question. Typically, he can only make crude estimates. Enter valgrind/xprof. This tool would allow the user to quickly provide a better CPU loading estimate within his simulation environment by providing cycle count estimates of specified regions of code. We are not after exact clock counts, but something better than crude flop estimates. |
|
From: Rich C. <rc...@wi...> - 2013-03-11 22:38:10
|
I couldn't reproduce this. It looks like the default suppressions are not being used. On Mon, 11 Mar 2013 17:24:28 +0100 Dan Shelton <dan...@gm...> wrote: > Has anyone seen this behaviour of valgrind 3.8.1 on opensuse 12.2? > Right after the upgrade from valgrind 3.7.0 it went mad and reported > uninitialised value(s) in /lib64/ld: > > valgrind /usr/bin/true > ==8501== Memcheck, a memory error detector > ==8501== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. > ==8501== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info > ==8501== Command: /usr/bin/true > ==8501== > ==8501== Conditional jump or move depends on uninitialised value(s) > ==8501== at 0x4017766: index (in /lib64/ld-2.15.so) > ==8501== by 0x40077D2: expand_dynamic_string_token (in /lib64/ld-2.15.so) > ==8501== by 0x40080C4: _dl_map_object (in /lib64/ld-2.15.so) > ==8501== by 0x40016CD: map_doit (in /lib64/ld-2.15.so) > ==8501== by 0x400E5F5: _dl_catch_error (in /lib64/ld-2.15.so) > ==8501== by 0x4000FFB: do_preload (in /lib64/ld-2.15.so) > ==8501== by 0x4003D93: dl_main (in /lib64/ld-2.15.so) > ==8501== by 0x40149FD: _dl_sysdep_start (in /lib64/ld-2.15.so) > ==8501== by 0x4004CED: _dl_start (in /lib64/ld-2.15.so) > ==8501== by 0x40014E7: ??? (in /lib64/ld-2.15.so) > ==8501== > ==8501== Conditional jump or move depends on uninitialised value(s) > ==8501== at 0x401776B: index (in /lib64/ld-2.15.so) > ==8501== by 0x40077D2: expand_dynamic_string_token (in /lib64/ld-2.15.so) > ==8501== by 0x40080C4: _dl_map_object (in /lib64/ld-2.15.so) > ==8501== by 0x40016CD: map_doit (in /lib64/ld-2.15.so) > ==8501== by 0x400E5F5: _dl_catch_error (in /lib64/ld-2.15.so) > ==8501== by 0x4000FFB: do_preload (in /lib64/ld-2.15.so) > ==8501== by 0x4003D93: dl_main (in /lib64/ld-2.15.so) > ==8501== by 0x40149FD: _dl_sysdep_start (in /lib64/ld-2.15.so) > ==8501== by 0x4004CED: _dl_start (in /lib64/ld-2.15.so) > ==8501== by 0x40014E7: ??? (in /lib64/ld-2.15.so) > ==8501== > ==8501== > ==8501== HEAP SUMMARY: > ==8501== in use at exit: 0 bytes in 0 blocks > ==8501== total heap usage: 0 allocs, 0 frees, 0 bytes allocated > ==8501== > ==8501== All heap blocks were freed -- no leaks are possible > ==8501== > ==8501== For counts of detected and suppressed errors, rerun with: -v > ==8501== Use --track-origins=yes to see where uninitialised values come from > ==8501== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0) > > valgrind --version > valgrind-3.8.1 > > ls /lib64/ld-* > ld-2.15.so ld-linux-x86-64.so.2 > > Dan > > ------------------------------------------------------------------------------ > Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester > Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the > endpoint security space. For insight on selecting the right partner to > tackle endpoint security challenges, access the full report. > http://p.sf.net/sfu/symantec-dev2dev > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers -- Rich Coe rc...@wi... |
|
From: Philippe W. <phi...@sk...> - 2013-03-11 22:23:54
|
On Mon, 2013-03-11 at 23:16 +0100, Dan Shelton wrote:
> Ouch.
>
> Do you have a simple beginner-class example which just issues the
> command 'where' (I know, redundant!) for each valgrind hit? I spend
> the last half hour with your suggestion and think that this is well
> beyond my current abilities without a small example usage.
Launch your valgrind with:
valgrind --vgdb-error=0 ./memcheck/tests/overlap
# this will output some lines such as:
==4718== and then give GDB the following command
==4718== target remote | /home/philippe/valgrind/trunk_untouched/install/lib/valgrind/../../bin/vgdb --pid=4718
In another window:
cat > a_lot_of_continue <<END
c
c
c
c
c
c
c
c
c
c
END
gdb ./memcheck/tests/overlap
set height 0
target remote | /home/philippe/valgrind/trunk_untouched/install/lib/valgrind/../../bin/vgdb --pid=4718
define hook-stop
print "before where"
where
print "after where"
end
source a_lot_of_continue
this will give something like:
(gdb) source a_lot_of_continue
Program received signal SIGTRAP, Trace/breakpoint trap.
$2 = "before where"
#0 0x04009383 in _vgr20180ZZ_libcZdsoZa_memcpy (dst=0xbefd00dc, src=0xbefd00c8, len=21)
at mc_replace_strmem.c:883
#1 0x08048632 in main () at overlap.c:40
$3 = "after where"
0x04009383 in _vgr20180ZZ_libcZdsoZa_memcpy (dst=0xbefd00dc, src=0xbefd00c8, len=21)
at mc_replace_strmem.c:883
883 MEMCPY(VG_Z_LIBC_SONAME, memcpy) /* fallback case */
Program received signal SIGTRAP, Trace/breakpoint trap.
$4 = "before where"
#0 0x04009383 in _vgr20180ZZ_libcZdsoZa_memcpy (dst=0xbefd00c8, src=0xbefd00dc, len=21)
at mc_replace_strmem.c:883
#1 0x0804867c in main () at overlap.c:42
$5 = "after where"
0x04009383 in _vgr20180ZZ_libcZdsoZa_memcpy (dst=0xbefd00c8, src=0xbefd00dc, len=21)
at mc_replace_strmem.c:883
883 MEMCPY(VG_Z_LIBC_SONAME, memcpy) /* fallback case */
Program received signal SIGTRAP, Trace/breakpoint trap.
$6 = "before where"
#0 0x04008927 in _vgr20090ZU_libcZdsoZa_strncpy (dst=<optimized out>, src=<optimized out>, n=21)
....
Of course, replace the print "before", where, etc by your own commands.
Philippe
|
|
From: Dan S. <dan...@gm...> - 2013-03-11 22:19:40
|
Are there any recommendations for gcc 4.7 compiler options to get the maximum effect from exp-sgcheck? I noticed that -g -gdb -gdwarf-4 -fvar-tracking-assignments gives extra valgrind findings but it also gives some horrible looking warnings like ==7716== Warning: bogus DWARF3 info: overlapping global blocks ==7716== Warning: bogus DWARF3 info: overlapping global blocks ==7716== Warning: bogus DWARF3 info: overlapping global blocks ==7716== Further instances of this message will not be shown ==7716== Warning: bogus DWARF3 info: overlapping stack blocks ==7716== Warning: bogus DWARF3 info: overlapping stack blocks ==7716== Warning: bogus DWARF3 info: overlapping stack blocks ==7716== Further instances of this message will not be shown Dan |
|
From: Dan S. <dan...@gm...> - 2013-03-11 22:16:34
|
On 11 March 2013 22:38, Philippe Waroquiers <phi...@sk...> wrote: > On Mon, 2013-03-11 at 17:52 +0100, Dan Shelton wrote: >> Has anyone found a way that for each valgrind hit a gdb command is issued? >> I need a way to print a certain amount of commands per valgrind hit on >> a live application (i.e. variables of interest). > I guess that by valgrind hit, you mean an error reported by valgrind. > > One way with which you can do that is to have a gdb connected > to Valgrind (use --vgdb-error=0 and follow the on-screen instructions). > > You can then put commands in the GDB "stop hook", using > > define hook-stop > print this_var > print other_var > ... any command accepted by gdb > ... including the Valgrind gdbserver monitor commands > end > > (the commands of a hook-stop are run each time your program stops). > There is one weakness with the GDB hook-stop: you cannot use > a continue command in the list of commands. > So, the bypass is to have a file containing a *lot* of > continue command. > You then source this file in GDB. > > So, in summary, at GDB side, you do: > > gdb your_program > define hook-stop > ... > all your needed commands > ... > end > target remote | ... (as told by valgrind) > set height 0 (this is needed to avoid having gdb pausing for each page of output > source a_file_containing_a_lot_of_continue_command > > I guess it will be possible to do the above also with --db-attach=yes > and giving GDB arguments to source a file of commands. This will however be very slow > as this will imply two forks and one GDB execution for each error. Ouch. Do you have a simple beginner-class example which just issues the command 'where' (I know, redundant!) for each valgrind hit? I spend the last half hour with your suggestion and think that this is well beyond my current abilities without a small example usage. Dan |
|
From: Philippe W. <phi...@sk...> - 2013-03-11 22:08:20
|
On Tue, 2013-03-12 at 02:46 +0800, Lu Mitnick wrote: > Hello Pḧilippe, > > I have took a look of the files you mentioned, not understanding how > Valgrind works very well. > In the following is a observation of me, please tell me if the > statement is wrong. > > * coregrind/m_redir implements the function lookup table used by > VG_(translate) > (coregrind/m_translate.c), a function do translattion. Yes, the translation code (m_translate.c) will call m_redir.c function VG_(redir_do_lookup) to see if an address of a function has to be redirected. If yes, rather than translating the original function, it translates the replacement function. > > Besides, I have some questions. Would you mind to answer me? > > * Is memcheck/Valgrind applicable to static-linked binary? Valgrind will sort of work with statically linked binaries, except that the standard Valgrind and tool redirections will not work. So, for example, malloc will not be replaced. This is because redirection instructions are in a shared object. If the executable is statically linked, the preload of the valgrind shared object will not be done, and so no replacement of malloc, libc, ... will be done. > * How do valgrind catch malloc call during translation? > > I am wondering how do Valgrind gather the information of malloc > address. So that it could > change the call target address during translation > (redirection/wrapping). Especially in striped > binary, there are fewer symbols. How do Valgrind do it? And which > source files should I take > a look? Valgrind will not work if libc etc have no debug info. Some distributions are stripping their libc etc. In such a case, VAlgrind will refuse to start, and will indicate to install the debug info for the library. Philippe |
|
From: Philippe W. <phi...@sk...> - 2013-03-11 21:38:16
|
On Mon, 2013-03-11 at 17:52 +0100, Dan Shelton wrote: > Has anyone found a way that for each valgrind hit a gdb command is issued? > I need a way to print a certain amount of commands per valgrind hit on > a live application (i.e. variables of interest). I guess that by valgrind hit, you mean an error reported by valgrind. One way with which you can do that is to have a gdb connected to Valgrind (use --vgdb-error=0 and follow the on-screen instructions). You can then put commands in the GDB "stop hook", using define hook-stop print this_var print other_var ... any command accepted by gdb ... including the Valgrind gdbserver monitor commands end (the commands of a hook-stop are run each time your program stops). There is one weakness with the GDB hook-stop: you cannot use a continue command in the list of commands. So, the bypass is to have a file containing a *lot* of continue command. You then source this file in GDB. So, in summary, at GDB side, you do: gdb your_program define hook-stop ... all your needed commands ... end target remote | ... (as told by valgrind) set height 0 (this is needed to avoid having gdb pausing for each page of output source a_file_containing_a_lot_of_continue_command I guess it will be possible to do the above also with --db-attach=yes and giving GDB arguments to source a file of commands. This will however be very slow as this will imply two forks and one GDB execution for each error. Philippe |
|
From: Lu M. <kin...@gm...> - 2013-03-11 18:46:41
|
Hello Pḧilippe,
I have took a look of the files you mentioned, not understanding how
Valgrind works very well.
In the following is a observation of me, please tell me if the statement is
wrong.
* coregrind/m_redir implements the function lookup table used by
VG_(translate)
(coregrind/m_translate.c), a function do translattion.
Besides, I have some questions. Would you mind to answer me?
* Is memcheck/Valgrind applicable to static-linked binary?
$ cat malloc.c
#include <stdlib.h>
int main() {
char *p = (char *)malloc(sizeof(char));
*(int *)p = 55;
return 0;
}
$ gcc malloc.c -o malloc
$ ./i-valgrind-3.8.1/bin/valgrind --tool=memcheck ./malloc
==4101== Memcheck, a memory error detector
==4101== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==4101== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==4101== Command: ./malloc
==4101==
==4101== Invalid write of size 4
==4101== at 0x40050E: main (in /home/mitnick/Desktop/IIS/ASan/malloc)
==4101== Address 0x51f4040 is 0 bytes inside a block of size 1 alloc'd
==4101== at 0x4C2A2D4: malloc (vg_replace_malloc.c:271)
==4101== by 0x400505: main (in /home/mitnick/Desktop/IIS/ASan/malloc)
==4101==
==4101==
==4101== HEAP SUMMARY:
==4101== in use at exit: 1 bytes in 1 blocks
==4101== total heap usage: 1 allocs, 0 frees, 1 bytes allocated
==4101==
==4101== LEAK SUMMARY:
==4101== definitely lost: 1 bytes in 1 blocks
==4101== indirectly lost: 0 bytes in 0 blocks
==4101== possibly lost: 0 bytes in 0 blocks
==4101== still reachable: 0 bytes in 0 blocks
==4101== suppressed: 0 bytes in 0 blocks
==4101== Rerun with --leak-check=full to see details of leaked memory
==4101==
==4101== For counts of detected and suppressed errors, rerun with: -v
==4101== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
Obviously, Valgrind do catch the memory access error of main. If we use
static-linking
instead, we could find out that Valgrind do not work.
$ gcc -static malloc.c -o malloc
$ ./i-valgrind-3.8.1/bin/valgrind --tool=memcheck ./malloc
==4126== Memcheck, a memory error detector
==4126== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==4126== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==4126== Command: ./malloc
==4126==
==4126== Conditional jump or move depends on uninitialised value(s)
==4126== at 0x410AE6: __linkin_atfork (in
/home/mitnick/Desktop/IIS/ASan/malloc)
==4126== by 0x403E43: ptmalloc_init.part.8 (in
/home/mitnick/Desktop/IIS/ASan/malloc)
==4126== by 0x407924: malloc_hook_ini (in
/home/mitnick/Desktop/IIS/ASan/malloc)
==4126== by 0x450C92: _dl_init_paths (in
/home/mitnick/Desktop/IIS/ASan/malloc)
==4126== by 0x4112A8: _dl_non_dynamic_init (in
/home/mitnick/Desktop/IIS/ASan/malloc)
==4126== by 0x411B22: __libc_init_first (in
/home/mitnick/Desktop/IIS/ASan/malloc)
==4126== by 0x40129C: (below main) (in
/home/mitnick/Desktop/IIS/ASan/malloc)
==4126==
==4126== Use of uninitialised value of size 8
==4126== at 0x401B9F: __run_exit_handlers (in
/home/mitnick/Desktop/IIS/ASan/malloc)
==4126==
==4126==
==4126== HEAP SUMMARY:
==4126== in use at exit: 0 bytes in 0 blocks
==4126== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==4126==
==4126== All heap blocks were freed -- no leaks are possible
==4126==
==4126== For counts of detected and suppressed errors, rerun with: -v
==4126== Use --track-origins=yes to see where uninitialised values come
from
==4126== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
* How do valgrind catch malloc call during translation?
I am wondering how do Valgrind gather the information of malloc address.
So that it could
change the call target address during translation (redirection/wrapping).
Especially in striped
binary, there are fewer symbols. How do Valgrind do it? And which source
files should I take
a look?
Thanks a lot
2013/3/6 Philippe Waroquiers <phi...@sk...>
> On Tue, 2013-03-05 at 03:16 +0800, Lu Mitnick wrote:
> > Hello everyone,
> >
> >
> > I am new to valgrind and wanna to know the mechanism of function
> > interception. Valgrind online documentation mentioned the function
> > interception is implemented via dynamic loader(dlopen/dlsym). I am
> > curious about whether the mechanism works well or not when the
> > instrumented program is static linked.
> You can do replacement of statically linked
> functions. See e.g. how --soname-synonyms=somalloc=NONE allows
> to do replacement of a statically linked malloc library.
>
> However, the "instructions" telling to Valgrind core to do the
> "standard" replacements are functions with special names which are
> in dynamically loaded objects.
> For example, the "instruction+code" to replace realloc for memcheck
> can be found by
> nm vgpreload_memcheck-x86-linux.so | grep realloc
> giving
> 000042b3 T _vgr10090ZU_VgSoSynsomalloc_realloc
> 000043af T _vgr10090ZU_libcZdsoZa_realloc
>
> Replacement is working in fully static executable.
> However, the "standard" valgrind replacements are not done,
> as e.g. the memcheck vgpreload_memcheck-x86-linux.so will not be loaded,
> because the dynamic loader will not be invoked.
>
> > To get deeper understanding of the topic. Would somebody tell me which
> > files is related so that I could take a look.
> Look in include/pub_tool_redir.h, coregrind/pub_core_redir.h
> and coregrind/m_redir.c
>
> You can also activate Valgrind trace(s) to see what is going on
> e.g. -v -v -v -d -d -d --trace-redir=yes
> for a lot of trace about everything + a lot of trace about the
> redirection.
>
> Pḧilippe
>
>
>
>
>
|
|
From: Dan S. <dan...@gm...> - 2013-03-11 16:52:26
|
Has anyone found a way that for each valgrind hit a gdb command is issued? I need a way to print a certain amount of commands per valgrind hit on a live application (i.e. variables of interest). Dan |
|
From: Patrick J. L. <lop...@gm...> - 2013-03-11 16:38:00
|
On Mon, Mar 11, 2013 at 8:03 AM, John Reiser <jr...@bi...> wrote: > > As the clang/llvm threads indicate ( http://llvm.org/bugs/show_bug.cgi?id=11763#c8 , > also https://bugs.kde.org/show_bug.cgi?id=148543 ) > in practice the only known possibility for trouble is something like 'dcbz' on > PowerPC "I cannot imagine why you would want to do that, therefore nobody will ever want to do that"? I think I read about this one in my logic class. Proof By Lack Of Imagination, aka. the "Modus Bogus". It's UNDEFINED BEHAVIOR, for crying out loud. I could have sworn there was this thing called programming by contract, where "undefined behavior" means "don't do that". It's a rule. The funny part is, there is no development group on the planet more aggressively eager to take advantage of this rule than the Clang developers. They seem to think the same rule they apply so zealously to everybody else does not apply to themselves. Hilarious. > In practice it would be poor engineering for the C library to implement such an > optimization without checking for exact overlap (dst==src). This check costs > two instructions of space and usually zero time (all overlapped with previous > execution on a 2-way superscalar processor.) Users will pay this cost gladly > in order to get robust practical computing. By that logic, Clang could emit the self-assignment test before calling memcpy, and it would cost zero time. Maybe you should suggest it to the Clang developers. How far do you think you would get? > Thus in practice the complaint "memcpy(x,x,n) is not OK" is very similar to noise. The whole discussion is ludicrous. If the object is small, then "*x = *y" should be inlined. If it is large enough to bother with a call to memcpy(), then it is large enough that the self-assignment test is negligible. memcpy() has well-defined preconditions; Clang violates them; therefore Clang is buggy. Period, ipso facto, Q.E.D. > Because a suppression has no access to actual arguments and cannot check for src==dst, > then there should be an option to turn off the complaint. Although I disagree with every step of your reasoning, I do agree with your conclusion. Valgrind's purpose is to tell us when our code does something "funny", and overlapping memcpy() certainly qualifies. But sometimes we do something "funny" for a reason, so we need a way to shut up Valgrind. So one way or another, there needs to be a way to silence this warning. Clang is still buggy though. - Pat |
|
From: Dan S. <dan...@gm...> - 2013-03-11 16:24:36
|
Has anyone seen this behaviour of valgrind 3.8.1 on opensuse 12.2? Right after the upgrade from valgrind 3.7.0 it went mad and reported uninitialised value(s) in /lib64/ld: valgrind /usr/bin/true ==8501== Memcheck, a memory error detector ==8501== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==8501== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==8501== Command: /usr/bin/true ==8501== ==8501== Conditional jump or move depends on uninitialised value(s) ==8501== at 0x4017766: index (in /lib64/ld-2.15.so) ==8501== by 0x40077D2: expand_dynamic_string_token (in /lib64/ld-2.15.so) ==8501== by 0x40080C4: _dl_map_object (in /lib64/ld-2.15.so) ==8501== by 0x40016CD: map_doit (in /lib64/ld-2.15.so) ==8501== by 0x400E5F5: _dl_catch_error (in /lib64/ld-2.15.so) ==8501== by 0x4000FFB: do_preload (in /lib64/ld-2.15.so) ==8501== by 0x4003D93: dl_main (in /lib64/ld-2.15.so) ==8501== by 0x40149FD: _dl_sysdep_start (in /lib64/ld-2.15.so) ==8501== by 0x4004CED: _dl_start (in /lib64/ld-2.15.so) ==8501== by 0x40014E7: ??? (in /lib64/ld-2.15.so) ==8501== ==8501== Conditional jump or move depends on uninitialised value(s) ==8501== at 0x401776B: index (in /lib64/ld-2.15.so) ==8501== by 0x40077D2: expand_dynamic_string_token (in /lib64/ld-2.15.so) ==8501== by 0x40080C4: _dl_map_object (in /lib64/ld-2.15.so) ==8501== by 0x40016CD: map_doit (in /lib64/ld-2.15.so) ==8501== by 0x400E5F5: _dl_catch_error (in /lib64/ld-2.15.so) ==8501== by 0x4000FFB: do_preload (in /lib64/ld-2.15.so) ==8501== by 0x4003D93: dl_main (in /lib64/ld-2.15.so) ==8501== by 0x40149FD: _dl_sysdep_start (in /lib64/ld-2.15.so) ==8501== by 0x4004CED: _dl_start (in /lib64/ld-2.15.so) ==8501== by 0x40014E7: ??? (in /lib64/ld-2.15.so) ==8501== ==8501== ==8501== HEAP SUMMARY: ==8501== in use at exit: 0 bytes in 0 blocks ==8501== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==8501== ==8501== All heap blocks were freed -- no leaks are possible ==8501== ==8501== For counts of detected and suppressed errors, rerun with: -v ==8501== Use --track-origins=yes to see where uninitialised values come from ==8501== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0) valgrind --version valgrind-3.8.1 ls /lib64/ld-* ld-2.15.so ld-linux-x86-64.so.2 Dan |
|
From: John R. <jr...@bi...> - 2013-03-11 15:03:03
|
On 03/11/2013 06:22 AM, Konstantin Serebryany wrote: > On Mon, Mar 11, 2013 at 5:18 PM, Tom Hughes <to...@co...> wrote: >> So clang are saying they have verified the glibc implementation is safe and >> have a guarantee from the glibc maintainers not to change it? > I don't think this has any stamp from glibc. :) As the clang/llvm threads indicate ( http://llvm.org/bugs/show_bug.cgi?id=11763#c8 , also https://bugs.kde.org/show_bug.cgi?id=148543 ) in practice the only known possibility for trouble is something like 'dcbz' on PowerPC, where the destination cache line might be zeroed before being read as identical overlapping source. Of course this applies only when n >= sizeof(line), actual alignment is known, etc. In practice it would be poor engineering for the C library to implement such an optimization without checking for exact overlap (dst==src). This check costs two instructions of space and usually zero time (all overlapped with previous execution on a 2-way superscalar processor.) Users will pay this cost gladly in order to get robust practical computing. Thus in practice the complaint "memcpy(x,x,n) is not OK" is very similar to noise. Because a suppression has no access to actual arguments and cannot check for src==dst, then there should be an option to turn off the complaint. -- |
|
From: Konstantin S. <kon...@gm...> - 2013-03-11 13:22:43
|
On Mon, Mar 11, 2013 at 5:18 PM, Tom Hughes <to...@co...> wrote: > On 11/03/13 13:16, Konstantin Serebryany wrote: >> >> On Mon, Mar 11, 2013 at 4:33 PM, Tom Hughes <to...@co...> wrote: >>> >>> On 11/03/13 11:52, Konstantin Serebryany wrote: >>> >>>> There was a gcc bug that caused Valgrind/Memcheck to complain about >>>> memcpy(x, x, n). >>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39480 >>>> Since gcc 4.3 it does not generate such code and the problem is gone. >>>> >>>> However, Clang/LLVM generates memcpy(x, x, n) and they have good reasons >>>> not >>>> to change this: http://llvm.org/bugs/show_bug.cgi?id=11763 >>>> >>>> As the result we have incompatibility between Clang and Valgrind, and >>>> Clang does not want to fix it. >>>> Does Valgrind want to? >>> >>> >>> >>> Well the critical question is, does the C standard say this is safe or >>> not? >> >> >> My understanding is that the C/C++ standards do not allow users to >> call memcpy(x, x, n), >> but the compiler may choose to generate memcpy(x, y, n) for *x=*y w/o >> checking x!=y, >> if it knows that the memcpy implementation is safe. > > > So clang are saying they have verified the glibc implementation is safe and > have a guarantee from the glibc maintainers not to change it? >> Eli Friedman 2012-01-13 19:47:28 CST >> This was done intentionally in r65699; in practice, memcpy implementations handle exact overlap correctly, and other implementations of struct assignment cause issues. (We're allowed to generate "illegal" calls to memcpy because LLVM is generating platform-specific assembly, not C code.) I don't think this has any stamp from glibc. :) --kcc > > > Tom > > -- > Tom Hughes (to...@co...) > http://compton.nu/ |
|
From: Tom H. <to...@co...> - 2013-03-11 13:18:23
|
On 11/03/13 13:16, Konstantin Serebryany wrote: > On Mon, Mar 11, 2013 at 4:33 PM, Tom Hughes <to...@co...> wrote: >> On 11/03/13 11:52, Konstantin Serebryany wrote: >> >>> There was a gcc bug that caused Valgrind/Memcheck to complain about >>> memcpy(x, x, n). >>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39480 >>> Since gcc 4.3 it does not generate such code and the problem is gone. >>> >>> However, Clang/LLVM generates memcpy(x, x, n) and they have good reasons >>> not >>> to change this: http://llvm.org/bugs/show_bug.cgi?id=11763 >>> >>> As the result we have incompatibility between Clang and Valgrind, and >>> Clang does not want to fix it. >>> Does Valgrind want to? >> >> >> Well the critical question is, does the C standard say this is safe or not? > > My understanding is that the C/C++ standards do not allow users to > call memcpy(x, x, n), > but the compiler may choose to generate memcpy(x, y, n) for *x=*y w/o > checking x!=y, > if it knows that the memcpy implementation is safe. So clang are saying they have verified the glibc implementation is safe and have a guarantee from the glibc maintainers not to change it? Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Konstantin S. <kon...@gm...> - 2013-03-11 13:16:59
|
On Mon, Mar 11, 2013 at 4:33 PM, Tom Hughes <to...@co...> wrote: > On 11/03/13 11:52, Konstantin Serebryany wrote: > >> There was a gcc bug that caused Valgrind/Memcheck to complain about >> memcpy(x, x, n). >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39480 >> Since gcc 4.3 it does not generate such code and the problem is gone. >> >> However, Clang/LLVM generates memcpy(x, x, n) and they have good reasons >> not >> to change this: http://llvm.org/bugs/show_bug.cgi?id=11763 >> >> As the result we have incompatibility between Clang and Valgrind, and >> Clang does not want to fix it. >> Does Valgrind want to? > > > Well the critical question is, does the C standard say this is safe or not? My understanding is that the C/C++ standards do not allow users to call memcpy(x, x, n), but the compiler may choose to generate memcpy(x, y, n) for *x=*y w/o checking x!=y, if it knows that the memcpy implementation is safe. --kcc > > Tom > > -- > Tom Hughes (to...@co...) > http://compton.nu/ |
|
From: Tom H. <to...@co...> - 2013-03-11 12:39:29
|
On 11/03/13 12:34, Roland Mainz wrote: > On Mon, Mar 11, 2013 at 1:32 PM, Tom Hughes <to...@co...> wrote: >> On 11/03/13 12:21, Roland Mainz wrote: >>> Does anyone know what's going wrong in the example below: >> Yes - it's using DWZ compression (hence the "indirect" string) and that is >> not yet supported in valgrind. > > Grumpf... ;-( > > Is there any workaround ? Actually I'm wrong - it is handled in 3.8.0 and later so you just need to update. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Roland M. <rol...@nr...> - 2013-03-11 12:34:25
|
On Mon, Mar 11, 2013 at 1:32 PM, Tom Hughes <to...@co...> wrote: > On 11/03/13 12:21, Roland Mainz wrote: >> Does anyone know what's going wrong in the example below: > Yes - it's using DWZ compression (hence the "indirect" string) and that is > not yet supported in valgrind. Grumpf... ;-( Is there any workaround ? ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) rol...@nr... \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) |
|
From: Tom H. <to...@co...> - 2013-03-11 12:33:49
|
On 11/03/13 11:52, Konstantin Serebryany wrote: > There was a gcc bug that caused Valgrind/Memcheck to complain about > memcpy(x, x, n). > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39480 > Since gcc 4.3 it does not generate such code and the problem is gone. > > However, Clang/LLVM generates memcpy(x, x, n) and they have good reasons not > to change this: http://llvm.org/bugs/show_bug.cgi?id=11763 > > As the result we have incompatibility between Clang and Valgrind, and > Clang does not want to fix it. > Does Valgrind want to? Well the critical question is, does the C standard say this is safe or not? Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Tom H. <to...@co...> - 2013-03-11 12:32:51
|
On 11/03/13 11:43, Roland Mainz wrote: > ping! - has any one looked at these issues ? Has anybody reported them properly? (hint: we have a bug tracker for reporting bugs). Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Tom H. <to...@co...> - 2013-03-11 12:32:19
|
On 11/03/13 12:21, Roland Mainz wrote: > Does anyone know what's going wrong in the example below: Yes - it's using DWZ compression (hence the "indirect" string) and that is not yet supported in valgrind. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Roland M. <rol...@nr...> - 2013-03-11 12:22:01
|
Hi!
----
Does anyone know what's going wrong in the example below:
-- snip --
$ cat helloworld.c
#include <stdlib.h>
#include <stdio.h>
#include <math.h>
volatile long double foo;
void blabla2(volatile long double *arg)
{
static int foo=2;
printf("sum=%d\n", ((int)*arg)+foo);
}
void blabla(int arg1)
{
foo=truncl(1.6L)+arg1;
blabla2(&foo);
}
int main(int ac, char *av[])
{
blabla(atoi("4"));
return EXIT_SUCCESS;
}
$ rm -f ./helloworld ; clang -g helloworld.c -lm -o helloworld
$ valgrind --track-origins=yes --read-var-info=yes ./helloworld
==6451== Memcheck, a memory error detector
==6451== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==6451== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==6451== Command: ./helloworld
==6451==
parse_var_DIE: confused by:
<0><101>: DW_TAG_compile_unit
DW_AT_producer : (indirect string, offset: 0xbf): clang
version 3.1 (branches/release_31 157047)
DW_AT_language : 12
DW_AT_name : (indirect string, offset: 0xee): helloworld.c
DW_AT_low_pc : 0x0
DW_AT_stmt_list : 136
DW_AT_comp_dir : (indirect string, offset: 0xfb):
/home/test001/tmp/dwarf4valgrind
--6451-- WARNING: Serious error when reading debug info
--6451-- When reading debug info from
/home/test001/tmp/dwarf4valgrind/helloworld:
--6451-- parse_var_DIE: confused by the above DIE
sum=7
==6451==
==6451== HEAP SUMMARY:
==6451== in use at exit: 0 bytes in 0 blocks
==6451== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==6451==
==6451== All heap blocks were freed -- no leaks are possible
==6451==
==6451== For counts of detected and suppressed errors, rerun with: -v
==6451== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)
$ clang --version
clang version 3.1 (branches/release_31 157047)
Target: x86_64-unknown-linux-gnu
Thread model: posix
$ valgrind --version
valgrind-3.7.0
-- snip --
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) rol...@nr...
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
|
|
From: Konstantin S. <kon...@gm...> - 2013-03-11 11:53:24
|
Hi, There was a gcc bug that caused Valgrind/Memcheck to complain about memcpy(x, x, n). http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39480 Since gcc 4.3 it does not generate such code and the problem is gone. However, Clang/LLVM generates memcpy(x, x, n) and they have good reasons not to change this: http://llvm.org/bugs/show_bug.cgi?id=11763 As the result we have incompatibility between Clang and Valgrind, and Clang does not want to fix it. Does Valgrind want to? Any suggestions? % cat memcpy_bug.cc struct LargeStruct { int foo[100]; }; void copy(LargeStruct *a, LargeStruct *b) { *a = *b; } int main() { LargeStruct x; copy(&x, &x); } % gcc -g memcpy_bug.cc ; ~/valgrind/trunk/inst/bin/valgrind -q ./a.out % clang -g memcpy_bug.cc ; ~/valgrind/trunk/inst/bin/valgrind -q ./a.out ==28173== Source and destination overlap in memcpy(0xfff0000d0, 0xfff0000d0, 400) ==28173== at 0x402E280: memcpy@@GLIBC_2.14 (mc_replace_strmem.c:882) ==28173== by 0x400581: copy(LargeStruct*, LargeStruct*) (memcpy_bug.cc:6) ==28173== by 0x4005AC: main (memcpy_bug.cc:11) ==28173== % Thanks, --kcc |
|
From: Roland M. <rol...@nr...> - 2013-03-11 11:43:11
|
On Mon, Feb 25, 2013 at 10:56 PM, Roland Mainz <rol...@nr...> wrote: > The valgrind usage below shows two issues with valgrind > (valgrind-3.7.0 on SuSE 12.2/AMD64/64bit, testing a 64bit ksh93 binary > (see http://lists.research.att.com/pipermail/ast-developers/2013q1/002266.html)): > 1. Some messages for |memcpy()| seem to use |signed int| as 3rd > argument for |memcpy()| instead of the (unsigned) |size_t|: > -- snip -- > ==3508== Source and destination overlap in memcpy(0x0, 0x5e3c081, -8751) > -- snip -- > > 2. Some messages reporting the stack size seem to use |signed int| for > the stack size: > -- snip -- > ==3508== The main thread stack size used in this run was -2147483648. > -- snip -- > > Example: > -- snip -- > $ ksh -c 'v="$(for ((i=0 ; i< 150000; i++)); do printf "abc" ; done)" > ; for ((j=0 ; j<500;j++)) ; do printf "%s%d=10\n" "$v" j ; done ; > print' | valgrind --track-origins=yes --read-var-info=yes > --main-stacksize=$((2**31)) ~/bin/ksh > ==3508== Memcheck, a memory error detector > ==3508== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. > ==3508== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info > ==3508== Command: /home/test001/bin/ksh > ==3508== > ==3508== Syscall param mount(type) points to unaddressable byte(s) > ==3508== at 0x5613A4A: mount (in /lib64/libc-2.15.so) > ==3508== by 0x4AADC5: fs3d_mount (fs3d.c:115) > ==3508== by 0x4AABF3: fs3d (fs3d.c:57) > ==3508== by 0x42E583: sh_init (init.c:1470) > ==3508== by 0x40D5A9: sh_main (main.c:142) > ==3508== by 0x40D450: main (pmain.c:45) > ==3508== Address 0x0 is not stack'd, malloc'd or (recently) free'd > ==3508== > ==3508== Source and destination overlap in memcpy(0x0, 0x5e3c081, -8751) > ==3508== at 0x4C2C400: memcpy@@GLIBC_2.14 (in > /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) > ==3508== by 0x454E7C: nv_open (name.c:1438) > ==3508== by 0x451FD5: sh_setlist (name.c:594) > ==3508== by 0x477E61: sh_exec (xec.c:1154) > ==3508== by 0x40F0D5: exfile (main.c:588) > ==3508== by 0x40E29A: sh_main (main.c:360) > ==3508== by 0x40D450: main (pmain.c:45) > ==3508== > ==3508== Invalid write of size 1 > ==3508== at 0x4C2C4D3: memcpy@@GLIBC_2.14 (in > /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) > ==3508== by 0x454E7C: nv_open (name.c:1438) > ==3508== by 0x451FD5: sh_setlist (name.c:594) > ==3508== by 0x477E61: sh_exec (xec.c:1154) > ==3508== by 0x40F0D5: exfile (main.c:588) > ==3508== by 0x40E29A: sh_main (main.c:360) > ==3508== by 0x40D450: main (pmain.c:45) > ==3508== Address 0x0 is not stack'd, malloc'd or (recently) free'd > ==3508== > ==3508== > ==3508== Process terminating with default action of signal 11 (SIGSEGV) > ==3508== Access not within mapped region at address 0x0 > ==3508== at 0x4C2C4D3: memcpy@@GLIBC_2.14 (in > /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) > ==3508== by 0x454E7C: nv_open (name.c:1438) > ==3508== by 0x451FD5: sh_setlist (name.c:594) > ==3508== by 0x477E61: sh_exec (xec.c:1154) > ==3508== by 0x40F0D5: exfile (main.c:588) > ==3508== by 0x40E29A: sh_main (main.c:360) > ==3508== by 0x40D450: main (pmain.c:45) > ==3508== If you believe this happened as a result of a stack > ==3508== overflow in your program's main thread (unlikely but > ==3508== possible), you can try to increase the size of the > ==3508== main thread stack using the --main-stacksize= flag. > ==3508== The main thread stack size used in this run was -2147483648. > ==3508== > ==3508== HEAP SUMMARY: > ==3508== in use at exit: 0 bytes in 0 blocks > ==3508== total heap usage: 424 allocs, 424 frees, 26,696 bytes allocated > ==3508== > ==3508== All heap blocks were freed -- no leaks are possible > ==3508== > ==3508== For counts of detected and suppressed errors, rerun with: -v > ==3508== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 2 from 2) > Segmentation fault > -- snip -- ping! - has any one looked at these issues ? ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) rol...@nr... \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) |
|
From: Rich C. <rc...@wi...> - 2013-03-11 05:17:15
|
valgrind revision: 13324
VEX revision: 2695
C compiler: i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)
GDB: GNU gdb 6.3.50-20050815 (Apple version gdb-1515) (Sat Jan 15 08:30:16 UTC 2011)
Assembler:
C library: unknown
uname -mrs: Darwin 10.8.0 i386
Vendor version: unknown
Nightly build on macx86 ( Darwin 10.8.0 i386 )
Started at 2013-03-10 23:35:00 CDT
Ended at 2013-03-11 00:16:55 CDT
Results differ from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests ... failed
Regression test results follow
== 509 tests, 149 stderr failures, 4 stdout failures, 3 stderrB failures, 3 stdoutB failures, 1 post failure ==
gdbserver_tests/mchelp (stdoutB)
gdbserver_tests/mchelp (stderrB)
gdbserver_tests/mcinvokeRU (stdoutB)
gdbserver_tests/mcinvokeRU (stderrB)
gdbserver_tests/mcinvokeWS (stdoutB)
gdbserver_tests/mcinvokeWS (stderrB)
memcheck/tests/accounting (stderr)
memcheck/tests/badpoll (stderr)
memcheck/tests/big_blocks_freed_list (stderr)
memcheck/tests/bug287260 (stderr)
memcheck/tests/darwin/aio (stderr)
memcheck/tests/darwin/pth-supp (stderr)
memcheck/tests/darwin/scalar (stderr)
memcheck/tests/deep-backtrace (stderr)
memcheck/tests/err_disable4 (stderr)
memcheck/tests/leak-delta (stderr)
memcheck/tests/leak-segv-jmp (stderr)
memcheck/tests/lks (stderr)
memcheck/tests/memcmptest (stderr)
memcheck/tests/mismatches (stderr)
memcheck/tests/null_socket (stdout)
memcheck/tests/origin5-bz2 (stderr)
memcheck/tests/overlap (stdout)
memcheck/tests/overlap (stderr)
memcheck/tests/sem (stderr)
memcheck/tests/sendmsg (stderr)
memcheck/tests/strchr (stderr)
memcheck/tests/test-plo-no (stderr)
memcheck/tests/varinfo3 (stderr)
memcheck/tests/varinfo5 (stderr)
memcheck/tests/vbit-test/vbit-test (stderr)
memcheck/tests/vcpu_fnfns (stdout)
memcheck/tests/writev1 (stderr)
massif/tests/big-alloc (post)
massif/tests/pages_as_heap (stderr)
none/tests/allexec32 (stderr)
none/tests/allexec64 (stderr)
none/tests/async-sigs (stderr)
none/tests/cmdline5 (stderr)
none/tests/execve (stderr)
none/tests/faultstatus (stderr)
none/tests/mmap_fcntl_bug (stderr)
none/tests/nodir (stderr)
none/tests/pth_blockedsig (stderr)
none/tests/require-text-symbol-2 (stderr)
none/tests/rlimit64_nofile (stderr)
none/tests/shell_nosuchfile (stderr)
none/tests/x86/cse_fail (stdout)
helgrind/tests/annotate_hbefore (stderr)
helgrind/tests/annotate_rwlock (stderr)
helgrind/tests/annotate_smart_pointer (stderr)
helgrind/tests/cond_timedwait_invalid (stderr)
helgrind/tests/free_is_write (stderr)
helgrind/tests/hg01_all_ok (stderr)
helgrind/tests/hg02_deadlock (stderr)
helgrind/tests/hg03_inherit (stderr)
helgrind/tests/hg04_race (stderr)
helgrind/tests/hg05_race2 (stderr)
helgrind/tests/hg06_readshared (stderr)
helgrind/tests/locked_vs_unlocked1_fwd (stderr)
helgrind/tests/locked_vs_unlocked1_rev (stderr)
helgrind/tests/locked_vs_unlocked2 (stderr)
helgrind/tests/locked_vs_unlocked3 (stderr)
helgrind/tests/pth_destroy_cond (stderr)
helgrind/tests/rwlock_race (stderr)
helgrind/tests/rwlock_test (stderr)
helgrind/tests/t2t_laog (stderr)
helgrind/tests/tc01_simple_race (stderr)
helgrind/tests/tc02_simple_tls (stderr)
helgrind/tests/tc03_re_excl (stderr)
helgrind/tests/tc04_free_lock (stderr)
helgrind/tests/tc05_simple_race (stderr)
helgrind/tests/tc06_two_races (stderr)
helgrind/tests/tc06_two_races_xml (stderr)
helgrind/tests/tc07_hbl1 (stderr)
helgrind/tests/tc08_hbl2 (stderr)
helgrind/tests/tc09_bad_unlock (stderr)
helgrind/tests/tc10_rec_lock (stderr)
helgrind/tests/tc11_XCHG (stderr)
helgrind/tests/tc12_rwl_trivial (stderr)
helgrind/tests/tc13_laog1 (stderr)
helgrind/tests/tc14_laog_dinphils (stderr)
helgrind/tests/tc15_laog_lockdel (stderr)
helgrind/tests/tc16_byterace (stderr)
helgrind/tests/tc17_sembar (stderr)
helgrind/tests/tc18_semabuse (stderr)
helgrind/tests/tc19_shadowmem (stderr)
helgrind/tests/tc21_pthonce (stderr)
helgrind/tests/tc23_bogus_condwait (stderr)
helgrind/tests/tc24_nonzero_sem (stderr)
drd/tests/annotate_barrier (stderr)
drd/tests/annotate_barrier_xml (stderr)
drd/tests/annotate_hb_race (stderr)
drd/tests/annotate_hbefore (stderr)
drd/tests/annotate_ignore_read (stderr)
drd/tests/annotate_ignore_rw (stderr)
drd/tests/annotate_ignore_rw2 (stderr)
drd/tests/annotate_ignore_write (stderr)
drd/tests/annotate_ignore_write2 (stderr)
drd/tests/annotate_order_1 (stderr)
drd/tests/annotate_order_2 (stderr)
drd/tests/annotate_order_3 (stderr)
drd/tests/annotate_rwlock (stderr)
drd/tests/annotate_smart_pointer (stderr)
drd/tests/annotate_smart_pointer2 (stderr)
drd/tests/annotate_spinlock (stderr)
drd/tests/annotate_static (stderr)
drd/tests/atomic_var (stderr)
drd/tests/bug-235681 (stderr)
drd/tests/circular_buffer (stderr)
drd/tests/fp_race (stderr)
drd/tests/fp_race2 (stderr)
drd/tests/fp_race_xml (stderr)
drd/tests/free_is_write (stderr)
drd/tests/free_is_write2 (stderr)
drd/tests/hg01_all_ok (stderr)
drd/tests/hg02_deadlock (stderr)
drd/tests/hg03_inherit (stderr)
drd/tests/hg04_race (stderr)
drd/tests/hg05_race2 (stderr)
drd/tests/hg06_readshared (stderr)
drd/tests/linuxthreads_det (stderr)
drd/tests/monitor_example (stderr)
drd/tests/pth_broadcast (stderr)
drd/tests/pth_cleanup_handler (stderr)
drd/tests/pth_cond_destroy_busy (stderr)
drd/tests/pth_cond_race (stderr)
drd/tests/pth_cond_race2 (stderr)
drd/tests/pth_cond_race3 (stderr)
drd/tests/pth_create_chain (stderr)
drd/tests/pth_detached3 (stderr)
drd/tests/pth_inconsistent_cond_wait (stderr)
drd/tests/pth_once (stderr)
drd/tests/read_and_free_race (stderr)
drd/tests/rwlock_race (stderr)
drd/tests/rwlock_test (stderr)
drd/tests/sem_open (stderr)
drd/tests/sem_open2 (stderr)
drd/tests/sem_open3 (stderr)
drd/tests/sem_open_traced (stderr)
drd/tests/sigalrm (stderr)
drd/tests/tc01_simple_race (stderr)
drd/tests/tc02_simple_tls (stderr)
drd/tests/tc03_re_excl (stderr)
drd/tests/tc05_simple_race (stderr)
drd/tests/tc06_two_races (stderr)
drd/tests/tc07_hbl1 (stderr)
drd/tests/tc08_hbl2 (stderr)
drd/tests/tc09_bad_unlock (stderr)
drd/tests/tc11_XCHG (stderr)
drd/tests/tc16_byterace (stderr)
drd/tests/tc17_sembar (stderr)
drd/tests/tc19_shadowmem (stderr)
drd/tests/tc21_pthonce (stderr)
drd/tests/tc23_bogus_condwait (stderr)
drd/tests/thread_name (stderr)
drd/tests/thread_name_xml (stderr)
drd/tests/threaded-fork (stderr)
drd/tests/unit_bitmap (stderr)
drd/tests/unit_vc (stderr)
=================================================
== Results from 24 hours ago ==
=================================================
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests ... failed
Regression test results follow
== 510 tests, 150 stderr failures, 4 stdout failures, 3 stderrB failures, 3 stdoutB failures, 1 post failure ==
gdbserver_tests/mchelp (stdoutB)
gdbserver_tests/mchelp (stderrB)
gdbserver_tests/mcinvokeRU (stdoutB)
gdbserver_tests/mcinvokeRU (stderrB)
gdbserver_tests/mcinvokeWS (stdoutB)
gdbserver_tests/mcinvokeWS (stderrB)
memcheck/tests/accounting (stderr)
memcheck/tests/badpoll (stderr)
memcheck/tests/big_blocks_freed_list (stderr)
memcheck/tests/bug287260 (stderr)
memcheck/tests/darwin/aio (stderr)
memcheck/tests/darwin/pth-supp (stderr)
memcheck/tests/darwin/scalar (stderr)
memcheck/tests/deep-backtrace (stderr)
memcheck/tests/err_disable4 (stderr)
memcheck/tests/leak-delta (stderr)
memcheck/tests/leak-segv-jmp (stderr)
memcheck/tests/lks (stderr)
memcheck/tests/memcmptest (stderr)
memcheck/tests/mismatches (stderr)
memcheck/tests/null_socket (stdout)
memcheck/tests/origin5-bz2 (stderr)
memcheck/tests/overlap (stdout)
memcheck/tests/overlap (stderr)
memcheck/tests/sem (stderr)
memcheck/tests/sendmsg (stderr)
memcheck/tests/strchr (stderr)
memcheck/tests/test-plo-no (stderr)
memcheck/tests/varinfo3 (stderr)
memcheck/tests/varinfo5 (stderr)
memcheck/tests/vbit-test/vbit-test (stderr)
memcheck/tests/vcpu_fnfns (stdout)
memcheck/tests/writev1 (stderr)
massif/tests/big-alloc (post)
massif/tests/pages_as_heap (stderr)
none/tests/allexec32 (stderr)
none/tests/allexec64 (stderr)
none/tests/async-sigs (stderr)
none/tests/cmdline5 (stderr)
none/tests/execve (stderr)
none/tests/faultstatus (stderr)
none/tests/mmap_fcntl_bug (stderr)
none/tests/nodir (stderr)
none/tests/pth_blockedsig (stderr)
none/tests/require-text-symbol-2 (stderr)
none/tests/rlimit64_nofile (stderr)
none/tests/shell_nosuchfile (stderr)
none/tests/x86/cse_fail (stdout)
helgrind/tests/annotate_hbefore (stderr)
helgrind/tests/annotate_rwlock (stderr)
helgrind/tests/annotate_smart_pointer (stderr)
helgrind/tests/cond_timedwait_invalid (stderr)
helgrind/tests/free_is_write (stderr)
helgrind/tests/hg01_all_ok (stderr)
helgrind/tests/hg02_deadlock (stderr)
helgrind/tests/hg03_inherit (stderr)
helgrind/tests/hg04_race (stderr)
helgrind/tests/hg05_race2 (stderr)
helgrind/tests/hg06_readshared (stderr)
helgrind/tests/locked_vs_unlocked1_fwd (stderr)
helgrind/tests/locked_vs_unlocked1_rev (stderr)
helgrind/tests/locked_vs_unlocked2 (stderr)
helgrind/tests/locked_vs_unlocked3 (stderr)
helgrind/tests/pth_destroy_cond (stderr)
helgrind/tests/rwlock_race (stderr)
helgrind/tests/rwlock_test (stderr)
helgrind/tests/t2t_laog (stderr)
helgrind/tests/tc01_simple_race (stderr)
helgrind/tests/tc02_simple_tls (stderr)
helgrind/tests/tc03_re_excl (stderr)
helgrind/tests/tc04_free_lock (stderr)
helgrind/tests/tc05_simple_race (stderr)
helgrind/tests/tc06_two_races (stderr)
helgrind/tests/tc06_two_races_xml (stderr)
helgrind/tests/tc07_hbl1 (stderr)
helgrind/tests/tc08_hbl2 (stderr)
helgrind/tests/tc09_bad_unlock (stderr)
helgrind/tests/tc10_rec_lock (stderr)
helgrind/tests/tc11_XCHG (stderr)
helgrind/tests/tc12_rwl_trivial (stderr)
helgrind/tests/tc13_laog1 (stderr)
helgrind/tests/tc14_laog_dinphils (stderr)
helgrind/tests/tc15_laog_lockdel (stderr)
helgrind/tests/tc16_byterace (stderr)
helgrind/tests/tc17_sembar (stderr)
helgrind/tests/tc18_semabuse (stderr)
helgrind/tests/tc19_shadowmem (stderr)
helgrind/tests/tc21_pthonce (stderr)
helgrind/tests/tc23_bogus_condwait (stderr)
helgrind/tests/tc24_nonzero_sem (stderr)
drd/tests/annotate_barrier (stderr)
drd/tests/annotate_barrier_xml (stderr)
drd/tests/annotate_hb_race (stderr)
drd/tests/annotate_hbefore (stderr)
drd/tests/annotate_ignore_read (stderr)
drd/tests/annotate_ignore_rw (stderr)
drd/tests/annotate_ignore_rw2 (stderr)
drd/tests/annotate_ignore_write (stderr)
drd/tests/annotate_ignore_write2 (stderr)
drd/tests/annotate_order_1 (stderr)
drd/tests/annotate_order_2 (stderr)
drd/tests/annotate_order_3 (stderr)
drd/tests/annotate_rwlock (stderr)
drd/tests/annotate_smart_pointer (stderr)
drd/tests/annotate_smart_pointer2 (stderr)
drd/tests/annotate_spinlock (stderr)
drd/tests/annotate_static (stderr)
drd/tests/atomic_var (stderr)
drd/tests/bug-235681 (stderr)
drd/tests/circular_buffer (stderr)
drd/tests/fp_race (stderr)
drd/tests/fp_race2 (stderr)
drd/tests/fp_race_xml (stderr)
drd/tests/free_is_write (stderr)
drd/tests/free_is_write2 (stderr)
drd/tests/hg01_all_ok (stderr)
drd/tests/hg02_deadlock (stderr)
drd/tests/hg03_inherit (stderr)
drd/tests/hg04_race (stderr)
drd/tests/hg05_race2 (stderr)
drd/tests/hg06_readshared (stderr)
drd/tests/linuxthreads_det (stderr)
drd/tests/monitor_example (stderr)
drd/tests/pth_broadcast (stderr)
drd/tests/pth_cleanup_handler (stderr)
drd/tests/pth_cond_destroy_busy (stderr)
drd/tests/pth_cond_race (stderr)
drd/tests/pth_cond_race2 (stderr)
drd/tests/pth_cond_race3 (stderr)
drd/tests/pth_create_chain (stderr)
drd/tests/pth_detached3 (stderr)
drd/tests/pth_inconsistent_cond_wait (stderr)
drd/tests/pth_once (stderr)
drd/tests/read_and_free_race (stderr)
drd/tests/rwlock_race (stderr)
drd/tests/rwlock_test (stderr)
drd/tests/sem_open (stderr)
drd/tests/sem_open2 (stderr)
drd/tests/sem_open3 (stderr)
drd/tests/sem_open_traced (stderr)
drd/tests/sem_wait (stderr)
drd/tests/sigalrm (stderr)
drd/tests/tc01_simple_race (stderr)
drd/tests/tc02_simple_tls (stderr)
drd/tests/tc03_re_excl (stderr)
drd/tests/tc05_simple_race (stderr)
drd/tests/tc06_two_races (stderr)
drd/tests/tc07_hbl1 (stderr)
drd/tests/tc08_hbl2 (stderr)
drd/tests/tc09_bad_unlock (stderr)
drd/tests/tc11_XCHG (stderr)
drd/tests/tc16_byterace (stderr)
drd/tests/tc17_sembar (stderr)
drd/tests/tc19_shadowmem (stderr)
drd/tests/tc21_pthonce (stderr)
drd/tests/tc23_bogus_condwait (stderr)
drd/tests/thread_name (stderr)
drd/tests/thread_name_xml (stderr)
drd/tests/threaded-fork (stderr)
drd/tests/unit_bitmap (stderr)
drd/tests/unit_vc (stderr)
=================================================
== Difference between 24 hours ago and now ==
=================================================
*** old.short Sun Mar 10 23:56:06 2013
--- new.short Mon Mar 11 00:16:55 2013
***************
*** 8,10 ****
! == 510 tests, 150 stderr failures, 4 stdout failures, 3 stderrB failures, 3 stdoutB failures, 1 post failure ==
gdbserver_tests/mchelp (stdoutB)
--- 8,10 ----
! == 509 tests, 149 stderr failures, 4 stdout failures, 3 stderrB failures, 3 stdoutB failures, 1 post failure ==
gdbserver_tests/mchelp (stdoutB)
***************
*** 149,151 ****
drd/tests/sem_open_traced (stderr)
- drd/tests/sem_wait (stderr)
drd/tests/sigalrm (stderr)
--- 149,150 ----
=================================================
./valgrind-new/drd/tests/annotate_barrier.stderr.diff
=================================================
--- annotate_barrier.stderr.exp 2013-03-10 23:56:22.000000000 -0500
+++ annotate_barrier.stderr.out 2013-03-11 00:14:03.000000000 -0500
@@ -37,6 +37,123 @@
by 0x........: vgDrd_thread_wrapper (drd_pthread_intercepts.c:?)
Thread 1:
+Conflicting load by thread 1 at 0x........ size 4
+ at 0x........: ???
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting load by thread 1 at 0x........ size 4
+ at 0x........: new_sem_from_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting load by thread 1 at 0x........ size 4
+ at 0x........: new_sem_from_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting load by thread 1 at 0x........ size 4
+ at 0x........: new_sem_from_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting load by thread 1 at 0x........ size 4
+ at 0x........: new_sem_from_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+Address 0x........ is at offset 4 from 0x......... Allocation context:
+ at 0x........: malloc (vg_replace_malloc.c:...)
+ by 0x........: realloc (vg_replace_malloc.c:...)
+ by 0x........: new_sem_from_pool (in /...libc...)
+
+Conflicting store by thread 1 at 0x........ size 4
+ at 0x........: new_sem_from_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting load by thread 1 at 0x........ size 4
+ at 0x........: ???
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting load by thread 1 at 0x........ size 4
+ at 0x........: restore_sem_to_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting store by thread 1 at 0x........ size 4
+ at 0x........: restore_sem_to_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting load by thread 1 at 0x........ size 4
+ at 0x........: restore_sem_to_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting store by thread 1 at 0x........ size 4
+ at 0x........: restore_sem_to_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+Address 0x........ is at offset 4 from 0x......... Allocation context:
+ at 0x........: malloc (vg_replace_malloc.c:...)
+ by 0x........: realloc (vg_replace_malloc.c:...)
+ by 0x........: new_sem_from_pool (in /...libc...)
+
+Conflicting load by thread 1 at 0x........ size 4
+ at 0x........: ???
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting load by thread 1 at 0x........ size 4
+ at 0x........: ???
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting load by thread 1 at 0x........ size 4
+ at 0x........: restore_sem_to_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting store by thread 1 at 0x........ size 4
+ at 0x........: restore_sem_to_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
<truncated beyond 100 lines>
=================================================
./valgrind-new/drd/tests/annotate_barrier_xml.stderr.diff
=================================================
--- annotate_barrier_xml.stderr.exp 2013-03-10 23:56:23.000000000 -0500
+++ annotate_barrier_xml.stderr.out 2013-03-11 00:14:04.000000000 -0500
@@ -188,7 +188,7 @@
<frame>
<ip>0x........</ip>
<obj>...</obj>
- <fn>start_thread</fn>
+ <fn>_pthread_start</fn>
</frame>
</stack>
<auxwhat>Address 0x........ is at offset 0 from 0x.........</auxwhat>
@@ -258,6 +258,549 @@
<error>
<unique>0x........</unique>
<tid>...</tid>
+ <kind>ConflictingAccess</kind>
+ <what>Conflicting load by thread 1 at 0x........ size 4</what>
+ <stack>
+ <frame>
+ <ip>0x........</ip>
+ </frame>
+ <frame>
+ <ip>0x........</ip>
+ <obj>...</obj>
+ <fn>pthread_join$UNIX2003</fn>
+ </frame>
+ <frame>
+ <ip>0x........</ip>
+ <obj>...</obj>
+ <fn>pthread_join$*</fn>
+ <dir>...</dir>
+ <file>drd_pthread_intercepts.c</file>
+ <line>...</line>
+ </frame>
+ </stack>
+ <auxwhat>Allocation context: Data section of /usr/lib/libSystem.B.dylib</auxwhat>
+</error>
+
+<error>
+ <unique>0x........</unique>
+ <tid>...</tid>
+ <kind>ConflictingAccess</kind>
+ <what>Conflicting load by thread 1 at 0x........ size 4</what>
+ <stack>
+ <frame>
+ <ip>0x........</ip>
+ <obj>...</obj>
+ <fn>new_sem_from_pool</fn>
+ </frame>
+ <frame>
+ <ip>0x........</ip>
+ <obj>...</obj>
+ <fn>pthread_join$UNIX2003</fn>
+ </frame>
+ <frame>
+ <ip>0x........</ip>
+ <obj>...</obj>
+ <fn>pthread_join$*</fn>
+ <dir>...</dir>
+ <file>drd_pthread_intercepts.c</file>
+ <line>...</line>
+ </frame>
+ </stack>
+ <auxwhat>Allocation context: Data section of /usr/lib/libSystem.B.dylib</auxwhat>
+</error>
+
+<error>
+ <unique>0x........</unique>
+ <tid>...</tid>
+ <kind>ConflictingAccess</kind>
+ <what>Conflicting load by thread 1 at 0x........ size 4</what>
+ <stack>
+ <frame>
+ <ip>0x........</ip>
+ <obj>...</obj>
+ <fn>new_sem_from_pool</fn>
+ </frame>
+ <frame>
+ <ip>0x........</ip>
+ <obj>...</obj>
+ <fn>pthread_join$UNIX2003</fn>
+ </frame>
+ <frame>
+ <ip>0x........</ip>
+ <obj>...</obj>
+ <fn>pthread_join$*</fn>
+ <dir>...</dir>
+ <file>drd_pthread_intercepts.c</file>
+ <line>...</line>
+ </frame>
+ </stack>
+ <auxwhat>Allocation context: Data section of /usr/lib/libSystem.B.dylib</auxwhat>
+</error>
+
+<error>
+ <unique>0x........</unique>
+ <tid>...</tid>
+ <kind>ConflictingAccess</kind>
+ <what>Conflicting load by thread 1 at 0x........ size 4</what>
+ <stack>
<truncated beyond 100 lines>
=================================================
./valgrind-new/drd/tests/annotate_hb_race.stderr.diff
=================================================
--- annotate_hb_race.stderr.exp 2013-03-10 23:56:23.000000000 -0500
+++ annotate_hb_race.stderr.out 2013-03-11 00:14:06.000000000 -0500
@@ -3,6 +3,60 @@
at 0x........: main (annotate_hb_race.c:?)
Allocation context: BSS section of annotate_hb_race
+Conflicting load by thread x at 0x........ size 4
+ at 0x........: ???
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: main (annotate_hb_race.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting load by thread x at 0x........ size 4
+ at 0x........: ???
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: main (annotate_hb_race.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting load by thread x at 0x........ size 4
+ at 0x........: restore_sem_to_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: main (annotate_hb_race.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting store by thread x at 0x........ size 4
+ at 0x........: restore_sem_to_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: main (annotate_hb_race.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting load by thread x at 0x........ size 4
+ at 0x........: restore_sem_to_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: main (annotate_hb_race.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting store by thread x at 0x........ size 4
+ at 0x........: restore_sem_to_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: main (annotate_hb_race.c:?)
+Address 0x........ is at offset 4 from 0x......... Allocation context:
+ at 0x........: malloc (vg_replace_malloc.c:...)
+ by 0x........: realloc (vg_replace_malloc.c:...)
+ by 0x........: new_sem_from_pool (in /...libc...)
+ by 0x........: _pthread_exit (in /...libc...)
+ by 0x........: thread_start (in /...libc...)
+
+Conflicting load by thread x at 0x........ size 4
+ at 0x........: ???
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: main (annotate_hb_race.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
Done.
-ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
+ERROR SUMMARY: 8 errors from 8 contexts (suppressed: 0 from 0)
=================================================
./valgrind-new/drd/tests/annotate_hbefore.stderr.diff
=================================================
--- annotate_hbefore.stderr.exp 2013-03-10 23:56:23.000000000 -0500
+++ annotate_hbefore.stderr.out 2013-03-11 00:14:08.000000000 -0500
@@ -1,3 +1,44 @@
+Conflicting load by thread 1 at 0x........ size 4
+ at 0x........: ???
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: main (annotate_hbefore.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
-ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
+Conflicting load by thread 1 at 0x........ size 4
+ at 0x........: restore_sem_to_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: main (annotate_hbefore.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting store by thread 1 at 0x........ size 4
+ at 0x........: restore_sem_to_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: main (annotate_hbefore.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting store by thread 1 at 0x........ size 4
+ at 0x........: restore_sem_to_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: main (annotate_hbefore.c:?)
+Address 0x........ is at offset 4 from 0x......... Allocation context:
+ at 0x........: malloc (vg_replace_malloc.c:...)
+ by 0x........: realloc (vg_replace_malloc.c:...)
+ by 0x........: new_sem_from_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: main (annotate_hbefore.c:?)
+
+Conflicting load by thread 1 at 0x........ size 4
+ at 0x........: ???
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: main (annotate_hbefore.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+
+ERROR SUMMARY: 5 errors from 5 contexts (suppressed: 0 from 0)
=================================================
./valgrind-new/drd/tests/annotate_ignore_read.stderr.diff
=================================================
--- annotate_ignore_read.stderr.exp 2013-03-10 23:56:23.000000000 -0500
+++ annotate_ignore_read.stderr.out 2013-03-11 00:14:09.000000000 -0500
@@ -1,6 +1,159 @@
FLAGS [phb=1, fm=0]
test69: negative
+Conflicting load by thread x at 0x........ size 4
+ at 0x........: ???
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: MyThread::Join() (tsan_thread_wrappers_pthread.h:?)
+ by 0x........: MyThreadArray::Join() (tsan_unittest.cpp:?)
+ by 0x........: test69::Run() (tsan_unittest.cpp:?)
+ by 0x........: Test::Run() (tsan_unittest.cpp:?)
+ by 0x........: main (tsan_unittest.cpp:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting load by thread x at 0x........ size 4
+ at 0x........: ???
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: MyThread::Join() (tsan_thread_wrappers_pthread.h:?)
+ by 0x........: MyThreadArray::Join() (tsan_unittest.cpp:?)
+ by 0x........: test69::Run() (tsan_unittest.cpp:?)
+ by 0x........: Test::Run() (tsan_unittest.cpp:?)
+ by 0x........: main (tsan_unittest.cpp:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting load by thread x at 0x........ size 4
+ at 0x........: new_sem_from_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: MyThread::Join() (tsan_thread_wrappers_pthread.h:?)
+ by 0x........: MyThreadArray::Join() (tsan_unittest.cpp:?)
+ by 0x........: test69::Run() (tsan_unittest.cpp:?)
+ by 0x........: Test::Run() (tsan_unittest.cpp:?)
+ by 0x........: main (tsan_unittest.cpp:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting load by thread x at 0x........ size 4
+ at 0x........: new_sem_from_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: MyThread::Join() (tsan_thread_wrappers_pthread.h:?)
+ by 0x........: MyThreadArray::Join() (tsan_unittest.cpp:?)
+ by 0x........: test69::Run() (tsan_unittest.cpp:?)
+ by 0x........: Test::Run() (tsan_unittest.cpp:?)
+ by 0x........: main (tsan_unittest.cpp:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting load by thread x at 0x........ size 4
+ at 0x........: new_sem_from_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: MyThread::Join() (tsan_thread_wrappers_pthread.h:?)
+ by 0x........: MyThreadArray::Join() (tsan_unittest.cpp:?)
+ by 0x........: test69::Run() (tsan_unittest.cpp:?)
+ by 0x........: Test::Run() (tsan_unittest.cpp:?)
+ by 0x........: main (tsan_unittest.cpp:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting load by thread x at 0x........ size 4
+ at 0x........: new_sem_from_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: MyThread::Join() (tsan_thread_wrappers_pthread.h:?)
+ by 0x........: MyThreadArray::Join() (tsan_unittest.cpp:?)
+ by 0x........: test69::Run() (tsan_unittest.cpp:?)
+ by 0x........: Test::Run() (tsan_unittest.cpp:?)
+ by 0x........: main (tsan_unittest.cpp:?)
+Address 0x........ is at offset 12 from 0x......... Allocation context:
+ at 0x........: malloc (vg_replace_malloc.c:...)
+ by 0x........: realloc (vg_replace_malloc.c:...)
+ by 0x........: new_sem_from_pool (in /...libc...)
+ by 0x........: _pthread_exit (in /...libc...)
+ by 0x........: thread_start (in /...libc...)
+
+Conflicting store by thread x at 0x........ size 4
+ at 0x........: new_sem_from_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: MyThread::Join() (tsan_thread_wrappers_pthread.h:?)
+ by 0x........: MyThreadArray::Join() (tsan_unittest.cpp:?)
+ by 0x........: test69::Run() (tsan_unittest.cpp:?)
+ by 0x........: Test::Run() (tsan_unittest.cpp:?)
+ by 0x........: main (tsan_unittest.cpp:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting load by thread x at 0x........ size 4
+ at 0x........: ???
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: MyThread::Join() (tsan_thread_wrappers_pthread.h:?)
+ by 0x........: MyThreadArray::Join() (tsan_unittest.cpp:?)
+ by 0x........: test69::Run() (tsan_unittest.cpp:?)
+ by 0x........: Test::Run() (tsan_unittest.cpp:?)
+ by 0x........: main (tsan_unittest.cpp:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting load by thread x at 0x........ size 4
<truncated beyond 100 lines>
=================================================
./valgrind-new/drd/tests/annotate_ignore_rw.stderr.diff
=================================================
--- annotate_ignore_rw.stderr.exp 2013-03-10 23:56:23.000000000 -0500
+++ annotate_ignore_rw.stderr.out 2013-03-11 00:14:11.000000000 -0500
@@ -4,6 +4,60 @@
Location 0x........ is 0 bytes inside global var "s_c"
declared at annotate_ignore_rw.c:12
+Conflicting load by thread 1 at 0x........ size 4
+ at 0x........: ???
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: main (annotate_ignore_rw.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting load by thread 1 at 0x........ size 4
+ at 0x........: ???
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: main (annotate_ignore_rw.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting load by thread 1 at 0x........ size 4
+ at 0x........: restore_sem_to_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: main (annotate_ignore_rw.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting store by thread 1 at 0x........ size 4
+ at 0x........: restore_sem_to_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: main (annotate_ignore_rw.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting load by thread 1 at 0x........ size 4
+ at 0x........: restore_sem_to_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: main (annotate_ignore_rw.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting store by thread 1 at 0x........ size 4
+ at 0x........: restore_sem_to_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: main (annotate_ignore_rw.c:?)
+Address 0x........ is at offset 0 from 0x......... Allocation context:
+ at 0x........: malloc (vg_replace_malloc.c:...)
+ by 0x........: realloc (vg_replace_malloc.c:...)
+ by 0x........: new_sem_from_pool (in /...libc...)
+ by 0x........: _pthread_exit (in /...libc...)
+ by 0x........: thread_start (in /...libc...)
+
+Conflicting load by thread 1 at 0x........ size 4
+ at 0x........: ???
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: main (annotate_ignore_rw.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
Finished.
-ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
+ERROR SUMMARY: 8 errors from 8 contexts (suppressed: 0 from 0)
=================================================
./valgrind-new/drd/tests/annotate_ignore_rw2.stderr.diff
=================================================
--- annotate_ignore_rw2.stderr.exp 2013-03-10 23:56:23.000000000 -0500
+++ annotate_ignore_rw2.stderr.out 2013-03-11 00:14:13.000000000 -0500
@@ -14,6 +14,60 @@
Location 0x........ is 0 bytes inside global var "s_c"
declared at annotate_ignore_rw.c:12
+Conflicting load by thread 1 at 0x........ size 4
+ at 0x........: ???
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: main (annotate_ignore_rw.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting load by thread 1 at 0x........ size 4
+ at 0x........: ???
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: main (annotate_ignore_rw.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting load by thread 1 at 0x........ size 4
+ at 0x........: restore_sem_to_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: main (annotate_ignore_rw.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting store by thread 1 at 0x........ size 4
+ at 0x........: restore_sem_to_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: main (annotate_ignore_rw.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting load by thread 1 at 0x........ size 4
+ at 0x........: restore_sem_to_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: main (annotate_ignore_rw.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting store by thread 1 at 0x........ size 4
+ at 0x........: restore_sem_to_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: main (annotate_ignore_rw.c:?)
+Address 0x........ is at offset 0 from 0x......... Allocation context:
+ at 0x........: malloc (vg_replace_malloc.c:...)
+ by 0x........: realloc (vg_replace_malloc.c:...)
+ by 0x........: new_sem_from_pool (in /...libc...)
+ by 0x........: _pthread_exit (in /...libc...)
+ by 0x........: thread_start (in /...libc...)
+
+Conflicting load by thread 1 at 0x........ size 4
+ at 0x........: ???
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: main (annotate_ignore_rw.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
Finished.
-ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)
+ERROR SUMMARY: 10 errors from 10 contexts (suppressed: 0 from 0)
=================================================
./valgrind-new/drd/tests/annotate_ignore_write.stderr.diff
=================================================
--- annotate_ignore_write.stderr.exp 2013-03-10 23:56:22.000000000 -0500
+++ annotate_ignore_write.stderr.out 2013-03-11 00:14:14.000000000 -0500
@@ -14,6 +14,60 @@
Location 0x........ is 0 bytes inside global var "s_a"
declared at annotate_ignore_write.c:10
+Conflicting load by thread 1 at 0x........ size 4
+ at 0x........: ???
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: main (annotate_ignore_write.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting load by thread 1 at 0x........ size 4
+ at 0x........: ???
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: main (annotate_ignore_write.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting load by thread 1 at 0x........ size 4
+ at 0x........: restore_sem_to_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: main (annotate_ignore_write.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting store by thread 1 at 0x........ size 4
+ at 0x........: restore_sem_to_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: main (annotate_ignore_write.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting load by thread 1 at 0x........ size 4
+ at 0x........: restore_sem_to_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: main (annotate_ignore_write.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting store by thread 1 at 0x........ size 4
+ at 0x........: restore_sem_to_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: main (annotate_ignore_write.c:?)
+Address 0x........ is at offset 0 from 0x......... Allocation context:
+ at 0x........: malloc (vg_replace_malloc.c:...)
+ by 0x........: realloc (vg_replace_malloc.c:...)
+ by 0x........: new_sem_from_pool (in /...libc...)
+ by 0x........: _pthread_exit (in /...libc...)
+ by 0x........: thread_start (in /...libc...)
+
+Conflicting load by thread 1 at 0x........ size 4
+ at 0x........: ???
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: main (annotate_ignore_write.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
Finished.
-ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)
+ERROR SUMMARY: 10 errors from 10 contexts (suppressed: 0 from 0)
=================================================
./valgrind-new/drd/tests/annotate_ignore_write2.stderr.diff
=================================================
--- annotate_ignore_write2.stderr.exp 2013-03-10 23:56:22.000000000 -0500
+++ annotate_ignore_write2.stderr.out 2013-03-11 00:14:15.000000000 -0500
@@ -19,6 +19,60 @@
Location 0x........ is 0 bytes inside global var "s_a"
declared at annotate_ignore_write.c:10
+Conflicting load by thread 1 at 0x........ size 4
+ at 0x........: ???
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: main (annotate_ignore_write.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting load by thread 1 at 0x........ size 4
+ at 0x........: ???
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: main (annotate_ignore_write.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting load by thread 1 at 0x........ size 4
+ at 0x........: restore_sem_to_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: main (annotate_ignore_write.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting store by thread 1 at 0x........ size 4
+ at 0x........: restore_sem_to_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: main (annotate_ignore_write.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting load by thread 1 at 0x........ size 4
+ at 0x........: restore_sem_to_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: main (annotate_ignore_write.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting store by thread 1 at 0x........ size 4
+ at 0x........: restore_sem_to_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: main (annotate_ignore_write.c:?)
+Address 0x........ is at offset 0 from 0x......... Allocation context:
+ at 0x........: malloc (vg_replace_malloc.c:...)
+ by 0x........: realloc (vg_replace_malloc.c:...)
+ by 0x........: new_sem_from_pool (in /...libc...)
+ by 0x........: _pthread_exit (in /...libc...)
+ by 0x........: thread_start (in /...libc...)
+
+Conflicting load by thread 1 at 0x........ size 4
+ at 0x........: ???
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: main (annotate_ignore_write.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
Finished.
-ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 0 from 0)
+ERROR SUMMARY: 11 errors from 11 contexts (suppressed: 0 from 0)
=================================================
./valgrind-new/drd/tests/annotate_order_1.stderr.diff
=================================================
--- annotate_order_1.stderr.exp 2013-03-10 23:56:22.000000000 -0500
+++ annotate_order_1.stderr.out 2013-03-11 00:14:16.000000000 -0500
@@ -1,6 +1,18 @@
FLAGS [phb=1, fm=0]
test03: negative
+Conflicting load by thread x at 0x........ size 4
+ at 0x........: ???
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: MyThread::Join() (tsan_thread_wrappers_pthread.h:?)
+ by 0x........: ThreadPool::~ThreadPool() (tsan_thread_wrappers_pthread.h:?)
+ by 0x........: test03::Waiter() (tsan_unittest.cpp:?)
+ by 0x........: test03::Run() (tsan_unittest.cpp:?)
+ by 0x........: Test::Run() (tsan_unittest.cpp:?)
+ by 0x........: main (tsan_unittest.cpp:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
GLOB=2
-ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
+ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
=================================================
./valgrind-new/drd/tests/annotate_order_2.stderr.diff
=================================================
--- annotate_order_2.stderr.exp 2013-03-10 23:56:22.000000000 -0500
+++ annotate_order_2.stderr.out 2013-03-11 00:14:18.000000000 -0500
@@ -1,6 +1,88 @@
FLAGS [phb=1, fm=0]
test30: negative
+Conflicting load by thread x at 0x........ size 4
+ at 0x........: ???
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: MyThread::Join() (tsan_thread_wrappers_pthread.h:?)
+ by 0x........: MyThreadArray::Join() (tsan_unittest.cpp:?)
+ by 0x........: test30::Run() (tsan_unittest.cpp:?)
+ by 0x........: Test::Run() (tsan_unittest.cpp:?)
+ by 0x........: main (tsan_unittest.cpp:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting load by thread x at 0x........ size 4
+ at 0x........: ???
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: MyThread::Join() (tsan_thread_wrappers_pthread.h:?)
+ by 0x........: MyThreadArray::Join() (tsan_unittest.cpp:?)
+ by 0x........: test30::Run() (tsan_unittest.cpp:?)
+ by 0x........: Test::Run() (tsan_unittest.cpp:?)
+ by 0x........: main (tsan_unittest.cpp:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting load by thread x at 0x........ size 4
+ at 0x........: restore_sem_to_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: MyThread::Join() (tsan_thread_wrappers_pthread.h:?)
+ by 0x........: MyThreadArray::Join() (tsan_unittest.cpp:?)
+ by 0x........: test30::Run() (tsan_unittest.cpp:?)
+ by 0x........: Test::Run() (tsan_unittest.cpp:?)
+ by 0x........: main (tsan_unittest.cpp:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting store by thread x at 0x........ size 4
+ at 0x........: restore_sem_to_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: MyThread::Join() (tsan_thread_wrappers_pthread.h:?)
+ by 0x........: MyThreadArray::Join() (tsan_unittest.cpp:?)
+ by 0x........: test30::Run() (tsan_unittest.cpp:?)
+ by 0x........: Test::Run() (tsan_unittest.cpp:?)
+ by 0x........: main (tsan_unittest.cpp:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting load by thread x at 0x........ size 4
+ at 0x........: restore_sem_to_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: MyThread::Join() (tsan_thread_wrappers_pthread.h:?)
+ by 0x........: MyThreadArray::Join() (tsan_unittest.cpp:?)
+ by 0x........: test30::Run() (tsan_unittest.cpp:?)
+ by 0x........: Test::Run() (tsan_unittest.cpp:?)
+ by 0x........: main (tsan_unittest.cpp:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting store by thread x at 0x........ size 4
+ at 0x........: restore_sem_to_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: MyThread::Join() (tsan_thread_wrappers_pthread.h:?)
+ by 0x........: MyThreadArray::Join() (tsan_unittest.cpp:?)
+ by 0x........: test30::Run() (tsan_unittest.cpp:?)
+ by 0x........: Test::Run() (tsan_unittest.cpp:?)
+ by 0x........: main (tsan_unittest.cpp:?)
+Address 0x........ is at offset 12 from 0x......... Allocation context:
+ at 0x........: malloc (vg_replace_malloc.c:...)
+ by 0x........: realloc (vg_replace_malloc.c:...)
+ by 0x........: new_sem_from_pool (in /...libc...)
+ by 0x........: _pthread_exit (in /...libc...)
+ by 0x........: thread_start (in /...libc...)
+
+Conflicting load by thread x at 0x........ size 4
+ at 0x........: ???
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: MyThread::Join() (tsan_thread_wrappers_pthread.h:?)
+ by 0x........: MyThreadArray::Join() (tsan_unittest.cpp:?)
+ by 0x........: test30::Run() (tsan_unittest.cpp:?)
+ by 0x........: Test::Run() (tsan_unittest.cpp:?)
+ by 0x........: main (tsan_unittest.cpp:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
GLOB=47
-ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
+ERROR SUMMARY: 7 errors from 7 contexts (suppressed: 0 from 0)
=================================================
./valgrind-new/drd/tests/annotate_order_3.stderr.diff
=================================================
--- annotate_order_3.stderr.exp 2013-03-10 23:56:23.000000000 -0500
+++ annotate_order_3.stderr.out 2013-03-11 00:14:20.000000000 -0500
@@ -1,6 +1,71 @@
FLAGS [phb=1, fm=0]
test31: negative
+Conflicting load by thread x at 0x........ size 4
+ at 0x........: ???
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: MyThread::Join() (tsan_thread_wrappers_pthread.h:?)
+ by 0x........: MyThreadArray::Join() (tsan_unittest.cpp:?)
+ by 0x........: test31::Run() (tsan_unittest.cpp:?)
+ by 0x........: Test::Run() (tsan_unittest.cpp:?)
+ by 0x........: main (tsan_unittest.cpp:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting load by thread x at 0x........ size 4
+ at 0x........: restore_sem_to_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: MyThread::Join() (tsan_thread_wrappers_pthread.h:?)
+ by 0x........: MyThreadArray::Join() (tsan_unittest.cpp:?)
+ by 0x........: test31::Run() (tsan_unittest.cpp:?)
+ by 0x........: Test::Run() (tsan_unittest.cpp:?)
+ by 0x........: main (tsan_unittest.cpp:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting store by thread x at 0x........ size 4
+ at 0x........: restore_sem_to_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: MyThread::Join() (tsan_thread_wrappers_pthread.h:?)
+ by 0x........: MyThreadArray::Join() (tsan_unittest.cpp:?)
+ by 0x........: test31::Run() (tsan_unittest.cpp:?)
+ by 0x........: Test::Run() (tsan_unittest.cpp:?)
+ by 0x........: main (tsan_unittest.cpp:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting store by thread x at 0x........ size 4
+ at 0x........: restore_sem_to_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: MyThread::Join() (tsan_thread_wrappers_pthread.h:?)
+ by 0x........: MyThreadArray::Join() (tsan_unittest.cpp:?)
+ by 0x........: test31::Run() (tsan_unittest.cpp:?)
+ by 0x........: Test::Run() (tsan_unittest.cpp:?)
+ by 0x........: main (tsan_unittest.cpp:?)
+Address 0x........ is at offset 4 from 0x......... Allocation context:
+ at 0x........: malloc (vg_replace_malloc.c:...)
+ by 0x........: realloc (vg_replace_malloc.c:...)
+ by 0x........: new_sem_from_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: MyThread::Join() (tsan_thread_wrappers_pthread.h:?)
+ by 0x........: MyThreadArray::Join() (tsan_unittest.cpp:?)
+ by 0x........: test31::Run() (tsan_unittest.cpp:?)
+ by 0x........: Test::Run() (tsan_unittest.cpp:?)
+ by 0x........: main (tsan_unittest.cpp:?)
+
+Conflicting load by thread x at 0x........ size 4
+ at 0x........: ???
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: MyThread::Join() (tsan_thread_wrappers_pthread.h:?)
+ by 0x........: MyThreadArray::Join() (tsan_unittest.cpp:?)
+ by 0x........: test31::Run() (tsan_unittest.cpp:?)
+ by 0x........: Test::Run() (tsan_unittest.cpp:?)
+ by 0x........: main (tsan_unittest.cpp:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
GLOB=48
-ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
+ERROR SUMMARY: 5 errors from 5 contexts (suppressed: 0 from 0)
=================================================
./valgrind-new/drd/tests/annotate_rwlock.stderr.diff
=================================================
--- annotate_rwlock.stderr.exp 2013-03-10 23:56:22.000000000 -0500
+++ annotate_rwlock.stderr.out 2013-03-11 00:14:24.000000000 -0500
@@ -1,4 +1,58 @@
+Conflicting load by thread x at 0x........ size 4
+ at 0x........: ???
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: main (annotate_rwlock.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting load by thread x at 0x........ size 4
+ at 0x........: ???
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: main (annotate_rwlock.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting load by thread x at 0x........ size 4
+ at 0x........: restore_sem_to_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: main (annotate_rwlock.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting store by thread x at 0x........ size 4
+ at 0x........: restore_sem_to_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts.c:?)
+ by 0x........: main (annotate_rwlock.c:?)
+Allocation context: Data section of /usr/lib/libSystem.B.dylib
+
+Conflicting load by thread x at 0x........ size 4
+ at 0x........: restore_sem_to_pool (in /...libc...)
+ by 0x........: pthread_join$UNIX2003 (in /...libc...)
+ by 0x........: pthread_join (drd_pthread_intercepts....
[truncated message content] |
|
From: Tom H. <to...@co...> - 2013-03-11 04:08:30
|
valgrind revision: 13324 VEX revision: 2695 C compiler: gcc (GCC) 4.3.0 20080428 (Red Hat 4.3.0-8) GDB: Assembler: GNU assembler version 2.18.50.0.6-2 20080403 C library: GNU C Library stable release version 2.8 uname -mrs: Linux 3.7.1-5.fc18.x86_64 x86_64 Vendor version: Fedora release 9 (Sulphur) Nightly build on bristol ( x86_64, Fedora 9 ) Started at 2013-03-11 03:42:05 GMT Ended at 2013-03-11 04:08:12 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 624 tests, 1 stderr failure, 1 stdout failure, 0 stderrB failures, 0 stdoutB failures, 0 post failures == memcheck/tests/amd64/insn-pcmpistri (stderr) none/tests/amd64/sse4-64 (stdout) |