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
|
2
|
3
|
4
|
|
5
(3) |
6
(7) |
7
(6) |
8
(10) |
9
(6) |
10
(3) |
11
(1) |
|
12
|
13
|
14
(2) |
15
(6) |
16
(16) |
17
(8) |
18
(1) |
|
19
|
20
|
21
(1) |
22
|
23
|
24
|
25
|
|
26
|
27
(1) |
28
(2) |
29
|
30
(1) |
31
(1) |
|
|
From: Thomas R. <tr...@st...> - 2010-12-14 09:40:50
|
Hi all
[domjudge cc'd in the hope that you're interested in such
developments]
First of all thanks for a great tool. In some years of using
valgrind, I only found a small bug in it, whereas it found lots of
bugs in my own code ;-)
Some back story (skip it if you're in a hurry):
I am part of a team of assistants giving a course called "Algorithms
Lab" at ETH. It works vaguely similar to the ACM contests: the
students solve a programming problem and hand it in at a "judge"[1].
The judge (actually a little cluster of 3*4 cores) automatically
compiles and executes the problem on a set of predefined (secret)
test cases, validates the output and saves the result in a database.
The students can then, with only slight delay, see the result.
The problem is that, to enforce use of efficient algorithms and also
to protect the judge against DoS, we impose hard time limits. As I
am sure you are well aware, times() and friends are not a very
precise way of measuring time, thus the same program may hit the
timelimit only some of the time. CPU stepping has made it really
hard to do any timings; programs run slower on the cluster when it
runs hot than when it only tests a single program. Finally, all of
this would of course completely break down on the day we add some
new hardware.
So at some point this year I figured, maybe valgrind could help with
this, after all it already does instruction counts. And it seems to
work pretty well[2]:
git://honeybunny.inf.ethz.ch/valgrind master
I started from nulgrind and added pieces of memcheck and other tools
until happy. It now outputs a score of 1 per every 1e7 IR register
accesses (Put[I]/Get[I]), which puts it in the same order of magnitude
as running the same programs unsupervised on my laptop. The huge
benefit of course is that this score is deterministic and the same
across hardware (if not compilers/platforms). The downside of course
is that I get a slowdown factor of about 8, but then again even
best-of-5 timings would incur a slowdown of 5 and still not give
deterministic results.
The slight downside is that in this setting valgrind is (abused as) a
security-relevant piece of software. I tried to plug all holes that I
could think of:
* Syscall whitelisting is done within valgrind, notably preventing the
client from escaping valgrind through execve(), and from closing or
duping over the FD used for valgrind messages
* Client requests are banned (immediate exit when seeing them in the IR)
* Memory is tracked far enough to be sure that the client cannot write
to valgrind's memory
As soon as you can stop screaming "valgrind -- security -- CRAZY", I
would of course be interested to hear if there are any other known
holes. I still plan on keeping the "other" syscall whitelist, to have
double security against leaking the testcases through socket() etc,
but any issue with valgrind would at least allow the student to
circumvent the time limits, which is bad enough.
Barring any major issues, I am hoping to roll this out by next
September in time for the next instalment of the course.
Regards,
Thomas
[1] It runs a fork of DOMjudge.
[2] Posting git links seems the norm here? But I haven't found an
up-to-date "authoritative" git-svn clone, so I took
git://gitorious.org/valgrind/mainlinemirror.git
and then fetched the rest myself. I can also post patches if you
like.
--
Thomas Rast
trast@{inf,student}.ethz.ch
|
|
From: Maynard J. <may...@us...> - 2010-12-14 00:42:57
|
Julian Seward wrote: > > How do you know the generated code is incorrect? Do you have more > info on this? I've attached two files showing the assembly code for machine_get_hwcaps for the good case (valgrind built with gcc 4.1.2) and the bad case (valgrind built with gcc 4.5.2). I ran this code on a POWER5, so it should fail the VMX check (using 'vor' instruction), where the __builtin_setjmp is at line 789 of coregrind/m_machine.c. You'll notice that in the good case, code is generated to branch to line 790 on failure or to line 797 on success. The generated code in the bad case does nothing like it's supposed to. > > Does the problem happen for ppc32, or does it only appear in > 64-bit mode? Both modes. -Maynard > > J > > On Friday, December 10, 2010, Maynard Johnson wrote: >> I've found that Valgrind may segfault in >> coregrind/m_machine.c:VG_(machine_get_hwcaps) under certain conditions: - >> Running on a processor where one of the capability checks will fail (e.g., >> IBM POWER5, checking for Altivec) - Valgrind was built with gcc 4.4.4 or >> later >> >> The generated code is apparently incorrect, but we got no joy when our >> resident gcc person reported this to other gcc community folk. We were >> told that these functions are for internal gcc use only -- and also that >> doing a longjmp out of a signal handler is "undefined" by the POSIX >> standard. So far, I've only seen problems occur in cases where the >> longjmp is performed out of a signal handler. >> >> I was able to come up with a patch to eliminate the use of these functions >> where it was causing problems on my older POWER systems, and I will open a >> bugzilla and attach that patch. But there are some other places where >> these functions are used (listed below). Someone familiar with ARM should >> probably take a look at the issue for that architecture, since those cases >> also use signal handlers like the problematic ppc64 cases I am fixing. >> But there are some architecture-independent uses that need to be >> investigated, as well. My sense is that the cases that do NOT involve >> signal handlers are OK for now -- based on my testing using gcc 4.4.4. >> >> Examples of __builtin_set[long]jmp with signal handlers >> ---------------------------------------------------- >> - coregrind/m_machine.c: ppc64 and arm >> - exp-ptrcheck/tests (several users of '#define TTT' which makes use of >> __builtin_setjmp) >> - memcheck/tests (badjmup2.c) >> - memcheck/mc_leakcheck.c >> >> Examples of __builtin_set[long]jmp without signal handlers >> ---------------------------------------------------- >> - coregrind/m_debuginfo/readdwarf.c >> - coregrind/m_scheduler/scheduler.c >> >> Regards, >> -Maynard >> >> >> --------------------------------------------------------------------------- >> --- Oracle to DB2 Conversion Guide: Learn learn about native support for >> PL/SQL, new data types, scalar functions, improved concurrency, built-in >> packages, OCI, SQL*Plus, data movement tools, best practices and more. >> http://p.sf.net/sfu/oracle-sfdev2dev >> _______________________________________________ >> Valgrind-developers mailing list >> Val...@li... >> https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |