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
(23) |
2
(15) |
|
3
|
4
|
5
|
6
|
7
(3) |
8
(22) |
9
(12) |
|
10
|
11
|
12
(1) |
13
(13) |
14
(4) |
15
(12) |
16
|
|
17
(5) |
18
(13) |
19
(6) |
20
(10) |
21
(17) |
22
|
23
(3) |
|
24
(18) |
25
(17) |
26
(12) |
27
|
28
(1) |
29
(3) |
30
(12) |
|
From: Philippe W. <phi...@sk...> - 2013-11-19 20:21:29
|
On Tue, 2013-11-19 at 09:08 -0800, Patrick J. LoPresti wrote: > When partial-loads-ok is working correctly, I believe all of > Valgrind's str/mem intercepts are technically unnecessary. True, they > are faster... But that is an argument for intercepting every function > in the C library :-). Not too sure I understand. The str/mem interceptions will usually run slower than the C lib functions (as in most cases, these interceptions run fully on the simulated cpu and are not as optimised as the c lib functions). > > In my opinion, "--partial-loads-ok=yes" should be the default. It > would make 90% of the intercepts and default suppression rules > unnecessary. OK that is just a guess... But this is certainly a > pervasive source of Valgrind false positives. You could try to run all the regression tests giving --partial-load-ok=yes and use -v to look at the used suppressions and see which one are not used anymore. Philippe |
|
From: Philippe W. <phi...@sk...> - 2013-11-19 20:17:06
|
On Tue, 2013-11-19 at 09:06 +0100, Bart Van Assche wrote: > On 11/18/13 23:43, Philippe Waroquiers wrote: > > On Sun, 2013-11-17 at 14:05 +0100, Bart Van Assche wrote: > > > I think for all the functions intercepted by vg_replace_strmem.c there > is a risk that the non-intercepted optimized versions in glibc read past > the end of the input range(s). That means that not intercepting these > functions creates a risk that subtle and hard to analyze false positive > data races will be reported. I think the choice we have is a choice > between a tool that runs fast or a tool that works correctly :-) Effectively, correctness is the main criteria. However, if replacing a function which currently does not cause a false positive has a big impact on performance, then we better do not replace it until a false positive is detected. Philippe |
|
From: Bart V. A. <bva...@ac...> - 2013-11-19 17:55:19
|
On 11/19/13 18:08, Patrick J. LoPresti wrote: > On Tue, Nov 19, 2013 at 12:06 AM, Bart Van Assche <bva...@ac...> wrote: >> >> I think for all the functions intercepted by vg_replace_strmem.c there >> is a risk that the non-intercepted optimized versions in glibc read past >> the end of the input range(s). That means that not intercepting these >> functions creates a risk that subtle and hard to analyze false positive >> data races will be reported. I think the choice we have is a choice >> between a tool that runs fast or a tool that works correctly :-) > > Note that "--partial-loads-ok=yes" fixes these false positives. A fair > amount of work went in to Valgrind 3.9.0 to make it work for > vectorized memory and string operations on x86 and x86_64: > > https://bugs.kde.org/show_bug.cgi?id=294285 > https://bugs.kde.org/show_bug.cgi?id=294523 > https://bugs.kde.org/show_bug.cgi?id=308627 > https://bugs.kde.org/show_bug.cgi?id=309921 > > (I needed this to handle the output of the Intel compiler, which has a > habit of inlining mem*() and str*() functions extensively.) > > When partial-loads-ok is working correctly, I believe all of > Valgrind's str/mem intercepts are technically unnecessary. True, they > are faster... But that is an argument for intercepting every function > in the C library :-). > > In my opinion, "--partial-loads-ok=yes" should be the default. It > would make 90% of the intercepts and default suppression rules > unnecessary. OK that is just a guess... But this is certainly a > pervasive source of Valgrind false positives. >From what I see in the Valgrind source code the --partial-loads-ok option is supported by memcheck and exp-sgcheck but not by Helgrind nor by DRD. And as you write for memcheck the intercepts work faster than --partial-loads-ok=yes. So I think the patch at the start of this thread is really needed for Helgrind and DRD. Bart. |
|
From: Patrick J. L. <pa...@pa...> - 2013-11-19 17:08:44
|
On Tue, Nov 19, 2013 at 12:06 AM, Bart Van Assche <bva...@ac...> wrote: > > I think for all the functions intercepted by vg_replace_strmem.c there > is a risk that the non-intercepted optimized versions in glibc read past > the end of the input range(s). That means that not intercepting these > functions creates a risk that subtle and hard to analyze false positive > data races will be reported. I think the choice we have is a choice > between a tool that runs fast or a tool that works correctly :-) Note that "--partial-loads-ok=yes" fixes these false positives. A fair amount of work went in to Valgrind 3.9.0 to make it work for vectorized memory and string operations on x86 and x86_64: https://bugs.kde.org/show_bug.cgi?id=294285 https://bugs.kde.org/show_bug.cgi?id=294523 https://bugs.kde.org/show_bug.cgi?id=308627 https://bugs.kde.org/show_bug.cgi?id=309921 (I needed this to handle the output of the Intel compiler, which has a habit of inlining mem*() and str*() functions extensively.) When partial-loads-ok is working correctly, I believe all of Valgrind's str/mem intercepts are technically unnecessary. True, they are faster... But that is an argument for intercepting every function in the C library :-). In my opinion, "--partial-loads-ok=yes" should be the default. It would make 90% of the intercepts and default suppression rules unnecessary. OK that is just a guess... But this is certainly a pervasive source of Valgrind false positives. - Pat |
|
From: Mark W. <mj...@re...> - 2013-11-19 09:31:15
|
Hi Valgrind Hackers and Users,
We are still looking for some more people wanting to present a talk or
just informally discuss some technical issues at the valgrind developer
room at FOSDEM, Sunday 2 Feb 2014 in Brussels, Belgium.
It would be helpful if proposals were submitted before:
SUNDAY 8 DECEMBER (<- PROPOSAL DEADLINE!)
That way we can create a schedule beforehand.
See below for some suggestions and details on how to submit a proposal.
But please do feel free to suggest anything you feel is interesting
around valgrind and just email us with a proposal or idea instead of
doing things through the penta system if that is easier or you just want
some feedback on an idea first.
We are also still looking for volunteers to create video recordings in
the developer room. Again, details below.
The important dates:
Video Volunteers: Before 30 Nov 2013
Talk/Discussion Submission deadline: Sunday 8 Dec 2013
Devroom Schedule announcement: Sunday 15 Dec 2013
Devroom day: Sunday 2 Feb 2014
Valgrind developer room at FOSDEM 2014 (Brussels, Belgium, 2 February).
FOSDEM is a free software event that offers open source communities a
place to meet, share ideas and collaborate. It is renowned for being
highly developer-oriented and brings together 5000+ hackers from all
over the world. Taking place in the city of Brussels (Belgium).
http://fosdem.org/
FOSDEM 2014 will take place during the weekend of Saturday, February 1st
and Sunday, February 2nd. On Sunday we will have a devroom for Valgrind.
Devrooms are a place for development teams to meet, discuss, hack and
publicly present the project latest improvements and future directions.
We will have a whole day to hang out together as Valgrind community.
Please join us whether you are a Valgrind core hacker, Valgrind tool
hacker, Valgrind user, Valgrind packager or hacker on a project that
integrates, extends or complements Valgrind.
Call For Participation
We would like to organize a series of talks/discussions on various
topics relevant to both core hackers, new developers, users, packagers
and cross project functionality. Please do submit a talk proposal before
Sunday December 8th 2013, so we can make a list of activities during the
day.
Some possible topics for talks/discussions are:
- The recently added functional changes (for valgrind users).
- State of the valgrind code base (core hackers).
- Helgrind - basic design, problems and opportunities (core and tools).
- Get feedback on what what kinds of new functionality would
be useful. Which tools users would like to see and/or which new
features for the existing tools. (valgrind developers and users).
- Modify memcheck to report the last leaked pointer to a block
integrate "omega" as a memcheck option or omega as a separate tool.
- Better support compiled and JITted code.
allowing the JIT compiler to indicate the link between
the JITted code and the source code.
- Valgrind and transactional memory.
- How to add simple features (adding syscalls for a platform or VEX
instructions for a architecture port). (new core developers).
- Making Valgrind really multi-threaded, parallelising Memcheck
parallelising the rest of the framework, and tools (for core hackers).
- Should we continue to support MacOS? What about Valgrind on
MS-Windows? Solaris? (attracting new hackers).
- Redo the JIT framework to reduce baseline overheads? (core hackers).
- Make Callgrind work sanely on ARM (core hackers).
- Discuss release/bugfixing strategy/policy (core hackers, packagers).
- Packaging valgrind for distros, handling patches, suppressions, etc.
(packagers).
- Valgrind/GDB integration (cross project).
- Valgrind vs the compiler. Compilers like GCC and clang now have
"valgrind like" features -fsanitize=address|thread|undefined.
How does valgrind complement or improve on these features?
- Eclipse and other visualisation tools for valgrind (cross project).
- Practical examples of using Valgrind in (big) systems automatic
regression testing (users).
Use the FOSDEM 'pentabarf' tool to submit your proposal.
https://penta.fosdem.org/submission/FOSDEM14/
- If necessary, create a Pentabarf account and activate it.
- In the "Person" section, provide First name, Last name
(in the "General" tab), Email (in the "Contact" tab)
and Bio ("Abstract" field in the "Description" tab).
- Submit a proposal by clicking on "Create event".
- Important! Select the "Valgrind devroom" track
(on the "General" tab).
- Provide the title of your talk ("Event title" in the "General" tab).
- Provide a description of the subject of the talk and the
intended audience (in the "Abstract" field of the "Description" tab)
- Provide a rough outline of the talk or goals of the session (a short
list of bullet points covering topics that will be discussed) in the
"Full description" field in the "Description" tab
Julian, Philippe and Mark will review the proposals and organize the
schedule for the day. Please feel free to suggest or discuss any ideas
for the devroom on the Valgrind developer mailinglist before creating a
proposal: val...@li...
Call For (Video) Volunteers
The FOSDEM organization can provide us with equipment to record some or
all of the talks in our devroom. But we need at least two volunteers to
do the actual recordings. An ideal candidate for this job would be
someone who is going to be watching talks in the Valgrind devroom most
(or all) of the time anyway, and who doesn't mind watching after a
camera and/or an audio mixer while watching the talk.
While some A/V experience is obviously useful for the volunteer, it is
absolutely not required; FOSDEM will provide the right gear and help set
it up, and FOSDEM organizers will also provide enough information so the
volunteers know what to do. This will include a live training session
during the opening talk (in Janson) for those who want it.
If you want to help record talks/discussions in the Valgrind devroom
please let us know before the end of November.
Important dates:
Video Volunteers: Before 30 Nov 2013
Talk/Discussion Submission deadline: Sunday 8 Dec 2013
Devroom Schedule announcement: Sunday 15 Dec 2013
Devroom day: Sunday 2 Feb 2014
Hope to see you all at FOSDEM 2014 in the Valgrind devroom.
Brussels (Belgium), Sunday 2 February, 2014.
https://fosdem.org/2014/schedule/track/valgrind/
|
|
From: Bart V. A. <bva...@ac...> - 2013-11-19 08:06:28
|
On 11/18/13 23:43, Philippe Waroquiers wrote: > On Sun, 2013-11-17 at 14:05 +0100, Bart Van Assche wrote: >> There is quite some duplicate code in mc_replace_strmem.c, hg_intercepts.c >> and drd_strmem_intercepts.c, hence this patch that merges these files. This >> patch moves memcheck/mc_replace_strmem.c to shared/vg_replace_strmem.c and >> adds several intercepts for SSE-variants. Include that source file from >> drd/drd_strmem_intercepts.c, helgrind/hg_intercepts.c and >> memcheck/mc_replace_strmem.c. The test filters that depend on the file >> name of the file with the intercept code are updated. > This patch looks a really good idea to me. > > Minor comments and a question below ... > >> diff --git a/shared/vg_replace_strmem.c b/shared/vg_replace_strmem.c >> new file mode 100644 >> index 0000000..110543c >> --- /dev/null >> +++ b/shared/vg_replace_strmem.c >> @@ -0,0 +1,1836 @@ >> + >> +/*--------------------------------------------------------------------*/ >> +/*--- Replacements for strcpy(), memcpy() et al, which run on the ---*/ >> +/*--- simulated CPU. ---*/ >> +/*--- mc_replace_strmem.c ---*/ > vg_replace_strmem.c > >> + >> +/* >> + This file is part of MemCheck, a heavyweight Valgrind tool for > part of Valgrind, used e.g. by memcheck/helgrind/drd ? > > >> +/* Assignment of behavioural equivalence class tags: 2NNNP is intended >> + to be reserved for Memcheck. Current usage: > ^^^^^^^^^^^^^^^^^^^^^ is that still the case ? > or is it now also used for helgrind and drd ? Thanks for the feedback, I will update that comment. > Finally, one question: > Currently, helgrind replaces a small nr of functions. With this patch, > a bigger nr of functions will be replaced. > Can there be a (significant) performance impact of these additional > (maybe not mandatory?) replacements ? I think for all the functions intercepted by vg_replace_strmem.c there is a risk that the non-intercepted optimized versions in glibc read past the end of the input range(s). That means that not intercepting these functions creates a risk that subtle and hard to analyze false positive data races will be reported. I think the choice we have is a choice between a tool that runs fast or a tool that works correctly :-) Bart. |