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
(20) |
2
(19) |
3
(7) |
|
4
(13) |
5
(24) |
6
(9) |
7
(12) |
8
(8) |
9
(34) |
10
(28) |
|
11
(20) |
12
(23) |
13
(12) |
14
(10) |
15
(15) |
16
(24) |
17
(26) |
|
18
(17) |
19
(14) |
20
(14) |
21
(8) |
22
(12) |
23
(22) |
24
(10) |
|
25
(21) |
26
(21) |
27
(18) |
28
(8) |
29
(13) |
30
(15) |
|
|
From: Nicholas N. <nj...@cs...> - 2007-11-12 21:14:33
|
On Mon, 12 Nov 2007, Bart Van Assche wrote: > Below you can find the contents of all writev.*.diff* files on my system > (for SVN revisions 7153 / 1793). I'm really puzzled by this -- any help in > solving this is certainly appreciated. This is just one of those annoying cases where different systems give slightly different stack traces. We're already handling three different cases, but your system is slightly different again. Probably the best thing to do is add a .exp4 file. The other test cases that failed -- did they fail for similar reasons? How many of them failed? Nick > head -n 999 memcheck/tests/writev.*.diff* > ==> memcheck/tests/writev.stderr.diff <== > 3c3 > < at 0x........: writev (in /...libc...) > --- >> at 0x........: (within /...libc...) > 9c9 > < at 0x........: writev (in /...libc...) > --- >> at 0x........: (within /...libc...) > 15c15 > < at 0x........: readv (in /...libc...) > --- >> at 0x........: (within /...libc...) > > ==> memcheck/tests/writev.stderr.diff2 <== > 15c15 > < at 0x........: readv (in /...libc...) > --- >> at 0x........: (within /...libc...) > > ==> memcheck/tests/writev.stderr.diff3 <== > 3c3 > < at 0x........: do_writev (in /...libc...) > --- >> at 0x........: (within /...libc...) > 9c9 > < at 0x........: do_writev (in /...libc...) > --- >> at 0x........: (within /...libc...) > 15c15 > < at 0x........: do_readv (in /...libc...) > --- >> at 0x........: (within /...libc...) > |
|
From: Nicholas N. <nj...@cs...> - 2007-11-12 21:08:43
|
On Mon, 12 Nov 2007, Ashley Pittman wrote: > Typically with parallel applications you launch many copies of the same > program with the same command line parameters, the MPI implementation > itself numbers the processes from 0 to N-1 given N processes, this is > known as the MPI "rank" of a process. Most job schedulers used for > launching parallel jobs export the rank as a environment variable so any > wrapper script, such as valgrind, can use this to name log files et al. > > Not having this in cachegrind frequently causes problems, I don't think > cachegrind supports --log-file-exactly currently which means I can't > even use a wrapper shell script to deference the variable. $QUAL support has been added in the trunk, although it's inconsistent at the moment (i.e. the naming scheme is inconsistent). It'll be fixed for 3.3.0. N |
|
From: Ashley P. <api...@co...> - 2007-11-12 20:20:22
|
On Sat, 2007-11-10 at 09:52 +1100, Nicholas Nethercote wrote: > On Sat, 3 Nov 2007, Josef Weidendorfer wrote: > > > I do not understand the benefit of QUAL above. Do I understand correctly, > > and you specify the name of an environment variable here that is substituted > > in the file name? Why can you not just say --cg-out-file=X.$QUAL (ie. the > > substitution is done by the shell at exec time)? > > It's somehow important for MPI programs, where you want every different > process's output to go to a different file. I don't know the details. Typically with parallel applications you launch many copies of the same program with the same command line parameters, the MPI implementation itself numbers the processes from 0 to N-1 given N processes, this is known as the MPI "rank" of a process. Most job schedulers used for launching parallel jobs export the rank as a environment variable so any wrapper script, such as valgrind, can use this to name log files et al. Not having this in cachegrind frequently causes problems, I don't think cachegrind supports --log-file-exactly currently which means I can't even use a wrapper shell script to deference the variable. I have a patch somewhere to add the qualifier to the name of any core file generated, I could dig it out if you think it would help although I if possible I think it would be better so abstract all this out so all the file naming code is handled centrally and all behaves the same way. Ashley, |
|
From: Bart V. A. <bar...@gm...> - 2007-11-12 18:59:29
|
On Nov 11, 2007 10:22 PM, Nicholas Nethercote <nj...@cs...> wrote: > On Sun, 11 Nov 2007, Bart Van Assche wrote: > > > Is any other Valgrind developer using openSUSE 10.3 ? Many regression > > tests that run fine during the nightly build fail on openSUSE 10.3. I > > don't know whether this is due to changes in Valgrind or due to > > changes in gcc, binutils or glibc. > > > > > > $ svn update > > > > Fetching external item into 'VEX' > > External at revision 1793. > > > > At revision 7146. > > > > $ ./autogen.sh && ./configure && make -s && make -s check && make -s > regtest > > ... > > == 350 tests, 66 stderr failures, 50 stdout failures, 0 post failures == > > ... > > > > $ cat memcheck/tests/writev.stderr.diff > > 3c3 > > < at 0x........: writev (in /...libc...) > > --- > >> at 0x........: (within /...libc...) > > 9c9 > > < at 0x........: writev (in /...libc...) > > --- > >> at 0x........: (within /...libc...) > > 15c15 > > < at 0x........: readv (in /...libc...) > > --- > >> at 0x........: (within /...libc...) > > For that test, at least, there are three .exp* files, and the .exp2 one > looks like it should match. What does writev.stderr.diff2 look like? > > Nick > Below you can find the contents of all writev.*.diff* files on my system (for SVN revisions 7153 / 1793). I'm really puzzled by this -- any help in solving this is certainly appreciated. head -n 999 memcheck/tests/writev.*.diff* ==> memcheck/tests/writev.stderr.diff <== 3c3 < at 0x........: writev (in /...libc...) --- > at 0x........: (within /...libc...) 9c9 < at 0x........: writev (in /...libc...) --- > at 0x........: (within /...libc...) 15c15 < at 0x........: readv (in /...libc...) --- > at 0x........: (within /...libc...) ==> memcheck/tests/writev.stderr.diff2 <== 15c15 < at 0x........: readv (in /...libc...) --- > at 0x........: (within /...libc...) ==> memcheck/tests/writev.stderr.diff3 <== 3c3 < at 0x........: do_writev (in /...libc...) --- > at 0x........: (within /...libc...) 9c9 < at 0x........: do_writev (in /...libc...) --- > at 0x........: (within /...libc...) 15c15 < at 0x........: do_readv (in /...libc...) --- > at 0x........: (within /...libc...) |
|
From: John R.
|
Paul Mackerras wrote [regarding r2 as TLS pointer for 32-bit PowerPC]: > I think it's described in the LSB psABI for 32-bit powerpc. Do you have a more specific citation? I can't find any designation of r2 as TLS pointer; only as "System reserved." The page http://refspecs.linux-foundation.org/LSB_3.1.0/LSB-Core-PPC32/LSB-Core-PPC32/normativerefs.html#STD.PPC32.ABI points to http://refspecs.freestandards.org/elf/elfspec_ppc.pdf (dated Sept.1995, twelve years ago) which says that r2 is "System reserved" but does not say anything about TLS (thread-local storage) pointer. The page http://refspecs.linux-foundation.org/LSB_3.1.0/LSB-Core-PPC32/LSB-Core-PPC32/processinitialization.html also does not mention r2. -- |
|
From: Julian S. <js...@ac...> - 2007-11-12 14:33:19
|
> And to think that some call this computer "science"... No, this is software "engineering" :-) J |
|
From: Eyal L. <ey...@ey...> - 2007-11-12 12:41:39
|
15 really did it (completed one servers test now). And to think that some call this computer "science"... Thanks Julian Seward wrote: >>> In the meantime, at hg_main.c:902 reduce N_LSID_BITS from 17 to 16 and >>> try again. > > change to 15 and try again. > > J -- Eyal Lebedinsky (ey...@ey...) |
|
From: Julian S. <js...@ac...> - 2007-11-12 12:15:13
|
> > In the meantime, at hg_main.c:902 reduce N_LSID_BITS from 17 to 16 and > > try again. change to 15 and try again. J |
|
From: Dirk M. <dm...@gm...> - 2007-11-12 12:13:53
|
On Wednesday 07 November 2007, Julian Seward wrote:
> > a real workaround would be to copy the content into a new location (e.g.
> > a local variable) and access that one via its type.
> I'd like to fix it properly, but there's lots of code like this:
>
> while (TC_(nextIterFM)( map_locks, (Word*)(void*)&gla,
> (Word*)(void*)&lk )) {
> ...
> }
Ok, I`ve had a short look at the code and it seems that this is because of a
generic AVL tree implementation based on "Lock" and a few other struct`s. Of
course any casting you do here might silence the warning, but it does not fix
the issue.
The static type of the memory you allocated is "Lock". if you access it
via "Word" (as the AVL implementation does), then you`re violating strict
aliasing. For now this seems to work because the AVL implementation is not
inline, so the compiler doesn`t have much chance at optimi^h^h^h^hscrewing it
up.
A proper solution would be something like
typdef union {
Word* asPtr;
Word asWord;
} AVLBase;
and changing struct Lock into
struct _Lock {
AVLBase admin;
...
Then the nextIterFM calls would look like:
&TC_(nextIterFM)(map_locks, &gla.admin, &lk.admin)
one could hide the ugly detail behind a #define, and it would suddenly look
rather nice. Its a pity that type inheritance is not implemented in C ;)
> > piece of memory via pointers that have a different type (except for the
> > non-symmetrical char* exception). in this case I guess it is because
> > Word*
> char* exception? Does the standard say a char* can point at anything?
not exactly. it is not about pointers, but about the actual access (load or
store). The standard says that as an exception, you can read or modify any
memory via "char" accesses (note, not unsigned/signed char! though that
happens to work as well on almost any platform). The sole motivation behind
that is that memcpy() has to work (which does not know type and is supposed
to copy by char). so something like:
int i = 0;
char* p = (char*)&i;
p[0] = 1;
if (!i) abort();
is going to work. However,
int i = 0;
short* s = (short*)(void*)(char*)&i;
s[0] = 1;
if (!i) abort();
will not.
So, by casting to "char*" inbetween, you`re silencing the warning (because
that is implemented somewhere else in the compiler) but you`re not fixing the
actual aliasing information (which is generated later). In this care, you`re
still accessing memory that has the static aliasing information "struct
_Lock" via "int". those two types may not alias. Even if you casted the
pointer a hundred times inbetween to all kinds of different types, it does
not matter: the actual access matters. In practice, it is possible that you
confuse the compiler good enough so that it will stop "miscompiling" the code
by no longer knowing that it doesn`t have to re-load a value that was already
cached in a register, but any future version of the compiler might become
better at interpreting your cast-chain.
> If yes, can I use the same hack as I just committed, but with char* as
> the intermediate type instead of void* ?
No. Sorry for not following up earlier, I only got reminded of this email
after I read the commit log.
Greetings,
Dirk
|
|
From: Eyal L. <ey...@ey...> - 2007-11-12 11:50:45
|
Sorry to say but this actually did not fix the problem. My first test ran past where it failed before but it did fail later and I can now see that the problem is not resolved. Though the message is slightly different now (tset/lset): Helgrind: Fatal internal error -- cannot continue. Helgrind: mk_SHVAL_ShR(tset=16384,lset=1): FAILED Helgrind: max allowed tset=16383, lset=65535 Helgrind: program has too many thread sets or lock sets to track. Julian Seward wrote: >> Helgrind: Fatal internal error -- cannot continue. >> Helgrind: mk_SHVAL_ShR(tset=8192,lset=1): FAILED >> Helgrind: max allowed tset=8191, lset=131071 >> Helgrind: program has too many thread sets or lock sets to track. > > Yes. It's a problem I'm tracking. Really it is trying to squeeze > too much information into a 32-bit word. It's probably fixable properly > at some performance loss. > > In the meantime, at hg_main.c:902 reduce N_LSID_BITS from 17 to 16 and > try again. > > J -- Eyal Lebedinsky (ey...@ey...) |
|
From: Julian S. <js...@ac...> - 2007-11-12 10:26:24
|
> I notice that I am getting race reports for situations where I > am rather sure that the only active thread is the main thread. It depends what you mean by the "only active thread". Are the other threads still alive but blocked somehow? Or (as below) have they really all exited? > My programs do not apply locks in these sections of the code, > for example during server shutdown after all threads were > join'ed. If all threads merge into one using pthread_join, then you are allowed to access it without a lock. The exact rule (which is somewhat more general than the sentence above implies) is described in detail in the docs, which are unfortunately hard to build. Try this: $ (cd docs && make html-docs) $ konqueror docs/html/hg-manual.html Click on "6.4.4. Restoration of Exclusive Ownership" J |
|
From: Eyal L. <ey...@ey...> - 2007-11-12 10:09:57
|
Julian, Thanks, this fixes it. Can I ask a question then? I notice that I am getting race reports for situations where I am rather sure that the only active thread is the main thread. My programs do not apply locks in these sections of the code, for example during server shutdown after all threads were join'ed. Is this possible or should I check my program again? cheers Eyal Julian Seward wrote: >> Helgrind: Fatal internal error -- cannot continue. >> Helgrind: mk_SHVAL_ShR(tset=8192,lset=1): FAILED >> Helgrind: max allowed tset=8191, lset=131071 >> Helgrind: program has too many thread sets or lock sets to track. > > Yes. It's a problem I'm tracking. Really it is trying to squeeze > too much information into a 32-bit word. It's probably fixable properly > at some performance loss. > > In the meantime, at hg_main.c:902 reduce N_LSID_BITS from 17 to 16 and > try again. > > J -- Eyal Lebedinsky (ey...@ey...) |
|
From: <sv...@va...> - 2007-11-12 07:05:08
|
Author: njn Date: 2007-11-12 07:05:07 +0000 (Mon, 12 Nov 2007) New Revision: 7153 Log: Another attempt at fixing some Massif regtest failures. Modified: trunk/massif/tests/culling1.stderr.exp trunk/massif/tests/culling2.stderr.exp trunk/massif/tests/deep-B.stderr.exp trunk/massif/tests/deep-C.stderr.exp trunk/massif/tests/peak2.stderr.exp trunk/massif/tests/realloc.stderr.exp Modified: trunk/massif/tests/culling1.stderr.exp =================================================================== --- trunk/massif/tests/culling1.stderr.exp 2007-11-12 01:16:24 UTC (rev 7152) +++ trunk/massif/tests/culling1.stderr.exp 2007-11-12 07:05:07 UTC (rev 7153) @@ -426,8 +426,8 @@ Massif: stack frees: 0 Massif: XPts: ... Massif: top-XPts: ... -Massif: XPt init expansions: 3 -Massif: XPt later expansions: 0 +Massif: XPt init expansions: ... +Massif: XPt later expansions: ... Massif: SXPt allocs: ... Massif: SXPt frees: ... Massif: skipped snapshots: 51 Modified: trunk/massif/tests/culling2.stderr.exp =================================================================== --- trunk/massif/tests/culling2.stderr.exp 2007-11-12 01:16:24 UTC (rev 7152) +++ trunk/massif/tests/culling2.stderr.exp 2007-11-12 07:05:07 UTC (rev 7153) @@ -529,8 +529,8 @@ Massif: stack frees: 0 Massif: XPts: ... Massif: top-XPts: ... -Massif: XPt init expansions: 3 -Massif: XPt later expansions: 0 +Massif: XPt init expansions: ... +Massif: XPt later expansions: ... Massif: SXPt allocs: ... Massif: SXPt frees: ... Massif: skipped snapshots: 1 Modified: trunk/massif/tests/deep-B.stderr.exp =================================================================== --- trunk/massif/tests/deep-B.stderr.exp 2007-11-12 01:16:24 UTC (rev 7152) +++ trunk/massif/tests/deep-B.stderr.exp 2007-11-12 07:05:07 UTC (rev 7153) @@ -38,8 +38,8 @@ Massif: stack frees: 0 Massif: XPts: ... Massif: top-XPts: ... -Massif: XPt init expansions: 8 -Massif: XPt later expansions: 0 +Massif: XPt init expansions: ... +Massif: XPt later expansions: ... Massif: SXPt allocs: ... Massif: SXPt frees: ... Massif: skipped snapshots: 0 Modified: trunk/massif/tests/deep-C.stderr.exp =================================================================== --- trunk/massif/tests/deep-C.stderr.exp 2007-11-12 01:16:24 UTC (rev 7152) +++ trunk/massif/tests/deep-C.stderr.exp 2007-11-12 07:05:07 UTC (rev 7153) @@ -41,8 +41,8 @@ Massif: stack frees: 0 Massif: XPts: ... Massif: top-XPts: ... -Massif: XPt init expansions: 5 -Massif: XPt later expansions: 0 +Massif: XPt init expansions: ... +Massif: XPt later expansions: ... Massif: SXPt allocs: ... Massif: SXPt frees: ... Massif: skipped snapshots: 0 Modified: trunk/massif/tests/peak2.stderr.exp =================================================================== --- trunk/massif/tests/peak2.stderr.exp 2007-11-12 01:16:24 UTC (rev 7152) +++ trunk/massif/tests/peak2.stderr.exp 2007-11-12 07:05:07 UTC (rev 7153) @@ -96,8 +96,8 @@ Massif: stack frees: 0 Massif: XPts: ... Massif: top-XPts: ... -Massif: XPt init expansions: 5 -Massif: XPt later expansions: 0 +Massif: XPt init expansions: ... +Massif: XPt later expansions: ... Massif: SXPt allocs: ... Massif: SXPt frees: ... Massif: skipped snapshots: 0 Modified: trunk/massif/tests/realloc.stderr.exp =================================================================== --- trunk/massif/tests/realloc.stderr.exp 2007-11-12 01:16:24 UTC (rev 7152) +++ trunk/massif/tests/realloc.stderr.exp 2007-11-12 07:05:07 UTC (rev 7153) @@ -28,8 +28,8 @@ Massif: stack frees: 0 Massif: XPts: ... Massif: top-XPts: ... -Massif: XPt init expansions: 9 -Massif: XPt later expansions: 0 +Massif: XPt init expansions: ... +Massif: XPt later expansions: ... Massif: SXPt allocs: ... Massif: SXPt frees: ... Massif: skipped snapshots: 0 |
|
From: Paul M. <pa...@sa...> - 2007-11-12 03:31:19
|
John Reiser writes: > > It's now used as the TLS pointer. It should get initialized for the > > main thread in glibc, and for other threads by the clone() system > > call. ... > > Please give a citation to a reference for this change. I think it's described in the LSB psABI for 32-bit powerpc. Paul. |
|
From: Tom H. <th...@cy...> - 2007-11-12 03:27:45
|
Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2007-11-12 03:05:06 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 == 350 tests, 12 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) massif/tests/culling1 (stderr) massif/tests/culling2 (stderr) massif/tests/deep-B (stderr) massif/tests/deep-C (stderr) massif/tests/peak2 (stderr) massif/tests/realloc (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc22_exit_w_lock (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 == 350 tests, 11 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) massif/tests/culling1 (stderr) massif/tests/culling2 (stderr) massif/tests/deep-C (stderr) massif/tests/peak2 (stderr) massif/tests/realloc (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc22_exit_w_lock (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Mon Nov 12 03:14:01 2007 --- new.short Mon Nov 12 03:27:47 2007 *************** *** 8,10 **** ! == 350 tests, 11 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/pointer-trace (stderr) --- 8,10 ---- ! == 350 tests, 12 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/pointer-trace (stderr) *************** *** 15,16 **** --- 15,17 ---- massif/tests/culling2 (stderr) + massif/tests/deep-B (stderr) massif/tests/deep-C (stderr) |
|
From: Tom H. <th...@cy...> - 2007-11-12 03:27:23
|
Nightly build on dellow ( x86_64, Fedora 7 ) started at 2007-11-12 03:10:07 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 == 350 tests, 13 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) massif/tests/culling1 (stderr) massif/tests/culling2 (stderr) massif/tests/deep-B (stderr) massif/tests/deep-C (stderr) massif/tests/peak2 (stderr) massif/tests/realloc (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc22_exit_w_lock (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 == 350 tests, 11 stderr failures, 3 stdout failures, 0 post failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) massif/tests/culling1 (stderr) massif/tests/culling2 (stderr) massif/tests/deep-C (stderr) massif/tests/peak2 (stderr) massif/tests/realloc (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/pth_detached (stdout) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc22_exit_w_lock (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Mon Nov 12 03:18:27 2007 --- new.short Mon Nov 12 03:27:19 2007 *************** *** 8,10 **** ! == 350 tests, 11 stderr failures, 3 stdout failures, 0 post failures == memcheck/tests/pointer-trace (stderr) --- 8,10 ---- ! == 350 tests, 13 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/pointer-trace (stderr) *************** *** 15,16 **** --- 15,17 ---- massif/tests/culling2 (stderr) + massif/tests/deep-B (stderr) massif/tests/deep-C (stderr) *************** *** 20,22 **** none/tests/mremap2 (stdout) ! none/tests/pth_detached (stdout) helgrind/tests/tc20_verifywrap (stderr) --- 21,23 ---- none/tests/mremap2 (stdout) ! helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc20_verifywrap (stderr) |
|
From: Tom H. <th...@cy...> - 2007-11-12 03:21:24
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2007-11-12 03:00:02 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 == 352 tests, 30 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) massif/tests/culling1 (stderr) massif/tests/culling2 (stderr) massif/tests/deep-B (stderr) massif/tests/deep-C (stderr) massif/tests/peak2 (stderr) massif/tests/realloc (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) helgrind/tests/hg01_all_ok (stderr) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (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 == 352 tests, 28 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) massif/tests/culling1 (stderr) massif/tests/culling2 (stderr) massif/tests/deep-C (stderr) massif/tests/peak2 (stderr) massif/tests/realloc (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) helgrind/tests/hg01_all_ok (stderr) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Mon Nov 12 03:07:33 2007 --- new.short Mon Nov 12 03:21:23 2007 *************** *** 8,10 **** ! == 352 tests, 28 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/pointer-trace (stderr) --- 8,10 ---- ! == 352 tests, 30 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/pointer-trace (stderr) *************** *** 15,16 **** --- 15,17 ---- massif/tests/culling2 (stderr) + massif/tests/deep-B (stderr) massif/tests/deep-C (stderr) *************** *** 33,34 **** --- 34,36 ---- helgrind/tests/tc17_sembar (stderr) + helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc19_shadowmem (stderr) |
|
From: John R.
|
Paul Mackerras wrote: > Julian Seward writes: > > >>complaining that r2 contains an undefined value. ... > > It's now used as the TLS pointer. It should get initialized for the > main thread in glibc, and for other threads by the clone() system > call. ... Please give a citation to a reference for this change. -- |
|
From: Paul M. <pa...@sa...> - 2007-11-12 02:29:57
|
Julian Seward writes: > complaining that r2 contains an undefined value. And it's true; > it is not written at all in the procedure in which this is > reported. Which is odd. AFAIK r2 is not an argument register > and it didn't used to have any particular meaning in the ppc32 ELF > ABI. It's now used as the TLS pointer. It should get initialized for the main thread in glibc, and for other threads by the clone() system call. Maybe the CLONE_SETTLS flag isn't handled properly by the syscall wrapper for clone? It should cause r2 in the child to be initialized to the value of the 4th argument (for 32-bit processes; 64-bit processes use r13 instead). Paul. |
|
From: Julian S. <js...@ac...> - 2007-11-12 01:35:06
|
I've been testing Valgrind on a recent ppc distro, openSUSE 10.3 running on a 32-bit ppc box. Memcheck generates huge numbers of undefined value errors even for the simplest program (eg /bin/date) and I'm trying to figure out what's going on. Many of the errors seem to relate to load instructions like this 387d8: 80 02 8f f4 lwz r0,-28684(r2) complaining that r2 contains an undefined value. And it's true; it is not written at all in the procedure in which this is reported. Which is odd. AFAIK r2 is not an argument register and it didn't used to have any particular meaning in the ppc32 ELF ABI. Now I'm wondering if the 32-bit ABI has morphed into something more similar to the 64-bit ppc ELF ABI. That uses r2 to point to tables of constants, which kinda looks like what I'm seeing. Or perhaps it is being used as a pointer to some thread-local data area? Anybody know anything about this? This is with gcc-4.2.1, gcc-2.6.1, kernel 2.6.22.9-0.4-default. J |
|
From: <js...@ac...> - 2007-11-12 01:21:37
|
Nightly build on g5 ( SuSE 10.1, ppc970 ) started at 2007-11-12 02:00:01 CET 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 == 284 tests, 30 stderr failures, 3 stdout failures, 0 post failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/pointer-trace (stderr) massif/tests/culling1 (stderr) massif/tests/culling2 (stderr) massif/tests/deep-C (stderr) massif/tests/peak2 (stderr) massif/tests/realloc (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc07_hbl1 (stderr) helgrind/tests/tc08_hbl2 (stdout) helgrind/tests/tc08_hbl2 (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc11_XCHG (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (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 == 284 tests, 30 stderr failures, 3 stdout failures, 0 post failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/pointer-trace (stderr) massif/tests/culling1 (stderr) massif/tests/culling2 (stderr) massif/tests/deep-C (stderr) massif/tests/peak2 (stderr) massif/tests/realloc (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/res_search (stdout) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc07_hbl1 (stderr) helgrind/tests/tc08_hbl2 (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc11_XCHG (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Mon Nov 12 02:10:38 2007 --- new.short Mon Nov 12 02:21:34 2007 *************** *** 22,24 **** none/tests/mremap2 (stdout) - none/tests/res_search (stdout) helgrind/tests/hg02_deadlock (stderr) --- 22,23 ---- *************** *** 31,32 **** --- 30,32 ---- helgrind/tests/tc07_hbl1 (stderr) + helgrind/tests/tc08_hbl2 (stdout) helgrind/tests/tc08_hbl2 (stderr) |
|
From: <sv...@va...> - 2007-11-12 01:16:24
|
Author: njn Date: 2007-11-12 01:16:24 +0000 (Mon, 12 Nov 2007) New Revision: 7152 Log: Fix verbose output filtering for Massif. Modified: trunk/massif/tests/filter_verbose Modified: trunk/massif/tests/filter_verbose =================================================================== --- trunk/massif/tests/filter_verbose 2007-11-12 01:01:08 UTC (rev 7151) +++ trunk/massif/tests/filter_verbose 2007-11-12 01:16:24 UTC (rev 7152) @@ -16,8 +16,8 @@ # zero than other machines. So filter them out. sed "s/\(Massif: XPts:\).*/\1 .../" | sed "s/\(Massif: top-XPts:\).*/\1 .../" | -sed "s/\(Massif: XPt-init-expansions:\).*/\1 .../" | -sed "s/\(Massif: XPt-later-expansions:\).*/\1 .../" | +sed "s/\(Massif: XPt init expansions:\).*/\1 .../" | +sed "s/\(Massif: XPt later expansions:\).*/\1 .../" | sed "s/\(Massif: SXPt allocs:\).*/\1 .../" | sed "s/\(Massif: SXPt frees:\).*/\1 .../" | sed "s/\(Massif: XCon redos:\).*/\1 .../" |
|
From: <sv...@va...> - 2007-11-12 01:01:20
|
Author: sewardj
Date: 2007-11-12 01:01:08 +0000 (Mon, 12 Nov 2007)
New Revision: 7151
Log:
More glibc-2.6 suppressions.
Modified:
trunk/glibc-2.3456-NPTL-helgrind.supp
Modified: trunk/glibc-2.3456-NPTL-helgrind.supp
===================================================================
--- trunk/glibc-2.3456-NPTL-helgrind.supp 2007-11-11 22:15:58 UTC (rev 7150)
+++ trunk/glibc-2.3456-NPTL-helgrind.supp 2007-11-12 01:01:08 UTC (rev 7151)
@@ -233,6 +233,19 @@
obj:/lib*/libpthread-2.6.*so
obj:/lib*/libc-2.6.*so
}
+{
+ helgrind-glibc26-011
+ Helgrind:Race
+ obj:/lib*/libc-2.6.*so
+ obj:/lib*/libpthread-2.6.*so
+}
+{
+ helgrind-glibc26-014
+ Helgrind:Race
+ obj:/lib*/ld-2.6.*so
+ obj:/lib*/ld-2.6.*so
+ obj:/lib*/libpthread-2.6.*so
+}
{
helgrind-glibc26-101
|