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
(6) |
|
2
(4) |
3
(9) |
4
(11) |
5
(16) |
6
(6) |
7
(1) |
8
(11) |
|
9
(11) |
10
(6) |
11
(10) |
12
(23) |
13
(23) |
14
(6) |
15
(10) |
|
16
(5) |
17
(13) |
18
(9) |
19
(4) |
20
(6) |
21
(16) |
22
(3) |
|
23
(5) |
24
(7) |
25
(6) |
26
(4) |
27
(8) |
28
|
29
(3) |
|
30
(2) |
31
(17) |
|
|
|
|
|
|
From: Mark W. <mj...@re...> - 2015-08-24 20:19:10
|
I hoped to fix the SIGABRT issue with tc18 and tc20 for sem_post in a similar way. See attached. It does "fix" the tc18 case, but not the tc20 case. Since hellgrind doesn't actually see the failure now it doesn't report anything. Which works for tc18 since there is an alternate exp file with that result (silent bad sem_post), but tc20 doesn't have an alternative where there is no EINVAL so it still reports an error. But at least not an abort, but a missing EINVAL. I do think glibc not detecting a bad semaphore might be allowed, so maybe we could just add an alternative tc20.exp that just doesn't see the EINVAL. Or would that be too much "cheating"? Cheers, Mark |
|
From: Matthias S. <zz...@ge...> - 2015-08-24 19:39:45
|
Hi! Will this patch or at least this idea be considered for commiting? This makes diagnosis of valgrind/client app abnormal exits a lot simpler. Especially in automated valgrind execution. Regards Matthias |
|
From: <sv...@va...> - 2015-08-24 19:27:03
|
Author: tom
Date: Mon Aug 24 20:26:56 2015
New Revision: 15588
Log:
Use sigjmp_buf
Modified:
trunk/helgrind/tests/safe-pthread.h
Modified: trunk/helgrind/tests/safe-pthread.h
==============================================================================
--- trunk/helgrind/tests/safe-pthread.h (original)
+++ trunk/helgrind/tests/safe-pthread.h Mon Aug 24 20:26:56 2015
@@ -4,7 +4,7 @@
#include <errno.h>
#include <assert.h>
-static jmp_buf env;
+static sigjmp_buf env;
/*
* Starting with glibc 2.20 some pthread calls may execute
|
|
From: Tom H. <to...@co...> - 2015-08-24 19:11:24
|
On 24/08/15 19:28, Matthias Schwarzott wrote: > Am 23.08.2015 um 11:13 schrieb Tom Hughes: > >> Can you try changing setjmp to sigsetjmp (with a non-zero second >> argument) and longjmp to siglongjmp, and see if that helps? >> > Yes, that fixes the issue. Thanks for confirming that. Committed as r15587. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: <sv...@va...> - 2015-08-24 19:10:13
|
Author: tom
Date: Mon Aug 24 20:10:06 2015
New Revision: 15587
Log:
Restore signal masks when recovering from xend related signals
Modified:
trunk/helgrind/tests/safe-pthread.h
Modified: trunk/helgrind/tests/safe-pthread.h
==============================================================================
--- trunk/helgrind/tests/safe-pthread.h (original)
+++ trunk/helgrind/tests/safe-pthread.h Mon Aug 24 20:10:06 2015
@@ -15,7 +15,7 @@
static void sigill_handler( int signum, siginfo_t *siginfo, void *sigcontext ) {
unsigned char *pc = siginfo->si_addr;
assert( pc[0] == 0x0f && pc[1] == 0x01 && pc[2] == 0xd5 );
- longjmp( env, EPERM );
+ siglongjmp( env, EPERM );
}
/*
@@ -25,7 +25,7 @@
* just zero, so we cannot add an assert/sanity check.
*/
static void segv_handler( int signum, siginfo_t *siginfo, void *sigcontext ) {
- longjmp( env, EPERM );
+ siglongjmp( env, EPERM );
}
/*
@@ -54,7 +54,7 @@
sigaction( SIGSEGV, &sa_segv, &oldsa_segv );
- if ( ( r = setjmp( env ) ) == 0 ) {
+ if ( ( r = sigsetjmp( env, 1 ) ) == 0 ) {
r = pthread_rwlock_unlock( rwlock );
} else {
r = 0;
|
|
From: Matthias S. <zz...@ge...> - 2015-08-24 18:28:54
|
Am 23.08.2015 um 11:13 schrieb Tom Hughes: > On 22/08/15 06:51, Matthias Schwarzott wrote: >> Am 22.08.2015 um 01:02 schrieb Tom Hughes: >> >>> There shouldn't be a second SIGILL signal. >> >> For me tc20_verifywrap.c triggers SIGILL in three locations: >> * tc20_verifywrap.c:189 (pthread_rwlock_unlock after init) >> * tc20_verifywrap.c:206 (double pthread_rwlock_unlock) >> * tc20_verifywrap.c:227 (three pthread_rwlock_unlock after two >> pthread_rwlock_rdlock) >> >> So technically there should be three SIGILL signals. > > Yes but each one is from a separate call to pthread_rwlock_unlock that > installs the signal handler before it starts and removes it afterwards. > > So there is no question of SA_NODEFER being needed because we are not > getting a SIGLLL while still handling the previous one. We are getting > one, handling it, then getting a second one, handling it, and then > getting a thired one. > >>> When SIGILL is caught we jump >>> out and restore the original handler. >> Yes, but we do not restore the signal mask. And if SA_NODEFER is not >> set, the signal will stay blocked afterwards. And we also do not call >> sigmask/sigblock/sigsetmask. >> >> From man sigaction: >> sa_mask specifies a mask of signals which should be blocked >> (i.e., added to the signal mask of the thread in which the signal >> handler >> is invoked) during execution of the signal handler. In >> addition, the signal which triggered the handler will be blocked, >> unless the >> SA_NODEFER flag is used. > > That mask is only applied while the signal is being handled though, and > should be removed afterwards. > > I have to admit that I'm not quite sure how (or if?) that happens when > you jump out of the handler... So maybe that is the real problem here in > which case the correct solution is likely sigsetjmp/siglongjmp. I think it just does not happen. Normally the return address of the signal handler points to a signal trampoline that cleans up and then calls sigreturn. This function restores the signal mask. Calling longjmp out of the signal handler skips this cleanup part. > > The trouble is that the current solution somehow seems to work for me in > that tc20 survives all three unlocks and then hits the abort. > Hmm, I have no clue. > Can you try changing setjmp to sigsetjmp (with a non-zero second > argument) and longjmp to siglongjmp, and see if that helps? > Yes, that fixes the issue. Regards Matthias |
|
From: Mark W. <mj...@re...> - 2015-08-24 09:15:07
|
On Sat, 2015-08-22 at 00:02 +0200, Philippe Waroquiers wrote: > On Fri, 2015-08-21 at 12:24 +0200, Julian Seward wrote: > > I would like to change the default value for the --partial-loads-ok flag > > so that it is =yes on all targets. Currently it defaults to =yes on OS X > > targets only, and =no on all other targets. > > > > The flag changes the way Memcheck handles loads that are word-sized or > > larger, are naturally aligned, and overlap the end of a heap allocated > > block (typically). Originally, Memcheck would complain about the > > invalid access (due to overlapping the end of the block). But as > > compilers and handwritten assembly have become more agressive about > > vectorization, more and more of these loads show up. They can't cause > > any faults, so the code is correct, but Memcheck complains nonetheless. > > > > Setting the value to =yes causes Memcheck not to complain about the > > invalid access, but to mark the part of the loaded data from the > > "inaccessible" area as undefined. So if it really gets used, Memcheck > > will still complain, but this time, validly. > > > > So I propose to change it to =yes for all targets for 3.11. > Looks reasonable to me. > > Maybe we could change some other clo defaults ? > > I am thinking a.o. to 2 candidates: > > * Change --leak-check-heuristics=none to --leak-check-heuristics=all > This avoids false possibly lost in c++ code. > No memory or cpu impact (except neglectible cpu needed for heuristic > during leak search, when encountering a possibly leaked block). > > * Change --keep-stacktraces=alloc-then-free to alloc-and-free > This gives more information for writes to freed blocks, showing > also the stacktrace where the block was allocated. > Neglectible cpu impact. Memory impact is one word per client > allocated block. I think all three suggestions are good. If we flip these default in the first beta/rc for 3.11 we can ask people to give feedback on them (and see if there is too much performance impact) and then decide to keep them that way for the final release. > Otherwise, for 3.11, I have on my todo list the following things: > 1. run valgrind under valgrind (memcheck) to search for leaks or other > errors inside valgrind itself. > > 2. investigate the shell_script exec test that causes gdbserver to be > closed twice (reported by Florian). Nothing serious, but it is not > supposed to happen. I have now packaged current svn for fedora rawhide and running it on all arches to look for testsuite issues. See the build.logs for armv7hl, i686 and x86_64 here: http://koji.fedoraproject.org/koji/buildinfo?buildID=678051 (ppc64, ppc64le, aarch64 and s390x are still pending) I did notice we have several vgdb test failures because newer GDB will warn of the remove gdbserver doesn't support the new vfile support (host I/O packets): "warning: remote target does not support file transfer, attempting to access files from local filesystem." https://sourceware.org/gdb/onlinedocs/gdb/Host-I_002fO-Packets.html Do you think it makes sense (is it easy?) to implement that, or should we just "set sysroot /" or filter out the warning in our testsuite? Cheers, Mark |