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
(12) |
2
(5) |
3
(12) |
4
(9) |
5
(4) |
6
(7) |
|
7
(6) |
8
(10) |
9
(5) |
10
(5) |
11
(4) |
12
(7) |
13
(19) |
|
14
(11) |
15
(9) |
16
(6) |
17
(21) |
18
(13) |
19
(12) |
20
(9) |
|
21
(22) |
22
(24) |
23
(21) |
24
(12) |
25
(6) |
26
(3) |
27
(4) |
|
28
(3) |
29
(5) |
30
(11) |
31
(7) |
|
|
|
|
From: Bart V. A. <bar...@gm...> - 2008-12-31 12:36:51
|
On Wed, Dec 31, 2008 at 12:11 PM, Felix Schmidt <fel...@we...> wrote:
> this is the code fragment:
>
> 73 VG_(thread_stack_next)(&thread, &s_min, &s_max);
> 74 if(addr >= s_min && addr <= s_max)
> 75 {
> 76 // stack
> 79 } else {
> 80 // heap or bss
> 81 }
>
> I try to get stack boundaries. Then I want to decide if the given
> address a stack address or a heap rather bss address.
> I think the +1 falsify the result. Wrong stack boundaries are supposed.
> (may be the stack boundaries of current thread +1)
VG_(thread_stack_next)() is typically used to iterate over all
threads. Without the "+1" inside VG_(thread_stack_next)() this
function would not iterate over threads but would always return
information for the same thread. If you only need the stack
information for a single thread, there are two options:
* Decrement 'thread' before calling VG_(thread_stack_next)().
* Use VG_(thread_get_stack_max)(...) and
VG_(thread_get_stack_size)(...) instead of VG_(thread_stack_next)().
Bart.
|
|
From: Felix S. <fel...@we...> - 2008-12-31 11:12:13
|
this is the code fragment:
73 VG_(thread_stack_next)(&thread, &s_min, &s_max);
74 if(addr >= s_min && addr <= s_max)
75 {
76 // stack
79 } else {
80 // heap or bss
81 }
I try to get stack boundaries. Then I want to decide if the given
address a stack address or a heap rather bss address.
I think the +1 falsify the result. Wrong stack boundaries are supposed.
(may be the stack boundaries of current thread +1)
i wish you all a happy new year!
fs
Bart Van Assche schrieb:
> On Tue, Dec 30, 2008 at 2:54 PM, Felix Schmidt <fel...@we...> wrote:
>
>> maybe I found an error in m_machine.c.
>> In line 248: for (i = (*tid)+1; ....
>> Why stands there a +1? I think this is a bug
>>
>
> If you are looking at this code, this is probably because you are
> using VG_(thread_stack_reset_iter)() and VG_(thread_stack_next)() ? It
> would help if you could post the code that calls these functions.
>
> Bart.
>
>
|
|
From: <sv...@va...> - 2008-12-31 09:55:51
|
Author: bart Date: 2008-12-31 09:55:44 +0000 (Wed, 31 Dec 2008) New Revision: 8887 Log: Updated to do list. Modified: trunk/drd/TODO.txt Modified: trunk/drd/TODO.txt =================================================================== --- trunk/drd/TODO.txt 2008-12-29 14:46:26 UTC (rev 8886) +++ trunk/drd/TODO.txt 2008-12-31 09:55:44 UTC (rev 8887) @@ -15,7 +15,11 @@ - Find out why no variable name information is printed for races detected in parallel sections of OpenMP programs. An example: ./vg-in-place --tool=exp-drd exp-drd/tests/omp_prime 4 -t 2 -- Report races in glibc on stdout / stderr back to glibc maintainers. +- Improve the code for suppressing races reported on glibc FILE objects, e.g. by intercepting + all operations on FILE objects and by associating mutex semantics with FILE objects. Verify + that races on unsynchronized *_unlocked() operations are reported. Remove FILE-I/O suppression + patterns from glibc-2.X-drd.supp. See also http://www.unix.org/whitepapers/reentrant.html. +- Find out why drd/tests/pth_inconsistent_cond_wait sometimes fails on Fedora Core 6. Testing |
|
From: Julian S. <js...@ac...> - 2008-12-31 09:17:44
|
> What would help greatly is a more flexible way of specifying the acceptable > (expected) tracebacks. Something exactly like the current suppression > syntax, allowing frame-level wildcards and > function/object-name-level-wildcards would be ideal. So I guess that would > mean writing a custom C program to do the check, rather than just using > diff. Possible it would be useful to have a format for the expected output files that has more structure than at present: * sections that must match literally, and * sections which are stack traces, and therefore are written using the .supp wildcard syntax in 3.4.0 J |
|
From: Tom H. <th...@cy...> - 2008-12-31 03:48:04
|
Nightly build on vauxhall ( x86_64, Fedora 10 ) started at 2008-12-31 03:20:05 GMT 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 == 481 tests, 13 stderr failures, 1 stdout failure, 0 post failures == cachegrind/tests/chdir (stderr) cachegrind/tests/clreq (stderr) cachegrind/tests/dlclose (stderr) cachegrind/tests/wrap5 (stderr) cachegrind/tests/x86/fpu-28-108 (stderr) callgrind/tests/simwork1 (stderr) callgrind/tests/simwork2 (stderr) callgrind/tests/simwork3 (stderr) drd/tests/pth_detached_sem (stdout) exp-ptrcheck/tests/base (stderr) exp-ptrcheck/tests/preen_invars (stderr) memcheck/tests/linux-syscalls-2007 (stderr) memcheck/tests/x86/scalar (stderr) none/tests/blockfault (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 == 481 tests, 13 stderr failures, 0 stdout failures, 0 post failures == cachegrind/tests/chdir (stderr) cachegrind/tests/clreq (stderr) cachegrind/tests/dlclose (stderr) cachegrind/tests/wrap5 (stderr) cachegrind/tests/x86/fpu-28-108 (stderr) callgrind/tests/simwork1 (stderr) callgrind/tests/simwork2 (stderr) callgrind/tests/simwork3 (stderr) exp-ptrcheck/tests/base (stderr) exp-ptrcheck/tests/preen_invars (stderr) memcheck/tests/linux-syscalls-2007 (stderr) memcheck/tests/x86/scalar (stderr) none/tests/blockfault (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Wed Dec 31 03:34:13 2008 --- new.short Wed Dec 31 03:47:52 2008 *************** *** 8,10 **** ! == 481 tests, 13 stderr failures, 0 stdout failures, 0 post failures == cachegrind/tests/chdir (stderr) --- 8,10 ---- ! == 481 tests, 13 stderr failures, 1 stdout failure, 0 post failures == cachegrind/tests/chdir (stderr) *************** *** 17,18 **** --- 17,19 ---- callgrind/tests/simwork3 (stderr) + drd/tests/pth_detached_sem (stdout) exp-ptrcheck/tests/base (stderr) |
|
From: Tom H. <th...@cy...> - 2008-12-31 03:47:41
|
Nightly build on trojan ( x86_64, Fedora Core 6 ) started at 2008-12-31 03:25:03 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 == 476 tests, 8 stderr failures, 4 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) helgrind/tests/tc20_verifywrap (stderr) memcheck/tests/x86/bug133694 (stdout) memcheck/tests/x86/bug133694 (stderr) memcheck/tests/x86/scalar (stderr) none/tests/blockfault (stderr) none/tests/cmdline1 (stdout) none/tests/cmdline2 (stdout) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2008-12-31 03:36:57
|
Nightly build on mg ( x86_64, Fedora 9 ) started at 2008-12-31 03:10:05 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 == 478 tests, 14 stderr failures, 1 stdout failure, 0 post failures == cachegrind/tests/chdir (stderr) cachegrind/tests/clreq (stderr) cachegrind/tests/dlclose (stderr) cachegrind/tests/wrap5 (stderr) cachegrind/tests/x86/fpu-28-108 (stderr) callgrind/tests/simwork1 (stderr) callgrind/tests/simwork2 (stderr) callgrind/tests/simwork3 (stderr) exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) memcheck/tests/x86/scalar (stderr) none/tests/blockfault (stderr) none/tests/mremap2 (stdout) |