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
(4) |
2
(17) |
3
(9) |
4
(14) |
5
(10) |
6
(11) |
7
(8) |
|
8
(9) |
9
(11) |
10
(29) |
11
(27) |
12
(29) |
13
(36) |
14
(8) |
|
15
(18) |
16
(30) |
17
(25) |
18
(6) |
19
(16) |
20
(13) |
21
(10) |
|
22
(16) |
23
(7) |
24
(8) |
25
(13) |
26
(14) |
27
(14) |
28
(5) |
|
29
(6) |
30
(21) |
31
(14) |
|
|
|
|
|
From: Konstantin S. <kon...@gm...> - 2009-03-30 18:40:06
|
[changed subject] On Mon, Mar 30, 2009 at 2:10 PM, Bart Van Assche <bar...@gm...> wrote: > On Mon, Mar 30, 2009 at 4:53 PM, Konstantin Serebryany > <kon...@gm...> wrote: >>> Did you check whether DRD reports a false positive on your TLS test case ? >> >> DRD says nothing about TLS in this test (it prints lots of reports >> about _dl_lookup_symbol_x though) > > On which distro did this occur ? We have (a slightly modified) Ubuntu Hardy Heron LTS (8.04). > The following command does not > complain about _dl_lookup_symbol_x on Ubuntu 7.10 nor on openSUSE > 11.1: > > ./vg-in-place --tool=drd --check-stack-var=yes > drt/unittest/racecheck_unittest 130 using recent trunk: % ./vg-in-place --tool=drd --check-stack-var=yes ~/drt/trunk/unittest/racecheck_unittest 130 ==6335== Conflicting load by thread 1/1 at 0x0cb363a8 size 8 ==6335== at 0xC927332: _dl_lookup_symbol_x (in /usr/grte/v1/lib64/ld-2.3.6.so) ==6335== by 0xC92AB31: fixup (in /usr/grte/v1/lib64/ld-2.3.6.so) ==6335== by 0xC92A861: _dl_runtime_resolve (in /usr/grte/v1/lib64/ld-2.3.6.so) ==6335== by 0x41EB38: MyThreadArray::Start() (racecheck_unittest.cc:267) ==6335== by 0x40CB3C: test130::Run() (racecheck_unittest.cc:6059) ==6335== by 0x41F104: Test::Run() (racecheck_unittest.cc:161) ==6335== by 0x41616C: main (racecheck_unittest.cc:230) ... <more> the file default.supp does not seem to have anything relevant. In tsan I simply ignore everything inside ld-*.so. Helps with performance too. --kcc > > Bart. > |
|
From: <sv...@va...> - 2009-03-30 18:16:44
|
Author: bart
Date: 2009-03-30 19:16:30 +0100 (Mon, 30 Mar 2009)
New Revision: 9500
Log:
Updated test plan.
Modified:
trunk/drd/Testing.txt
Modified: trunk/drd/Testing.txt
===================================================================
--- trunk/drd/Testing.txt 2009-03-30 13:06:48 UTC (rev 9499)
+++ trunk/drd/Testing.txt 2009-03-30 18:16:30 UTC (rev 9500)
@@ -12,7 +12,7 @@
perl tests/vg_regtest drd
5. Run Konstantin's regression tests:
svn checkout http://data-race-test.googlecode.com/svn/trunk drt
- make -C drt/unittest -s build
+ make -C drt/unittest -s all
./vg-in-place --tool=drd --check-stack-var=yes drt/unittest/racecheck_unittest 2>&1|less
6. Test the slowdown for matinv for various matrix sizes via the script
drd/scripts/run-matinv (must be about 24 for i == 1 and about
|
|
From: Bart V. A. <bar...@gm...> - 2009-03-30 18:14:53
|
On Mon, Mar 30, 2009 at 8:09 PM, Louis Savard <ls...@so...> wrote: > errno contains -240 (0xffffff10) That's really strange -- I was expecting a positive value in errno. As Konstantin asked, it would help if you could post a test case that allows to reproduce this issue. Bart. |
|
From: Bart V. A. <bar...@gm...> - 2009-03-30 18:10:53
|
On Mon, Mar 30, 2009 at 4:53 PM, Konstantin Serebryany <kon...@gm...> wrote: >> Did you check whether DRD reports a false positive on your TLS test case ? > > DRD says nothing about TLS in this test (it prints lots of reports > about _dl_lookup_symbol_x though) On which distro did this occur ? The following command does not complain about _dl_lookup_symbol_x on Ubuntu 7.10 nor on openSUSE 11.1: ./vg-in-place --tool=drd --check-stack-var=yes drt/unittest/racecheck_unittest 130 Bart. |
|
From: Konstantin S. <kon...@gm...> - 2009-03-30 14:53:13
|
On Mon, Mar 30, 2009 at 6:42 PM, Bart Van Assche
<bar...@gm...> wrote:
> On Mon, Mar 30, 2009 at 4:33 PM, Konstantin Serebryany
> <kon...@gm...> wrote:
>> On Mon, Mar 30, 2009 at 6:22 PM, Bart Van Assche
>> <bar...@gm...> wrote:
>>> On Mon, Mar 30, 2009 at 3:17 PM, Konstantin Serebryany
>>> <kon...@gm...> wrote:
>>>> Does valgrind core do something special about TLS (thread-local storage)?
>>>
>>> Are you familiar with the implementation of TLS in the NPTL ?
>>
>> Nope. You?
>
> Did you check whether DRD reports a false positive on your TLS test case ?
DRD says nothing about TLS in this test (it prints lots of reports
about _dl_lookup_symbol_x though)
Helgrind report is given in my previous message.
ThreadSanitizer prints this:
==24659== WARNING: Possible data race during read of size 4 at 0x1243595C: {{{
==24659== T16 (locks held: {}):
==24659== #0 test130::RealWorker() racecheck_unittest.cc:6038
==24659== #1 MyThread::ThreadBody(MyThread*) thread_wrappers_pthread.h:320
==24659== #2 ThreadSanitizerStartThread ts_valgrind_intercepts.c:407
==24659== Concurrent write(s) happened at (OR AFTER) these points:
==24659== T10 (locks held: {}):
==24659== #0 test130::RealWorker() racecheck_unittest.cc:6036
==24659== #1 MyThread::ThreadBody(MyThread*) thread_wrappers_pthread.h:320
==24659== #2 ThreadSanitizerStartThread ts_valgrind_intercepts.c:407
==24659== }}}
ThreadSanitizer and Helgrind reports are different because
ThreadSanitizer ignores everything that happens inside pthread_create.
>
> If I remember correctly, the NPTL allocates an area at the top of the
> stack of each thread for internal use. This area contains a.o. a
> lookup table for pthread_key_t values, and this lookup table is
> accessed from more than one thread. The race conditions triggered by
> using TLS are in this lookup table. This is why the Drd tool ignores
> the top-of-stack area allocated by the NPTL. Suppressing race reports
> on _dl_allocate_tls_init() in Helgrind and ThreadSanitizer might help,
No suppressing.
I think we may need to treat _dl_allocate_tls_init (or something else
there) as a function that clears the memory state.
--kcc
> but I'm not sure this is a full solution.
>
> Bart.
>
|
|
From: Bart V. A. <bar...@gm...> - 2009-03-30 14:42:13
|
On Mon, Mar 30, 2009 at 4:33 PM, Konstantin Serebryany <kon...@gm...> wrote: > On Mon, Mar 30, 2009 at 6:22 PM, Bart Van Assche > <bar...@gm...> wrote: >> On Mon, Mar 30, 2009 at 3:17 PM, Konstantin Serebryany >> <kon...@gm...> wrote: >>> Does valgrind core do something special about TLS (thread-local storage)? >> >> Are you familiar with the implementation of TLS in the NPTL ? > > Nope. You? Did you check whether DRD reports a false positive on your TLS test case ? If I remember correctly, the NPTL allocates an area at the top of the stack of each thread for internal use. This area contains a.o. a lookup table for pthread_key_t values, and this lookup table is accessed from more than one thread. The race conditions triggered by using TLS are in this lookup table. This is why the Drd tool ignores the top-of-stack area allocated by the NPTL. Suppressing race reports on _dl_allocate_tls_init() in Helgrind and ThreadSanitizer might help, but I'm not sure this is a full solution. Bart. |
|
From: Konstantin S. <kon...@gm...> - 2009-03-30 14:33:54
|
On Mon, Mar 30, 2009 at 6:22 PM, Bart Van Assche <bar...@gm...> wrote: > On Mon, Mar 30, 2009 at 3:17 PM, Konstantin Serebryany > <kon...@gm...> wrote: >> Does valgrind core do something special about TLS (thread-local storage)? > > Are you familiar with the implementation of TLS in the NPTL ? Nope. You? The logs produced by helgrind make me think that we need to intercept something like _dl_allocate_tls_init: ==22589== Possible data race during read of size 1 at 0x1203495c by thread #11 ==22589== at 0x40CBB6: test130::RealWorker() (racecheck_unittest.cc:6038) ==22589== by 0x41E8FC: MyThread::ThreadBody(MyThread*) (thread_wrappers_pthread.h:320) ==22589== by 0xD54070F: mythread_wrapper (hg_intercepts.c:194) ==22589== by 0xD7490C9: start_thread (in /usr/grte/v1/lib64/libpthread-2.3.6.so) ==22589== by 0xE1AF811: clone (in /usr/grte/v1/lib64/libc-2.3.6.so) ==22589== This conflicts with a previous write of size 1 by thread #7 ==22589== at 0xC930508: memset (in /usr/grte/v1/lib64/ld-2.3.6.so) ==22589== by 0xC92D643: _dl_allocate_tls_init (in /usr/grte/v1/lib64/ld-2.3.6.so) ==22589== by 0xD7493F9: pthread_create@@GLIBC_2.2.5 (in /usr/grte/v1/lib64/libpthread-2.3.6.so) ==22589== by 0xD5405E4: pthread_create@* (hg_intercepts.c:214) ==22589== by 0x41E84A: MyThread::Start() (thread_wrappers_pthread.h:312) ==22589== by 0x41EB2E: MyThreadArray::Start() (racecheck_unittest.cc:266) ==22589== by 0x4099EB: test130::Worker() (racecheck_unittest.cc:6048) ==22589== by 0x410FE6: test130::Worker2() (racecheck_unittest.cc:6053) ==22589== > > Bart. > |
|
From: Bart V. A. <bar...@gm...> - 2009-03-30 14:22:46
|
On Mon, Mar 30, 2009 at 3:17 PM, Konstantin Serebryany <kon...@gm...> wrote: > Does valgrind core do something special about TLS (thread-local storage)? Are you familiar with the implementation of TLS in the NPTL ? Bart. |
|
From: Nicholas N. <n.n...@gm...> - 2009-03-30 13:45:19
|
On Mon, Mar 30, 2009 at 8:17 AM, Konstantin Serebryany <kon...@gm...> wrote: > Hi valgrind developers, > > Does valgrind core do something special about TLS (thread-local storage)? > > I've recently discovered a false positive in ThreadSanitizer which is > caused by TLS. > Helgrind also emits a race report on the same test case. > Test: > // - Thread1 starts > // - Thread1 touches per_thread_global > // - Thread1 ends > // - Thread2 starts (and there is no happens-before relation between > it and Thread1) > // - Thread2 touches per_thread_global > // It may happen so that Thread2 will have per_thread_global in the same address > // as Thread1. Since there is no happens-before relation between threads, > // ThreadSanitizer reports a race. > The runable code is in > http://code.google.com/p/data-race-test/source/browse/trunk/unittest/racecheck_unittest.cc?spec=svn939&r=939#6017 > > As I understand, the valgrind core handles stack allocation and > deallocation itself. > All that tool needs to do is to call VG_(track_new_mem_stack) and similar. > Is there anything like this for TLS? No; it's never come up before... Nick |
|
From: Konstantin S. <kon...@gm...> - 2009-03-30 13:17:36
|
Hi valgrind developers, Does valgrind core do something special about TLS (thread-local storage)? I've recently discovered a false positive in ThreadSanitizer which is caused by TLS. Helgrind also emits a race report on the same test case. Test: // - Thread1 starts // - Thread1 touches per_thread_global // - Thread1 ends // - Thread2 starts (and there is no happens-before relation between it and Thread1) // - Thread2 touches per_thread_global // It may happen so that Thread2 will have per_thread_global in the same address // as Thread1. Since there is no happens-before relation between threads, // ThreadSanitizer reports a race. The runable code is in http://code.google.com/p/data-race-test/source/browse/trunk/unittest/racecheck_unittest.cc?spec=svn939&r=939#6017 As I understand, the valgrind core handles stack allocation and deallocation itself. All that tool needs to do is to call VG_(track_new_mem_stack) and similar. Is there anything like this for TLS? Thanks, --kcc |
|
From: <sv...@va...> - 2009-03-30 13:07:01
|
Author: sewardj
Date: 2009-03-30 14:06:48 +0100 (Mon, 30 Mar 2009)
New Revision: 9499
Log:
Merge from trunk, r9497 and r9498 (handle references to new
pseudo-register IP_AT_SYSCALL on VGA_x86 and VGA_amd64).
Modified:
branches/DARWIN/exp-ptrcheck/h_main.c
branches/DARWIN/memcheck/mc_machine.c
Modified: branches/DARWIN/exp-ptrcheck/h_main.c
===================================================================
--- branches/DARWIN/exp-ptrcheck/h_main.c 2009-03-30 02:34:29 UTC (rev 9498)
+++ branches/DARWIN/exp-ptrcheck/h_main.c 2009-03-30 13:06:48 UTC (rev 9499)
@@ -1322,6 +1322,7 @@
if (o == GOF(ESI) && is4) goto exactly1;
if (o == GOF(EDI) && is4) goto exactly1;
if (o == GOF(EIP) && is4) goto none;
+ if (o == GOF(IP_AT_SYSCALL) && is4) goto none;
if (o == GOF(CC_OP) && is4) goto none;
if (o == GOF(CC_DEP1) && is4) goto none;
if (o == GOF(CC_DEP2) && is4) goto none;
@@ -1412,6 +1413,7 @@
if (o == GOF(R14) && is8) goto exactly1;
if (o == GOF(R15) && is8) goto exactly1;
if (o == GOF(RIP) && is8) goto exactly1;
+ if (o == GOF(IP_AT_SYSCALL) && is8) goto none;
if (o == GOF(CC_OP) && is8) goto none;
if (o == GOF(CC_DEP1) && is8) goto none;
if (o == GOF(CC_DEP2) && is8) goto none;
Modified: branches/DARWIN/memcheck/mc_machine.c
===================================================================
--- branches/DARWIN/memcheck/mc_machine.c 2009-03-30 02:34:29 UTC (rev 9498)
+++ branches/DARWIN/memcheck/mc_machine.c 2009-03-30 13:06:48 UTC (rev 9499)
@@ -181,7 +181,7 @@
if (o == GOF(CTR) && sz == 8) return o;
if (o == GOF(CIA) && sz == 8) return -1;
- if (o == GOF(IP_AT_SYSCALL) && sz == 8) return -1;
+ if (o == GOF(IP_AT_SYSCALL) && sz == 8) return -1; /* slot unused */
if (o == GOF(RESVN) && sz == 8) return -1;
if (o == GOF(FPROUND) && sz == 4) return -1;
if (o == GOF(EMWARN) && sz == 4) return -1;
@@ -340,7 +340,7 @@
if (o == GOF(CTR) && sz == 4) return o;
if (o == GOF(CIA) && sz == 4) return -1;
- if (o == GOF(IP_AT_SYSCALL) && sz == 4) return -1;
+ if (o == GOF(IP_AT_SYSCALL) && sz == 4) return -1; /* slot unused */
if (o == GOF(RESVN) && sz == 4) return -1;
if (o == GOF(FPROUND) && sz == 4) return -1;
if (o == GOF(VRSAVE) && sz == 4) return -1;
@@ -488,6 +488,7 @@
if (o == GOF(CC_NDEP) && sz == 8) return -1; /* slot used for %BH */
if (o == GOF(DFLAG) && sz == 8) return -1; /* slot used for %CH */
if (o == GOF(RIP) && sz == 8) return -1; /* slot unused */
+ if (o == GOF(IP_AT_SYSCALL) && sz == 8) return -1; /* slot unused */
if (o == GOF(IDFLAG) && sz == 8) return -1; /* slot used for %DH */
if (o == GOF(FS_ZERO) && sz == 8) return -1; /* slot unused */
if (o == GOF(GS_0x60) && sz == 8) return -1; /* slot unused */
@@ -600,6 +601,7 @@
if (o == GOF(CC_NDEP) && sz == 4) return -1; /* slot used for %BH */
if (o == GOF(DFLAG) && sz == 4) return -1; /* slot used for %CH */
if (o == GOF(EIP) && sz == 4) return -1; /* slot unused */
+ if (o == GOF(IP_AT_SYSCALL) && sz == 4) return -1; /* slot unused */
if (o == GOF(IDFLAG) && sz == 4) return -1; /* slot used for %DH */
if (o == GOF(ACFLAG) && sz == 4) return -1; /* slot unused */
if (o == GOF(TISTART) && sz == 4) return -1; /* slot unused */
|
|
From: Nicholas N. <n.n...@gm...> - 2009-03-30 12:55:51
|
On Mon, Mar 30, 2009 at 7:06 AM, Ehab Ababneh <eha...@gm...> wrote: > Ok..Thanks..yes, the tarball missing the files was the problem (or may be me > missing the instructions on the page explicitly saying to get the source > code from svn). Also, I think you have to do "make ; make install" rather than just "make install". FIxing this in the docs is on my todo list. Nick |
|
From: Ehab A. <eha...@gm...> - 2009-03-30 12:06:49
|
Ok..Thanks..yes, the tarball missing the files was the problem (or may be me missing the instructions on the page explicitly saying to get the source code from svn). Thanks Konstantin! On Mon, Mar 30, 2009 at 12:28 AM, Konstantin Serebryany < kon...@gm...> wrote: > On Mon, Mar 30, 2009 at 11:15 AM, Ehab Ababneh <eha...@gm...> > wrote: > > Hello All, > > > > I have been trying to create a new tool for Valgrind and I was stuck on > few > > of the instructions here: > > > > http://valgrind.org/docs/manual/writing-tools.html > > > > where is the autogen.sh script? where should I get it form? or is it > > outdated thing? > > You probably took the tar ball. You need to take the sources from svn. > > > > It says here: ¨It should automake, configure and compile without errors, > > putting copies of the tool in foobar/ and inst/lib/valgrind/.¨ > > > > well, it did automake, configure and compile without errors, > but > > it did not put anything in foobar/ or inst/lib/valgrind/...... > > did you do 'make install' ? > > > --kcc > > > > > I appreciate any help to resolve this. > > > > Thanks. > > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > > Valgrind-developers mailing list > > Val...@li... > > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > > > > > |
|
From: Bart V. A. <bar...@gm...> - 2009-03-30 08:20:52
|
Nightly build on georgia-tech-cellbuzz-native ( cellbuzz, ppc64, Fedora 7, native ) started at 2009-03-30 02:00:01 EDT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... done Regression test results follow == 407 tests, 36 stderr failures, 9 stdout failures, 0 post failures == exp-ptrcheck/tests/bad_percentify (stderr) exp-ptrcheck/tests/base (stderr) exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/fp (stderr) exp-ptrcheck/tests/globalerr (stderr) exp-ptrcheck/tests/hackedbz2 (stderr) exp-ptrcheck/tests/hp_bounds (stderr) exp-ptrcheck/tests/hp_dangle (stderr) exp-ptrcheck/tests/justify (stderr) exp-ptrcheck/tests/partial_bad (stderr) exp-ptrcheck/tests/partial_good (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) exp-ptrcheck/tests/realloc (stderr) exp-ptrcheck/tests/stackerr (stderr) exp-ptrcheck/tests/strcpy (stderr) exp-ptrcheck/tests/supp (stderr) exp-ptrcheck/tests/tricky (stderr) exp-ptrcheck/tests/unaligned (stderr) exp-ptrcheck/tests/zero (stderr) helgrind/tests/hg05_race2 (stderr) memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cases-full (stderr) memcheck/tests/leak-cases-summary (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/varinfo1 (stderr) memcheck/tests/varinfo2 (stderr) memcheck/tests/varinfo3 (stderr) memcheck/tests/varinfo4 (stderr) memcheck/tests/varinfo5 (stderr) memcheck/tests/varinfo6 (stderr) memcheck/tests/wrap8 (stderr) none/tests/linux/mremap (stderr) none/tests/linux/mremap2 (stdout) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-vmx (stdout) none/tests/ppc32/round (stdout) none/tests/ppc32/test_gx (stdout) none/tests/ppc64/jm-fp (stdout) none/tests/ppc64/jm-vmx (stdout) none/tests/ppc64/round (stdout) none/tests/shell_valid2 (stderr) none/tests/shell_valid3 (stderr) |
|
From: Konstantin S. <kon...@gm...> - 2009-03-30 07:28:39
|
On Mon, Mar 30, 2009 at 11:15 AM, Ehab Ababneh <eha...@gm...> wrote: > Hello All, > > I have been trying to create a new tool for Valgrind and I was stuck on few > of the instructions here: > > http://valgrind.org/docs/manual/writing-tools.html > > where is the autogen.sh script? where should I get it form? or is it > outdated thing? You probably took the tar ball. You need to take the sources from svn. > It says here: ¨It should automake, configure and compile without errors, > putting copies of the tool in foobar/ and inst/lib/valgrind/.¨ > > well, it did automake, configure and compile without errors, but > it did not put anything in foobar/ or inst/lib/valgrind/...... did you do 'make install' ? --kcc > > I appreciate any help to resolve this. > > Thanks. > > ------------------------------------------------------------------------------ > > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > > |
|
From: Ehab A. <eha...@gm...> - 2009-03-30 07:15:12
|
Hello All, I have been trying to create a new tool for Valgrind and I was stuck on few of the instructions here: http://valgrind.org/docs/manual/writing-tools.html 1. where is the autogen.sh script? where should I get it form? or is it outdated thing? 2. It says here: ¨It should automake, configure and compile without errors, putting copies of the tool in foobar/ and inst/lib/valgrind/.¨ well, it did automake, configure and compile without errors, but it did not put anything in foobar/ or inst/lib/valgrind/...... I appreciate any help to resolve this. Thanks. |
|
From: Tom H. <th...@cy...> - 2009-03-30 03:17:25
|
Nightly build on vauxhall ( x86_64, Fedora 10 ) started at 2009-03-30 03:20:05 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... done Regression test results follow == 487 tests, 0 stderr failures, 0 stdout failures, 0 post failures == |
|
From: Tom H. <th...@cy...> - 2009-03-30 03:11:36
|
Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2009-03-30 03:05:05 BST 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 == 478 tests, 4 stderr failures, 0 stdout failures, 0 post failures == exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) |
|
From: Tom H. <th...@cy...> - 2009-03-30 02:47:19
|
Nightly build on mg ( x86_64, Fedora 9 ) started at 2009-03-30 03:10:06 BST 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 == 484 tests, 4 stderr failures, 1 stdout failure, 0 post failures == exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) none/tests/linux/mremap2 (stdout) |
|
From: <sv...@va...> - 2009-03-30 02:35:09
|
Author: sewardj
Date: 2009-03-30 03:34:29 +0100 (Mon, 30 Mar 2009)
New Revision: 9498
Log:
Handle accesses to new pseudo-register IP_AT_SYSCALL. Related to, but
not actually the cause or fix for, #188161.
Modified:
trunk/exp-ptrcheck/h_main.c
Modified: trunk/exp-ptrcheck/h_main.c
===================================================================
--- trunk/exp-ptrcheck/h_main.c 2009-03-30 02:27:29 UTC (rev 9497)
+++ trunk/exp-ptrcheck/h_main.c 2009-03-30 02:34:29 UTC (rev 9498)
@@ -1322,6 +1322,7 @@
if (o == GOF(ESI) && is4) goto exactly1;
if (o == GOF(EDI) && is4) goto exactly1;
if (o == GOF(EIP) && is4) goto none;
+ if (o == GOF(IP_AT_SYSCALL) && is4) goto none;
if (o == GOF(CC_OP) && is4) goto none;
if (o == GOF(CC_DEP1) && is4) goto none;
if (o == GOF(CC_DEP2) && is4) goto none;
@@ -1412,6 +1413,7 @@
if (o == GOF(R14) && is8) goto exactly1;
if (o == GOF(R15) && is8) goto exactly1;
if (o == GOF(RIP) && is8) goto exactly1;
+ if (o == GOF(IP_AT_SYSCALL) && is8) goto none;
if (o == GOF(CC_OP) && is8) goto none;
if (o == GOF(CC_DEP1) && is8) goto none;
if (o == GOF(CC_DEP2) && is8) goto none;
|
|
From: <sv...@va...> - 2009-03-30 02:28:03
|
Author: sewardj
Date: 2009-03-30 03:27:29 +0100 (Mon, 30 Mar 2009)
New Revision: 9497
Log:
Handle new pseudo-register IP_AT_SYSCALL when origin-tracking is
enabled. Fixes #188161.
Modified:
trunk/memcheck/mc_machine.c
Modified: trunk/memcheck/mc_machine.c
===================================================================
--- trunk/memcheck/mc_machine.c 2009-03-26 19:07:15 UTC (rev 9496)
+++ trunk/memcheck/mc_machine.c 2009-03-30 02:27:29 UTC (rev 9497)
@@ -181,7 +181,7 @@
if (o == GOF(CTR) && sz == 8) return o;
if (o == GOF(CIA) && sz == 8) return -1;
- if (o == GOF(IP_AT_SYSCALL) && sz == 8) return -1;
+ if (o == GOF(IP_AT_SYSCALL) && sz == 8) return -1; /* slot unused */
if (o == GOF(RESVN) && sz == 8) return -1;
if (o == GOF(FPROUND) && sz == 4) return -1;
if (o == GOF(EMWARN) && sz == 4) return -1;
@@ -340,7 +340,7 @@
if (o == GOF(CTR) && sz == 4) return o;
if (o == GOF(CIA) && sz == 4) return -1;
- if (o == GOF(IP_AT_SYSCALL) && sz == 4) return -1;
+ if (o == GOF(IP_AT_SYSCALL) && sz == 4) return -1; /* slot unused */
if (o == GOF(RESVN) && sz == 4) return -1;
if (o == GOF(FPROUND) && sz == 4) return -1;
if (o == GOF(VRSAVE) && sz == 4) return -1;
@@ -488,6 +488,7 @@
if (o == GOF(CC_NDEP) && sz == 8) return -1; /* slot used for %BH */
if (o == GOF(DFLAG) && sz == 8) return -1; /* slot used for %CH */
if (o == GOF(RIP) && sz == 8) return -1; /* slot unused */
+ if (o == GOF(IP_AT_SYSCALL) && sz == 8) return -1; /* slot unused */
if (o == GOF(IDFLAG) && sz == 8) return -1; /* slot used for %DH */
if (o == GOF(FS_ZERO) && sz == 8) return -1; /* slot unused */
if (o == GOF(TISTART) && sz == 8) return -1; /* slot unused */
@@ -598,6 +599,7 @@
if (o == GOF(CC_NDEP) && sz == 4) return -1; /* slot used for %BH */
if (o == GOF(DFLAG) && sz == 4) return -1; /* slot used for %CH */
if (o == GOF(EIP) && sz == 4) return -1; /* slot unused */
+ if (o == GOF(IP_AT_SYSCALL) && sz == 4) return -1; /* slot unused */
if (o == GOF(IDFLAG) && sz == 4) return -1; /* slot used for %DH */
if (o == GOF(ACFLAG) && sz == 4) return -1; /* slot unused */
if (o == GOF(TISTART) && sz == 4) return -1; /* slot unused */
|