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
(11) |
2
(13) |
3
(7) |
|
4
(9) |
5
(23) |
6
(19) |
7
(18) |
8
(2) |
9
(7) |
10
(21) |
|
11
(13) |
12
|
13
(8) |
14
(17) |
15
(19) |
16
(25) |
17
(43) |
|
18
(22) |
19
(12) |
20
(19) |
21
(12) |
22
(9) |
23
(12) |
24
(5) |
|
25
(16) |
26
(25) |
27
(24) |
28
(19) |
29
(26) |
30
(25) |
31
(6) |
|
From: Julian S. <js...@ac...> - 2004-07-20 23:49:34
|
CVS commit by jseward:
Fix scary bug causing mis-identification of SSE stores vs loads.
M +2 -2 vg_to_ucode.c 1.143
--- valgrind/coregrind/vg_to_ucode.c #1.142:1.143
@@ -4883,5 +4883,5 @@ static Addr disInstr ( UCodeBlock* cb, A
//(insn[1] == 0x10 || insn[1] == 0x11)
// ? "movups" : "movaps";
- Bool store = False; //insn[1] == 0x29 || insn[1] == 11;
+ Bool store = False; //insn[1] == 0x29 || insn[1] == 0x11;
eip = dis_SSE3_load_store_or_mov
( cb, sorb, eip+2, 16, store, name,
@@ -4904,5 +4904,5 @@ static Addr disInstr ( UCodeBlock* cb, A
UChar* name = (insn[1] == 0x10 || insn[1] == 0x11)
? "movups" : "movaps";
- Bool store = insn[1] == 0x29 || insn[1] == 11;
+ Bool store = insn[1] == 0x29 || insn[1] == 0x11;
vg_assert(sz == 2 || sz == 4);
if (sz == 4) {
|
|
From: Jeremy F. <je...@go...> - 2004-07-20 23:36:16
|
On Tue, 2004-07-20 at 12:39 +0100, Nicholas Nethercote wrote: > What are aa's virtual memory patches? They are almost certainly causing > the problem. Not sure they would be - they're probably more to do with swapping/ paging policy than address space layout, but I'm not sure what Andrea's putting in there these days. > Can you send us what you see when you run "vim /proc/self/maps" (or the > contents of any smallish /proc/<pid>/maps file)? That would be > instructive. Thanks. Also "readelf -lh /bin/ls" would be interesting too. J |
|
From: Jeremy F. <je...@go...> - 2004-07-20 23:33:07
|
On Tue, 2004-07-20 at 12:51 +0100, Nicholas Nethercote wrote:
> [CC'ing vg-dev]
>
> On Tue, 20 Jul 2004, Julian Seward wrote:
>
> >
> > Hi. I added a new redirection entry (fruitlessly, but that's
> > not the point)
> >
> > VG_(add_redirect_sym)("file:/lib/ld-2.3.3.so", "strchr",
> > "*vgpreload_memcheck.so*", "strchr");
>
> I'm not sure what is the difference between the redirection table and the
> LIBALIAS stuff. Someone wrote a patch for one of the bugs in bugzilla
> where they replaced all of the redirection table with LIBALIAS usage, I
> think.
>
> > at the end of VG_(setup_code_redirect_table), and got this:
> >
> > ==20560== REDIRECT soname:libc.so.6(__GI___res_state) to
> > soname:libpthread.so.0(__res_state)
> > ==20560== REDIRECT soname:libc.so.6(__res_state) to soname:libpthread.so.0
> > (__res_state)
> > ==20560== REDIRECT soname:libc.so.6(stpcpy) to *vgpreload_memcheck.so*(stpcpy)
> > ==20560== REDIRECT soname:libc.so.6(strnlen) to
> > *vgpreload_memcheck.so*(strnlen)
> > ==20560== REDIRECT soname:ld-linux.so.2(stpcpy) to
> > *vgpreload_memcheck.so*(stpcpy)
> > ==20560== REDIRECT soname:ld-linux.so.2(strchr) to
> > *vgpreload_memcheck.so*(strchr)
> > ==20560== REDIRECT file:/lib/ld-2.3.3.so(strchr) to
> > *vgpreload_memcheck.so*(strchr)
> > ==20560==
> > ==20560== Reading syms
> > from /home/sewardj/VgHEAD/valgrind/Inst/lib/valgrind/vg_inject.so
> > (0x1B8FB000)
> > ==20560== Conditional jump or move depends on uninitialised value(s)
> > ==20560== at 0x1B8F4126: strchr (in /lib/ld-2.3.3.so)
> > ==20560== Reading syms
> > from /home/sewardj/VgHEAD/valgrind/Inst/lib/valgrind/vgpreload_memcheck.so
> > (0x1B8FE000)
> >
> > valgrind: vg_skiplist.c:377 (vgPlain_SkipList_Insert): Assertion `n == ((void
> > *)0) || (l->cmp)(key_of_node(l, n), k) != 0' failed.
> > ==20560== at 0xB002BF80: vgPlain_skin_assert_fail (vg_mylibc.c:1169)
> > ==20560== by 0xB002BF7F: assert_fail (vg_mylibc.c:1165)
> > ==20560== by 0xB002BFBD: vgPlain_core_assert_fail (vg_mylibc.c:1176)
> > ==20560== by 0xB0039498: vgPlain_SkipList_Insert (vg_skiplist.c:381)
> >
> > Wow! What did I do wrong?
I think it's trying to tell you, in its own clumsy way, that you've got
a duplicate entry in the list. It doesn't support duplicates.
> >
> > Can I ask .. what is a skiplist? Is it like a FiniteMap in Haskell
> > in the sense that it maps arbitrary keys (with ordering) to arbitrary
> > values?
>
> Yes. Read the comment at the top of coregrind/vg_skiplist.c; it explains
> how they work in general, and also the obscure structure layout that is
> used in the implementation to allow arbitrary length keys and values.
>
> > Am trying to figure out why SuSE often gives me this at startup
> >
> > ==20560== Conditional jump or move depends on uninitialised value(s)
> > ==20560== at 0x1B8F4126: strchr (in /lib/ld-2.3.3.so)
> > (no further frames, alas)
> >
> > It's somehow env dependent, and I've chased that a bit, with no success.
> > In any case, I'd prefer a solution that didn't depend subtly on
> > environment variables. I wanted to be sure this strchr call was being
> > redirected, which I think it is. That probably means my only option
> > is to suppress this, but having only a single frame to match on is
> > not good. Umm. Ideas?
>
> Maybe LIBALIAS instead of the redirection table for strchr()? I don't
> know, I don't understand the redirection stuff at all.
There's a few things going on here. You can explicitly register a
redirect with VG_(add_redirect_sym)(). This is the base mechanism, but
I don't like it much because it forces you to scatter special knowledge
into too many places.
The preferred mechanism is the implicit one, where a shared object (ie,
Tool, or something else), magically registers its own redirections.
Unfortunately this has the appearance of being a bit magical, because
this stuff is encoded into special symbols with special names (courtesy
of Robert). It's a bit ugly, but its nicer than the alternatives which
were 1) more complex and 2) ELF-specific.
LIBALIAS is the macro which implements this for vg_replace_malloc.c, but
the real meat is in VG_INTERCEPT/VG_INTERCEPT_ALIAS() macros and the
genintercepts.pl script. These generate aliased symbols with the magic
mangling which is used by the symtable parser to automatically install
the intercepts.
The upshot is that when a client loads a library which happens to be
provided by Valgrind, and that library wants to intercept some symbols
from other client-side libraries, the interceptions are put in place
when the library's symtab is loaded.
The interceptions act like "come-froms" - they specify a to and from
address, either numerically or symbolically. When both from and to
addresses have been resolved into real addresses, the interception
becomes active, which means that when we start executing the BB at
"from", the translator reads code from "to" instead.
Unresolved intercepts can hang around forever, if they're specified to
match libraries and/or symbols which are never loaded.
Also, a given interception pattern can only become resolved once, even
if it matches multiple symbols (ie, matching "malloc" in all libraries
will resolve to the first malloc it finds). This is probably a bug, but
it does encourage more precise matching conditions which is not a bad
thing.
J
|
|
From: Julian S. <js...@ac...> - 2004-07-20 22:42:49
|
CVS commit by jseward:
Remove duplicate suppressions for SuSE 9.0 (section appeared twice)
and add one for SuSE 9.1.
M +3 -13 glibc-2.3.supp 1.15
--- valgrind/glibc-2.3.supp #1.14:1.15
@@ -228,18 +228,8 @@
##----------------------------------------------------------------------##
-## SuSE 9 after FV changes (post 2.1.0)
-
+## SuSE 9.1 with post 2.1.2
{
- strlen/_dl_init_paths/dl_main/_dl_sysdep_start(Cond)
+ Ugly strchr error in /lib/ld-2.3.3.so
Memcheck:Cond
- fun:strlen
- fun:_dl_init_paths
- fun:dl_main
- fun:_dl_sysdep_start
-}
-
-{
- Ugly strchr error in /lib/ld-2.3.2.so
- Memcheck:Cond
- obj:/lib/ld-2.3.2.so
+ obj:/lib/ld-2.3.3.so
}
|
|
From: Nicholas N. <nj...@ca...> - 2004-07-20 14:19:41
|
CVS commit by nethercote: typo M +1 -1 AUTHORS 1.8 --- valgrind/AUTHORS #1.7:1.8 @@ -13,5 +13,5 @@ Tom Hughes, th...@cy..., did a vast number of bug fixes, and -helped out with support for more recent Linux/glibc versions". +helped out with support for more recent Linux/glibc versions. Robert Walsh, rj...@du..., added file descriptor leakage |
|
From: Nicholas N. <nj...@ca...> - 2004-07-20 13:29:08
|
CVS commit by nethercote: comment typo M +1 -1 cg_main.c 1.73 --- valgrind/cachegrind/cg_main.c #1.72:1.73 @@ -119,5 +119,5 @@ static fileCC *CC_table[N_FILE_ENTRIES]; // - table(BB_start_addr, list(instr_info)) // - For each BB, each instr_info in the list holds info about the -// instruction (instr_size, instr_addr, etc), plue a pointer to its line +// instruction (instr_size, instr_addr, etc), plus a pointer to its line // CC. This node is what's passed to the simulation function. // - When BBs are discarded the relevant list(instr_details) is freed. |
|
From: Julian S. <js...@ac...> - 2004-07-20 12:25:02
|
CVS commit by jseward:
Fix extremely obscure bug in xadd picked up by QEMU's test suite. The
(almost useless) instruction "xadd %reg,%reg" gave the wrong answer
due to a subtlety of the order in which the destination registers are
PUTted to.
M +1 -1 vg_to_ucode.c 1.142
--- valgrind/coregrind/vg_to_ucode.c #1.141:1.142
@@ -3138,6 +3138,6 @@ Addr dis_xadd_G_E ( UCodeBlock* cb,
uInstr2(cb, ADD, sz, TempReg, tmpd, TempReg, tmpt);
setFlagsFromUOpcode(cb, ADD);
- uInstr2(cb, PUT, sz, TempReg, tmpt, ArchReg, eregOfRM(rm));
uInstr2(cb, PUT, sz, TempReg, tmpd, ArchReg, gregOfRM(rm));
+ uInstr2(cb, PUT, sz, TempReg, tmpt, ArchReg, eregOfRM(rm));
DIP("xadd%c %s, %s\n",
nameISize(sz), nameIReg(sz,gregOfRM(rm)), nameIReg(sz,eregOfRM(rm)));
|
|
From: Nicholas N. <nj...@ca...> - 2004-07-20 11:52:54
|
CVS commit by nethercote:
Future-proof
M +1 -1 related.html 1.17
--- devel-home/valgrind/related.html #1.16:1.17
@@ -26,5 +26,5 @@
can profile shared libraries.
<p>
-<li>Nick Nethercote has three experimental tools: a memory access tracer, a
+<li>Nick Nethercote has several experimental tools: a memory access tracer, a
heap profiler, a pointer misuse-checker, and a signal-handler checker. He
also has an experimental Valgrind distribution that has an interactive
|
|
From: Nicholas N. <nj...@ca...> - 2004-07-20 11:52:13
|
[CC'ing vg-dev]
On Tue, 20 Jul 2004, Julian Seward wrote:
>
> Hi. I added a new redirection entry (fruitlessly, but that's
> not the point)
>
> VG_(add_redirect_sym)("file:/lib/ld-2.3.3.so", "strchr",
> "*vgpreload_memcheck.so*", "strchr");
I'm not sure what is the difference between the redirection table and the
LIBALIAS stuff. Someone wrote a patch for one of the bugs in bugzilla
where they replaced all of the redirection table with LIBALIAS usage, I
think.
> at the end of VG_(setup_code_redirect_table), and got this:
>
> ==20560== REDIRECT soname:libc.so.6(__GI___res_state) to
> soname:libpthread.so.0(__res_state)
> ==20560== REDIRECT soname:libc.so.6(__res_state) to soname:libpthread.so.0
> (__res_state)
> ==20560== REDIRECT soname:libc.so.6(stpcpy) to *vgpreload_memcheck.so*(stpcpy)
> ==20560== REDIRECT soname:libc.so.6(strnlen) to
> *vgpreload_memcheck.so*(strnlen)
> ==20560== REDIRECT soname:ld-linux.so.2(stpcpy) to
> *vgpreload_memcheck.so*(stpcpy)
> ==20560== REDIRECT soname:ld-linux.so.2(strchr) to
> *vgpreload_memcheck.so*(strchr)
> ==20560== REDIRECT file:/lib/ld-2.3.3.so(strchr) to
> *vgpreload_memcheck.so*(strchr)
> ==20560==
> ==20560== Reading syms
> from /home/sewardj/VgHEAD/valgrind/Inst/lib/valgrind/vg_inject.so
> (0x1B8FB000)
> ==20560== Conditional jump or move depends on uninitialised value(s)
> ==20560== at 0x1B8F4126: strchr (in /lib/ld-2.3.3.so)
> ==20560== Reading syms
> from /home/sewardj/VgHEAD/valgrind/Inst/lib/valgrind/vgpreload_memcheck.so
> (0x1B8FE000)
>
> valgrind: vg_skiplist.c:377 (vgPlain_SkipList_Insert): Assertion `n == ((void
> *)0) || (l->cmp)(key_of_node(l, n), k) != 0' failed.
> ==20560== at 0xB002BF80: vgPlain_skin_assert_fail (vg_mylibc.c:1169)
> ==20560== by 0xB002BF7F: assert_fail (vg_mylibc.c:1165)
> ==20560== by 0xB002BFBD: vgPlain_core_assert_fail (vg_mylibc.c:1176)
> ==20560== by 0xB0039498: vgPlain_SkipList_Insert (vg_skiplist.c:381)
>
> Wow! What did I do wrong?
>
> Can I ask .. what is a skiplist? Is it like a FiniteMap in Haskell
> in the sense that it maps arbitrary keys (with ordering) to arbitrary
> values?
Yes. Read the comment at the top of coregrind/vg_skiplist.c; it explains
how they work in general, and also the obscure structure layout that is
used in the implementation to allow arbitrary length keys and values.
> Am trying to figure out why SuSE often gives me this at startup
>
> ==20560== Conditional jump or move depends on uninitialised value(s)
> ==20560== at 0x1B8F4126: strchr (in /lib/ld-2.3.3.so)
> (no further frames, alas)
>
> It's somehow env dependent, and I've chased that a bit, with no success.
> In any case, I'd prefer a solution that didn't depend subtly on
> environment variables. I wanted to be sure this strchr call was being
> redirected, which I think it is. That probably means my only option
> is to suppress this, but having only a single frame to match on is
> not good. Umm. Ideas?
Maybe LIBALIAS instead of the redirection table for strchr()? I don't
know, I don't understand the redirection stuff at all.
N
|
|
From: Julian S. <js...@ac...> - 2004-07-20 11:42:31
|
CVS commit by jseward:
gcc sometimes generates "sbbl %reg,%reg" to convert the carry flag
into 0 or -1 in reg. This has no actual dependency on reg, but
memcheck can't see that, and so will yelp if reg contains garbage. A
simple fix is to put zero into reg before we start, zapping any
undefinedness it might otherwise contain.
Hopefully fixes #84978 (unconfirmed)
M +14 -0 vg_to_ucode.c 1.141
--- valgrind/coregrind/vg_to_ucode.c #1.140:1.141
@@ -1115,4 +1115,18 @@ Addr dis_op2_G_E ( UCodeBlock* cb,
}
+ /* gcc sometimes generates "sbbl %reg,%reg" to convert the carry
+ flag into 0 or -1 in reg. This has no actual dependency on
+ reg, but memcheck can't see that, and so will yelp if reg
+ contains garbage. A simple fix is to put zero into reg
+ before we start, zapping any undefinedness it might otherwise
+ contain.
+ */
+ if (opc == SBB && gregOfRM(rm) == eregOfRM(rm)) {
+ Int tzero = newTemp(cb);
+ uInstr2(cb, MOV, size, Literal, 0, TempReg, tzero);
+ uLiteral(cb, 0);
+ uInstr2(cb, PUT, size, TempReg, tzero, ArchReg, eregOfRM(rm));
+ }
+
uInstr2(cb, GET, size, ArchReg, eregOfRM(rm), TempReg, tmp);
|
|
From: Nicholas N. <nj...@ca...> - 2004-07-20 11:39:32
|
[cc'ing to valgrind-developers list] On Mon, 19 Jul 2004, Kingsley G. Morse Jr. wrote: > Here's a bug report. > > Immediately after installing version 2.1.1-4 of > debian's valgrind package, I typed: > > $ valgrind ls -l > > and got the error message: > > Executable is mapped outside of range 0x80d3000-0x3ffff000 > failed to load /usr/lib/valgrind/stage2: Cannot allocate memory > > Other info: > > $ uname -a > 2.4.19-aa1 (2.4.19 + aa's virtual memory patches) What are aa's virtual memory patches? They are almost certainly causing the problem. Can you send us what you see when you run "vim /proc/self/maps" (or the contents of any smallish /proc/<pid>/maps file)? That would be instructive. Thanks. N |
|
From: Nicholas N. <nj...@ca...> - 2004-07-20 11:34:15
|
CVS commit by nethercote: Clarify bug-submission procedure. M +32 -19 bugs.html 1.13 --- devel-home/valgrind/bugs.html #1.12:1.13 @@ -5,19 +5,36 @@ ?> -Before you report a bug, please consult the -<a HREF="faq.html">Frequently Asked Questions</a>. It -contains workarounds for more or less all the failure conditions for -which we know a workaround. This includes a large fraction of the -failures people seem to encounter in practice. -<p> -If that fails, please file a report using our -<a href="http://bugs.kde.org/enter_valgrind_bug.cgi">Bugzilla page</a>. -Patches for bugs are particularly welcome. -<p> -If you have trouble with Bugzilla, or for some reason you don't think -Bugzilla is appropriate for your report (although it probably is), -contact the valgrind-users <a href="lists.html">mailing list</a>. We -try to respond to most bug reports, but if we don't, it doesn't mean we -are ignoring you; it may well be that the bug has been reported before. +If you think you've found a Valgrind bug, please take the following steps. +<ul> +<li>Before you report a bug, please consult the + <a HREF="faq.html">Frequently Asked Questions</a>. It contains + more or less all the failure conditions for which we know a + workaround. This includes a large fraction of the failures people + seem to encounter in practice. + <p> + +<li>If that fails, please file a report using our + <a href="http://bugs.kde.org/enter_valgrind_bug.cgi">Bugzilla page</a>. + Please check if the bug has already been reported. Patches for bugs + are particularly welcome. All Bugzilla reports are read by the + developers. If you get no response, we are not ignoring the bug; + we probably just don't know how to fix it satisfactorily yet. Some + bugs are fixed immediately, some take months, but if they are in + Bugzilla, they won't be forgotten, and other people can search for + them. + <p> + +<li>If you are not sure if what you are seeing is actually a bug, you + could contact the valgrind-users <a href="lists.html">mailing + list</a>. The developers all read the list, but there is no + guarantee you will get a useful response. Often we will ask you to + put the problem into Bugzilla anyway. + <p> + +<li>Please do not email developers individually; this is the + <em>least effective</em> way of getting a bug fixed. + <p> +</ul> + <p> When you report a bug, <em>please</em> give the following information: @@ -32,8 +49,4 @@ <p> -Filing bug reports in bugzilla is the most effective way of getting -the developers to look at it. Mailing the developers individually -your <em>least effective</em> solution. Please use bugzilla! - <?php include "footer.inc" |
|
From: Nicholas N. <nj...@ca...> - 2004-07-20 11:32:26
|
CVS commit by nethercote:
Update
M +4 -4 related.html 1.16
--- devel-home/valgrind/related.html #1.15:1.16
@@ -26,8 +26,8 @@
can profile shared libraries.
<p>
-<li>Nick Nethercote has three experimental tools: a heap profiler, a
- pointer misuse-checker, and a signal-handler checker. He also has
- an experimental Valgrind distribution that has an interactive command
- line. They are all available
+<li>Nick Nethercote has three experimental tools: a memory access tracer, a
+ heap profiler, a pointer misuse-checker, and a signal-handler checker. He
+ also has an experimental Valgrind distribution that has an interactive
+ command line. They are all available
<a href="http://www.cl.cam.ac.uk/~njn25/valgrind.html">here</a>.
<p>
|
|
From: <js...@ac...> - 2004-07-20 02:57:45
|
Nightly build on nemesis ( SuSE 9.1 ) started at 2004-07-20 03:50:00 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow memcheck/tests/overlap (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/pushfpopf (stderr) memcheck/tests/realloc1 (stderr) memcheck/tests/realloc2 (stderr) memcheck/tests/realloc3 (stderr) memcheck/tests/sigaltstack (stderr) memcheck/tests/signal2 (stderr) memcheck/tests/supp1 (stderr) memcheck/tests/supp2 (stderr) memcheck/tests/suppfree (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/toobig-allocs (stderr) memcheck/tests/trivialleak (stderr) memcheck/tests/tronical (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <to...@co...> - 2004-07-20 02:25:10
|
Nightly build on dunsmere ( Fedora Core 2 ) started at 2004-07-20 03:20:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow 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 ---------------------------------------- == 173 tests, 7 stderr failures, 1 stdout failure ================= corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_socketpair (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/writev (stderr) none/tests/exec-sigmask (stdout) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-07-20 02:19:42
|
Nightly build on audi ( Red Hat 9 ) started at 2004-07-20 03:15:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow 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 ---------------------------------------- == 173 tests, 8 stderr failures, 0 stdout failures ================= corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_socketpair (stderr) corecheck/tests/pth_cancel2 (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-07-20 02:13:19
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2004-07-20 03:10:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow sem: valgrind ./sem 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 ---------------------------------------- == 173 tests, 4 stderr failures, 0 stdout failures ================= helgrind/tests/deadlock (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-07-20 02:08:10
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2004-07-20 03:05:01 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 ---------------------------------------- == 173 tests, 6 stderr failures, 1 stdout failure ================= addrcheck/tests/toobig-allocs (stderr) memcheck/tests/badjump (stderr) memcheck/tests/brk (stderr) memcheck/tests/error_counts (stdout) memcheck/tests/new_nothrow (stderr) memcheck/tests/toobig-allocs (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-07-20 02:07:44
|
Nightly build on standard ( Red Hat 7.2 ) started at 2004-07-20 03:00: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 rlimit_nofile: valgrind ./rlimit_nofile seg_override: valgrind ./seg_override sem: valgrind ./sem 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 ---------------------------------------- == 173 tests, 0 stderr failures, 0 stdout failures ================= |