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
(8) |
2
(8) |
3
(7) |
|
4
(3) |
5
(6) |
6
(9) |
7
(8) |
8
(7) |
9
(7) |
10
(18) |
|
11
(7) |
12
(11) |
13
(24) |
14
(13) |
15
(11) |
16
(18) |
17
(7) |
|
18
(8) |
19
(7) |
20
(9) |
21
(24) |
22
(18) |
23
(10) |
24
(7) |
|
25
(8) |
26
(11) |
27
(14) |
28
(7) |
29
(10) |
30
(7) |
|
|
From: Robert W. <rj...@du...> - 2004-04-13 21:47:37
|
Hi all, I've updated the patch on the KDE Bugzilla site with feedback from Nick (comments, filename changes, etc): http://bugs.kde.org/show_bug.cgi?id=73655 Have at it! Regards, Robert. |
|
From: Robert W. <rj...@du...> - 2004-04-13 21:40:09
|
> So if a program has its own version of new or new[], Valgrind doesn't know
> anything about them, and any heap blocks allocated with them won't be
> checked as normal?
Well, most of these new and deletes are going to be doing some sort of
allocation and freeing at the end of the day. I can see several
scenarios:
* custom allocator doesn't actually allocate anything.
* custom allocator allocates memory by doing a call to the glibc
version of the allocator after looking up it's address using
dlsym(RTLD_NEXT, ...).
* custom allocator allocates memory by doing a call to malloc or
some other existing allocator.
* custom allocator allocates memory using some custom mechanism,
such as a memory pool.
In the first scenario, nothing happens. That's just weird anyway, and I
can't imagine it happening very often, but you never know. In any case,
nothing is allocated and life goes on. Valgrind won't mind at all.
In the second scenario, the glibc allocator is eventually called, but
that call gets intercepted by Valgrind and treated as normal. This is
probably most often used for error-checking malloc wrappers and the
like.
In the third scenario, operator new or whatever calls malloc or
something like that. This too will get intercepted by Valgrind as a
regular malloc. This is what the new_override.cpp test does.
In the fourth scenario, everything is up in the air, but I don't see why
Valgrind should care, as long as the underlying memory allocation
mechanism is intercepted.
If I'm forgetting anything, let me know.
> Is it possible to have a custom 'new' but a non-custom
> 'delete'? That could cause false free errors?
Yes, but I don't think they'd be false errors. If your custom operator
new() uses malloc, then your custom operator delete() should use
free... If there is not custom operator delete(), then you're doing
something wrong and Valgrind would be correct in pointing that out.
Regards,
Robert.
|
|
From: Tom H. <th...@cy...> - 2004-04-13 21:37:03
|
In message <Pin...@ye...>
Nicholas Nethercote <nj...@ca...> wrote:
> So if a program has its own version of new or new[], Valgrind doesn't know
> anything about them, and any heap blocks allocated with them won't be
> checked as normal? Is it possible to have a custom 'new' but a non-custom
> 'delete'? That could cause false free errors?
Well it's possible in as much as you could write code to do that, but
it would usually be a bad plan as the custom new would presumably have
allocated memory in some special way that an ordinary delete wouldn't
know how to free.
I guess you might have a custom new that does an ordinary new and then
initialises the memory or something, so that the ordinary delete would
be fine.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-04-13 21:23:11
|
On Tue, 13 Apr 2004, Robert Walsh wrote: > The test is borked. new Test[2] doesn't ever call the operator new > defined in that file because it's looking for operator new[] instead. > I'll fix the test in the patch and make a new release of the patch later > tonight. So if a program has its own version of new or new[], Valgrind doesn't know anything about them, and any heap blocks allocated with them won't be checked as normal? Is it possible to have a custom 'new' but a non-custom 'delete'? That could cause false free errors? N |
|
From: Robert W. <rj...@du...> - 2004-04-13 21:09:27
|
> > I probably would have just replaced them with underscores, but hey, if it > > works... it's not like any compiler other than GCC can compile Valgrind. > > Rereading that... last bit might sound sarcastic, but it wasn't meant to > be; certain features (esp. nested functions) mean GCC is the only > compiler that can compile Valgrind, AFAIK. Right. I spent about 2 whole minutes agonising over what character to use as the escape and choose a dollar symbol. We can replace it with something else if it every becomes an issue. Regards, Robert. |
|
From: Nicholas N. <nj...@ca...> - 2004-04-13 21:02:17
|
On Tue, 13 Apr 2004, Nicholas Nethercote wrote: > I probably would have just replaced them with underscores, but hey, if it > works... it's not like any compiler other than GCC can compile Valgrind. Rereading that... last bit might sound sarcastic, but it wasn't meant to be; certain features (esp. nested functions) mean GCC is the only compiler that can compile Valgrind, AFAIK. N |
|
From: Nicholas N. <nj...@ca...> - 2004-04-13 20:50:40
|
On Tue, 13 Apr 2004, Robert Walsh wrote: > The dollar symbols are legal in symbols in gcc, believe > it or not. We use them to delimit bits of the symbol. The two numbers > following it are hex digits of a character that isn't legal in a symbol, > so $3A == ':' and $2E == '.'. So this function is: > > soname:libc.so.6:__raise > > This is plucked apart by the scanning code to set up the intercept > table. This basically says "the function called > _vgi__soname$3Alibc$2Eso$2E6$3A__raise is an intercept for __raise in > the shared object called libc.so.6." > > Ugly, but it works. :-) If you can think of a cleaner mechanism, I'd > like to hear about it. I probably would have just replaced them with underscores, but hey, if it works... it's not like any compiler other than GCC can compile Valgrind. N |
|
From: Robert W. <rj...@du...> - 2004-04-13 20:43:46
|
> Sounds plausible. Is it documented? Phngh. > I'm not sure if the comments in > vg_intercept.vgi now match with the reality. A precis of your description > could be what's needed... Okey dokey. I'll put a better description extracted from my message into vg_intercept.c.base. > Also, I see in the generated vg_intercept.c lines like this: > > int VG_INTERCEPT(soname$3Alibc$2Eso$2E6$3A__raise)(int) > > How does that work? What's with the dollar signs? VG_INTERCEPT is a C macro that just sticks a magic preamble onto the symbol so that we can pick it up automatically when we're scanning the symbol table. The dollar symbols are legal in symbols in gcc, believe it or not. We use them to delimit bits of the symbol. The two numbers following it are hex digits of a character that isn't legal in a symbol, so $3A == ':' and $2E == '.'. So this function is: soname:libc.so.6:__raise This is plucked apart by the scanning code to set up the intercept table. This basically says "the function called _vgi__soname$3Alibc$2Eso$2E6$3A__raise is an intercept for __raise in the shared object called libc.so.6." Ugly, but it works. :-) If you can think of a cleaner mechanism, I'd like to hear about it. Regards, Robert. |
|
From: Tom H. <th...@cy...> - 2004-04-13 20:37:55
|
In message <Pin...@ye...>
Nicholas Nethercote <nj...@ca...> wrote:
> Also, I see in the generated vg_intercept.c lines like this:
>
> int VG_INTERCEPT(soname$3Alibc$2Eso$2E6$3A__raise)(int)
>
> How does that work? What's with the dollar signs?
Well looking at it I'd guess $xx is a hex escape, as $2E would be
a '.' character which makes sense for libc.so in that line.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-04-13 20:33:33
|
On Tue, 13 Apr 2004, Robert Walsh wrote: > The test is borked. new Test[2] doesn't ever call the operator new > defined in that file because it's looking for operator new[] instead. > I'll fix the test in the patch and make a new release of the patch later > tonight. Ah, of course. > First, the problem: the problem was that Valgrind was always > intercepting operator new, even when your program defined it's own > version of it. This is why new_override.cpp would never have worked > even if it had been overriding operator new[]. [snip] > Does that make sense? Sounds plausible. Is it documented? I'm not sure if the comments in vg_intercept.vgi now match with the reality. A precis of your description could be what's needed... Also, I see in the generated vg_intercept.c lines like this: int VG_INTERCEPT(soname$3Alibc$2Eso$2E6$3A__raise)(int) How does that work? What's with the dollar signs? N |
|
From: Madhu M K. <mm...@ya...> - 2004-04-13 19:30:16
|
Hi, Nicholas Nethercote <nj...@ca...> said on April 13,2004: > > suppressions, eg. dumping all --gen-suppressions output to a file to > save all the cutting and pasting; probably a good idea, but I'm not > addressing that here. > I was just about to resend my patch to do precisely that. It does the following: - create a suppfile / pid - determines frequency counts for suppressions seen - orders them This enables you to tackle the errors that occur once or twice and show up in suppressions, which most often I have found to be *real* errors. In some of our internal tests, valgrind with this patch produced a suppression file that had ~ 100 rules which then went on to suppress ~ 300K errors. And all of that was via openssl - Value4/Param "errors". Cheerio, M Madhu M Kurup /* Nemo Me Impune Lacessit */ mmk at yahoo-inc dt com |
|
From: Robert W. <rj...@du...> - 2004-04-13 19:11:32
|
CVS commit by rjwalsh:
Fix new override test.
A new_override.stdout.exp 1.1
M +1 -1 new_override.cpp 1.3
--- valgrind/memcheck/tests/new_override.cpp #1.2:1.3
@@ -7,5 +7,5 @@ public:
};
-void *operator new(size_t size)
+void *operator new[](size_t size)
{
void *ret = malloc(size);
|
|
From: Robert W. <rj...@du...> - 2004-04-13 19:08:40
|
CVS commit by rjwalsh:
Update test for recent "recently" fix.
M +1 -1 buflen_check.stderr.exp 1.9
--- valgrind/memcheck/tests/buflen_check.stderr.exp #1.8:1.9
@@ -9,5 +9,5 @@
by 0x........: __libc_start_main (...libc...)
by 0x........: ...
- Address 0x........ is not stack'd, malloc'd or free'd
+ Address 0x........ is not stack'd, malloc'd or (recently) free'd
getsockname(1) failed
getsockname(2) failed
|
|
From: Robert W. <rj...@du...> - 2004-04-13 18:57:47
|
> I tried it; that test case works on my, er, RH 9 box too. Yea! Now we know it's safe :-) > What about the memcheck/tests/new_override.cpp test? The expected output > in the .exp file is that Valgrind's 'new' takes precedence, which is > actually wrong here. With your patch, I'm still getting V's new taking > precedence. The test is borked. new Test[2] doesn't ever call the operator new defined in that file because it's looking for operator new[] instead. I'll fix the test in the patch and make a new release of the patch later tonight. > Also, you're now generating vg_intercept.c and vg_replace_malloc.c, from > files with .vgi extensions... we already have similar files with .base > extensions (vg_skin.h.base)... should be consistent here. Yes. I'll do that, too. > Finally, how does your patch actually work? What did you change? First, the problem: the problem was that Valgrind was always intercepting operator new, even when your program defined it's own version of it. This is why new_override.cpp would never have worked even if it had been overriding operator new[]. This was happening because the preloaded vg_inject.so had an exported operator new symbol. This was to work around the following issue: vg_inject.so used an init segment to set up the intercept table. However, there was no guarantee that vg_inject.so would have it's init segment run before any other shared object. This meant that a shared object that had an init section that called operator new might actually have ended up using the glibc version instead of the Valgrind one if the intercept table hadn't been set up yet, causing all sorts of confusion. However, exporting the operator new function in vg_inject.so worked around this issue by ensuring that the Valgrind one was always used. Of course, this meant that the Valgrind one was always used, even if your program defined it's own version. The solution was to get rid of any symbol called "operator new" (or, actually, _Znwj) from the vg_inject.so file. This meant that a program-defined operator new got resolved properly. However, we needed some way of setting up the intercept table before hand. Jeremy and I talked about this for a few hours and decided to go with the solution I adopted. We now mangle the symbols in vg_inject.so so that they can be demangled to indicate exactly what library and function they are overriding. When a .so file is loaded, we slurp in the symbol table, pick out those symbols that match the mangled syntax we defined, demangle the symbol into a library name/function name pair and set up the table that way. In order to make the whole thing a bit more palatable, we use a pre-processor to turn a human-readable version of the file (the .vgi files) into the mangled version. The above also goes for all other overridden symbols, not just operator new. Does that make sense? Thanks for the feedback. Regards, Robert. |
|
From: Nicholas N. <nj...@ca...> - 2004-04-13 10:25:51
|
On Sun, 11 Apr 2004, Robert Walsh wrote: > I think I finally have a working patch for bug 73655. I've tested it on > RedHat 9 and everything appears to be working just fine. I'd really like > it if someone could test on something else (Fedora, say) just so I'm not > borking any of the other builds. If someone could volunteer for this, I'd > really appreciate it. I tried it; that test case works on my, er, RH 9 box too. What about the memcheck/tests/new_override.cpp test? The expected output in the .exp file is that Valgrind's 'new' takes precedence, which is actually wrong here. With your patch, I'm still getting V's new taking precedence. Also, you're now generating vg_intercept.c and vg_replace_malloc.c, from files with .vgi extensions... we already have similar files with .base extensions (vg_skin.h.base)... should be consistent here. Finally, how does your patch actually work? What did you change? thanks N |
|
From: Nicholas N. <nj...@ca...> - 2004-04-13 10:09:36
|
Hi,
I've been thinking about improving the suppression syntax. It really is
pretty awful at the moment, so many people don't understand it, even with
--gen-suppressions.
I've worked out pretty clearly the reasons why people find it confusing.
But I haven't come up with a new syntax that fixes all the problems; I
have some ideas, but they're not quite right yet. I thought I'd run it
past some other eyes.
Note that people have also requested better ways of generated the
suppressions, eg. dumping all --gen-suppressions output to a file to save
all the cutting and pasting; probably a good idea, but I'm not addressing
that here.
Comments appreciated.
N
The suppression syntax is generally confusing -- people just can't get
it right. Ideally, you should be able to write your own suppression
without reading the manual (nobody does) just by looking at existing
examples.
Specific problems with the current format:
- it's unclear that different lines have different roles:
- line 1: name
- line 2: tool:type
- lines 3+: stack trace
- it's unclear that the suppression name is arbitrary (the common a/b/c
form in the default .supp files might make people think the slashes
are meaningful?)
- it's unclear that you need "core" in front of the type for PThread errors
- supp types unclear, in two ways:
- unclear what type each error has, easy to mix up (eg. using
Value4 instead of Addr4)
- people sometimes get them completely wrong -- have no idea what
the type even means
- it's unclear that the trace must match exactly, ie. line-by-line
- sometimes a line is missed, esp. the first one
- sometimes people try to match multiple similar errors with one set of
lines that partially match
- sometimes we have an almost meaningless "fun:*" as the last line,
indicates likely confusion
- one person seemed to think that each line gave a different
suppression, ie. you could specify suppress all errors of a
single type in a single {} block
- it's unclear that obj: matches executables as well as .so files
- it's possibly unclear that you can use either the fun: or obj: form
to match a line like this:
==3643== by 0x804835A: main (in /auto/homes/njn25/grind/head5/a.out)
- The extra info for Param errors in Memcheck is a nasty kludge;
inconsistent and thus highly confusing
- unclear that C++ names must be mangled
[hard to address in syntax...]
Desired functionality:
- need much greater depth than 4 -- have seen examples where the
distinguishing part of the call chain was 11--14 deep. Should
support arbitrary length.
- want a wildcard to match a single entry, and one for multiple
entries. Shouldn't be easily confusible with * and ? as wildcards
within entries. (ie. clearly distinguish inter-entry and intra-entry
wildcards).
- sometimes want to match against "???:???" (could do with a
single-entry wildcard)
- sometimes want to match against a .c source file name?
- possibilities:
at 0x80483BF: really (malloc1.c:20)
at 0x80483BF: really (in /foo/a.out)
at 0x80483BF: (within /foo/a.out)
func:really should match the first two?
file:malloc1.c should match the first one?
obj:/foo/a.out should match the last two?
[should we really distinguish between "in" and "within"?]
- want to be able to partially specify call traces, using wildcards,
eg:
bad_func() ... -> ... malloc()
purify style:
# suppress abr GetNextFontList; _XmCvtStringToXmFontList; XtDirectConvert
But do wildcards match a single entry, or multiple? If multiple,
greedy or non-greedy matching?
- could be more flexible with whitespace
-----------------------------------------------------------------------------
possible new syntax
-----------------------------------------------------------------------------
Memcheck,Addrcheck:Addr4("this is the name of it")[optional part?]
[
fun:blahblah,
fil:foobar,
..., multi-matching wildcard?
obj:foo*,
_, single-matching wildcard?
obj:floo
]
- name as string gives a clue that it's arbitrary
- commas after trace lines indicate they're part of a sequence, as does
grouping them together within the brackets, as does (maybe) the
use of square brackets
- different roles of different parts much clearer
- ... gives more flexibility; the different meanings of "..." vs. '*'/'?'
wildcards should be clear XXX: really?
- lots of the complaints above not addressed, however
|
|
From: Nicholas N. <nj...@ca...> - 2004-04-13 08:47:39
|
CVS commit by nethercote:
Suppressions of jump errors were broken, because the size was zero and
so caused an assertion failure. So set size == 1 -- it's only used for
suppressions.
M +1 -0 mac_needs.c 1.24
--- valgrind/memcheck/mac_needs.c #1.23:1.24
@@ -474,4 +474,5 @@ void MAC_(record_jump_error) ( ThreadId
MAC_(clear_MAC_Error)( &err_extra );
err_extra.axskind = ExecAxs;
+ err_extra.size = 1; // size only used for suppressions
err_extra.addrinfo.akind = Undescribed;
VG_(maybe_record_error)( tid, AddrErr, a, /*s*/NULL, &err_extra );
|
|
From: Nicholas N. <nj...@ca...> - 2004-04-13 08:36:42
|
CVS commit by nethercote:
Changed error message from:
Address 0x%x is not stack'd, malloc'd or free'd
to
Address 0x%x is not stack'd, malloc'd or (recently) free'd
This makes things clearer in some circumstances, particularly when bogusly
accessing heap memory that has been freed, but Memcheck is no longer tracking.
M +1 -1 addrcheck/tests/fprw.stderr.exp 1.4
M +1 -1 helgrind/hg_main.c 1.75
M +1 -1 memcheck/mac_needs.c 1.23
M +1 -1 memcheck/tests/badfree-2trace.stderr.exp 1.6
M +1 -1 memcheck/tests/badfree.stderr.exp 1.10
M +1 -1 memcheck/tests/badjump.stderr.exp 1.9
M +1 -1 memcheck/tests/buflen_check.stderr.exp 1.8
M +1 -1 memcheck/tests/custom_alloc.stderr.exp 1.5
M +3 -3 memcheck/tests/execve.stderr.exp 1.2
M +1 -1 memcheck/tests/fprw.stderr.exp 1.10
M +1 -1 memcheck/tests/signal2.stderr.exp 1.9
M +3 -3 memcheck/tests/writev.stderr.exp 1.6
--- valgrind/addrcheck/tests/fprw.stderr.exp #1.3:1.4
@@ -26,5 +26,5 @@
at 0x........: free (vg_replace_malloc.c:...)
by 0x........: main (fprw.c:22)
- Address 0x........ is not stack'd, malloc'd or free'd
+ Address 0x........ is not stack'd, malloc'd or (recently) free'd
Invalid write of size 8
--- valgrind/helgrind/hg_main.c #1.74:1.75
@@ -2586,5 +2586,5 @@ static void pp_AddrInfo ( Addr a, AddrIn
} else {
VG_(message)(Vg_UserMsg,
- " Address %p is not stack'd, malloc'd or free'd", a);
+ " Address %p is not stack'd, malloc'd or (recently) free'd", a);
}
break;
--- valgrind/memcheck/mac_needs.c #1.22:1.23
@@ -239,5 +239,5 @@ void MAC_(pp_AddrInfo) ( Addr a, AddrInf
} else {
VG_(message)(Vg_UserMsg,
- " Address 0x%x is not stack'd, malloc'd or free'd", a);
+ " Address 0x%x is not stack'd, malloc'd or (recently) free'd",a);
}
break;
--- valgrind/memcheck/tests/badfree-2trace.stderr.exp #1.5:1.6
@@ -2,5 +2,5 @@
at 0x........: free (vg_replace_malloc.c:...)
by 0x........: main (badfree.c:12)
- Address 0x........ is not stack'd, malloc'd or free'd
+ Address 0x........ is not stack'd, malloc'd or (recently) free'd
Invalid free() / delete / delete[]
--- valgrind/memcheck/tests/badfree.stderr.exp #1.9:1.10
@@ -2,5 +2,5 @@
at 0x........: free (vg_replace_malloc.c:...)
by 0x........: main (badfree.c:12)
- Address 0x........ is not stack'd, malloc'd or free'd
+ Address 0x........ is not stack'd, malloc'd or (recently) free'd
Invalid free() / delete / delete[]
--- valgrind/memcheck/tests/badjump.stderr.exp #1.8:1.9
@@ -4,5 +4,5 @@
by 0x........: __libc_start_main (...libc...)
by 0x........: ...
- Address 0x........ is not stack'd, malloc'd or free'd
+ Address 0x........ is not stack'd, malloc'd or (recently) free'd
Process terminating with default action of signal 11 (SIGSEGV)
--- valgrind/memcheck/tests/buflen_check.stderr.exp #1.7:1.8
@@ -3,5 +3,5 @@
by 0x........: __libc_start_main (...libc...)
by 0x........: ...
- Address 0x........ is not stack'd, malloc'd or free'd
+ Address 0x........ is not stack'd, malloc'd or (recently) free'd
Syscall param socketcall.getsockname(namelen_in) contains uninitialised or unaddressable byte(s)
--- valgrind/memcheck/tests/custom_alloc.stderr.exp #1.4:1.5
@@ -9,5 +9,5 @@
at 0x........: custom_free (custom_alloc.c:54)
by 0x........: main (custom_alloc.c:83)
- Address 0x........ is not stack'd, malloc'd or free'd
+ Address 0x........ is not stack'd, malloc'd or (recently) free'd
Mismatched free() / delete / delete []
--- valgrind/memcheck/tests/execve.stderr.exp #1.1:1.2
@@ -2,13 +2,13 @@
at 0x........: execve (in /...libc...)
by 0x........: main (execve.c:8)
- Address 0x........ is not stack'd, malloc'd or free'd
+ Address 0x........ is not stack'd, malloc'd or (recently) free'd
Syscall param execve(argv[i]) contains uninitialised or unaddressable byte(s)
at 0x........: execve (in /...libc...)
by 0x........: main (execve.c:8)
- Address 0x........ is not stack'd, malloc'd or free'd
+ Address 0x........ is not stack'd, malloc'd or (recently) free'd
Syscall param execve(envp[i]) contains uninitialised or unaddressable byte(s)
at 0x........: execve (in /...libc...)
by 0x........: main (execve.c:8)
- Address 0x........ is not stack'd, malloc'd or free'd
+ Address 0x........ is not stack'd, malloc'd or (recently) free'd
--- valgrind/memcheck/tests/fprw.stderr.exp #1.9:1.10
@@ -38,5 +38,5 @@
at 0x........: free (vg_replace_malloc.c:...)
by 0x........: main (fprw.c:22)
- Address 0x........ is not stack'd, malloc'd or free'd
+ Address 0x........ is not stack'd, malloc'd or (recently) free'd
Invalid write of size 8
--- valgrind/memcheck/tests/signal2.stderr.exp #1.8:1.9
@@ -1,3 +1,3 @@
Invalid write of size 4
at 0x........: main (signal2.c:17)
- Address 0x........ is not stack'd, malloc'd or free'd
+ Address 0x........ is not stack'd, malloc'd or (recently) free'd
--- valgrind/memcheck/tests/writev.stderr.exp #1.5:1.6
@@ -4,5 +4,5 @@
at 0x........: writev (in /...libc...)
by 0x........: main (writev.c:56)
- Address 0x........ is not stack'd, malloc'd or free'd
+ Address 0x........ is not stack'd, malloc'd or (recently) free'd
Received EFAULT as expected
@@ -10,5 +10,5 @@
at 0x........: writev (in /...libc...)
by 0x........: main (writev.c:68)
- Address 0x........ is not stack'd, malloc'd or free'd
+ Address 0x........ is not stack'd, malloc'd or (recently) free'd
Received EINVAL as expected
@@ -16,5 +16,5 @@
at 0x........: readv (in /...libc...)
by 0x........: main (writev.c:76)
- Address 0x........ is not stack'd, malloc'd or free'd
+ Address 0x........ is not stack'd, malloc'd or (recently) free'd
Received EINVAL as expected
|
|
From: <js...@ac...> - 2004-04-13 02:40:24
|
Nightly build on nemesis ( SuSE 9.0 ) started at 2004-04-13 03:50:00 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 152 tests, 13 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_creat (stderr) corecheck/tests/fdleak_dup (stderr) corecheck/tests/fdleak_dup2 (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_open (stderr) corecheck/tests/fdleak_pipe (stderr) corecheck/tests/fdleak_socketpair (stderr) helgrind/tests/inherit (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <to...@co...> - 2004-04-13 02:23:02
|
Nightly build on dunsmere ( Fedora Core 1 ) started at 2004-04-13 03:20:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow readline1: valgrind ./readline1 resolv: valgrind ./resolv seg_override: valgrind ./seg_override semlimit: valgrind ./semlimit sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 157 tests, 1 stderr failure, 1 stdout failure ================= helgrind/tests/inherit (stderr) none/tests/exec-sigmask (stdout) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-04-13 02:18:21
|
Nightly build on audi ( Red Hat 9 ) started at 2004-04-13 03:15:03 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow rcrl: valgrind ./rcrl readline1: valgrind ./readline1 resolv: valgrind ./resolv seg_override: valgrind ./seg_override semlimit: valgrind ./semlimit sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 157 tests, 1 stderr failure, 0 stdout failures ================= helgrind/tests/inherit (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-04-13 02:13:16
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2004-04-13 03:10:03 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow semlimit: valgrind ./semlimit sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 157 tests, 5 stderr failures, 0 stdout failures ================= helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) memcheck/tests/nanoleak (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-04-13 02:08:14
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2004-04-13 03:05:03 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 157 tests, 6 stderr failures, 1 stdout failure ================= helgrind/tests/inherit (stderr) memcheck/tests/badfree-2trace (stderr) memcheck/tests/badjump (stderr) memcheck/tests/brk (stderr) memcheck/tests/error_counts (stdout) memcheck/tests/new_nothrow (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-04-13 02:06:38
|
Nightly build on standard ( Red Hat 7.2 ) started at 2004-04-13 03:00:03 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow readline1: valgrind ./readline1 resolv: valgrind ./resolv seg_override: valgrind ./seg_override semlimit: valgrind ./semlimit sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 157 tests, 2 stderr failures, 0 stdout failures ================= helgrind/tests/inherit (stderr) memcheck/tests/badfree-2trace (stderr) make: *** [regtest] Error 1 |