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
(9) |
2
(16) |
|
3
(9) |
4
(8) |
5
(9) |
6
(10) |
7
(14) |
8
(10) |
9
(7) |
|
10
(14) |
11
(19) |
12
(22) |
13
(18) |
14
(20) |
15
(10) |
16
(12) |
|
17
(13) |
18
(7) |
19
(12) |
20
(13) |
21
(9) |
22
(12) |
23
(6) |
|
24
(5) |
25
(5) |
26
(6) |
27
(7) |
28
(9) |
29
(13) |
30
(21) |
|
From: Christoph B. <bar...@gm...> - 2006-09-05 18:56:13
|
Hi,
I could write a small test programm to reproduce the error I reported earlier
today.
The end of the trace is attached.
Here is the programm:
extern "C" {
#include <unistd.h>
}
int main() {
while (true) {
sleep(1);
}
}
1. Compile it with g++ -g <programmname>
2. Start valgrind:
valgrind --tool=callgrind --dump-instr=yes --collect-jumps=yes \
--simulate-cache=yes --instr-atstart=no --num-callers=32 --error-limit=no \
--time-stamp=yes --log-file=vg --trace-children=no --trace-syscalls=yes \
programmname
3. Start instrumentation: callgrind_control -i on <PID>
4. Dump: callgrind_control -d <PID>
5. Valgrind crashed.
The error does not occur on i386 machines only on x86_64 ones. Maybe a 64bit
problem.
If you need more information, just ask.
Greetings
Christoph
|
|
From: Nicholas N. <nj...@cs...> - 2006-09-05 08:13:26
|
On Tue, 5 Sep 2006, Bart Van Assche wrote: > - Does the PTT tool report false positives ? I got the impression from the email and the website it was a visualisation tool rather than an error-detection tool, but I could be wrong. Nick |
|
From: Bart V. A. <bar...@gm...> - 2006-09-05 04:56:14
|
Hello Tony,
Three questions:
- Is the paper about PTT available online ?
- Does the PTT tool report false positives ?
- You wrote about an impact on behavior. Can you explain this further ?
On 9/4/06, Tony Reix <ton...@bu...> wrote:
>
> Hello,
>
> Two years ago, we had studied Valgrind/Helgrind.
> Our conclusion was that it was not the perfect solution for helping
> these kinds of users: NPTL maintainers, and Linux customers support.
>
> If I remember well, Helgrind provides its own thread library. So it
> helps to find some kinds of bugs, but it cannot help in many complex
> cases related to NPTL details.
>
> So, we developed a tool named PTT (NPTL POSIX Trace Tool), aimed at
> providing a trace tool integrated into the NPTL library, with the lowest
> impact to performance and behavior as possible. It also provides some
> performance information related to contention.
> PTT is available at:
> http://sourceforge.net/projects/nptltracetool
> http://nptltracetool.sourceforge.net/
> (See OLS'05 for a paper describing PTT. Or read the up-to-date
> documentation on these sites).
> PTT has been built by several students working at Bull labs since 2004
> and is fully Open Source.
>
> PTT is now mature and is easy to use by end-users. It comes with
> documentation and has been ported/tested on ia32, x86_64, ppc (still
> bugs ...) and on medium/large multi-processor machines. It has been
> tested with OPTS and some other applications (Java, HPC).
>
> PTT could also be added to glibc by distributions: it generates an
> unmodified version of the glibc and a separate version of glibc enabling
> to generate traces. And one can move from one library to the other very
> easily.
>
> But the best solution would be to have it added to the glibc sources. it
> would be a matter of hours to add it.
> Discussions with glibc maintainers (Ulrich Drepper !!) have failed.
> These guys do not seem to add a debug tool inside the glibc ... Probably
> they do not know what "customer" and "support" mean.
>
> My opinion is that the number of multi-threaded applications will
> increase quickly now due to the availability of multi-core processors.
> Since multi-threading is so complex, tools are needed.
>
> So, if Valgrind developers are interested by PTT and would like either
> to add it to the Valgrind's Tool Suite or to mix it with the Helgrind
> tool, that would be very nice and very useful for the Linux community, I
> think.
> The main 4 values of PTT source code are:
> - its ability to integrated smoothly within glibc source code,
> - the trace points which required a lot of study to define,
> - the motor and buffer aimed at not slowing down applications,
> - the integration within NPTL.
>
> (The best solution is still to convince the glibc maintainers to accept
> PTT. But, after several tries, I have no more hope ... However, once
> SystemTap offers user-land hooks and is widely accepted by the
> community, I guess they will have to change their mind and to accept
> debug/trace tools.)
>
> Some people working in Linux RT are interested by an extension of PTT to
> RT, but I've had no news since months ...
>
|
|
From: Kailash S. <hs...@gm...> - 2006-09-05 04:36:51
|
Hi,
Firstly my apologies for digressing from the actual discussion on
Valgrind 3.3, but this pertains to both the regtest framework and the
new ports.
With regards to the NetBSD/i386 port of Valgrind, we have been making
quiet progress and have been doing so with the view of our code
finding its way back into the main tree sometime in the future. The
snapshot of valgrind our code is based on is somewhere between 3.1 and
3.2, as we have already merged code from -current two times before,
regular merges should not be a problem.
On Sunday 3rd Sept, we finally managed to get our port to debug
simple programs under NetBSD/i386. Memcheck is now able to detect most
leaks and read symbols correctly ( displaying proper stack traces).
Valgrind is able to run dynamic binaries under it in a proper manner.
The missing bits are the syscall wrapper implementations for many
syscalls.
In various places, such as mainly the syscall handling code, we have
had no choice but to put in 'dirty hacks'. For example, one major area
is around syscall handling, where NetBSD passes syscall arguments via
stack rather than registers. While most of this code is abstracted,
the abstraction assumes linux's pass-by-register semantics ( the
workings of syswrap-main.c using offsets in libvex_guest_offsets.h to
grab arguments out of VexGuestX86State ).
As we try to keep our codebase mergable , a lot of hacks have gone
into place without redoing this framework. In this case, we use
special 'offsets' here to query the stack in
{get/set}_shadow_regs_area in m_machine.c.
This sort of changes will also benifit other ports such as Darwin/i386
and FreeBSD port.
Currently, we are in the process of making the regtest framework work
correctly, as there are quite a few linuxisms in the code. This will
be crucial for us in determining exactly where further porting work is
required, as correctness is most important.
There are also other minor niggles in our codebase around Makefiles
especially, which require to be cleaned up before we can put a tarball
of a mostly-working valgrind for netbsd up. ( Dependancy on GNU Sed,
some symlink issues in the .in_place/ dir etc).
Our intention was to report our progress after the regtest framework
was fixed as that would give us some concrete statistics to show and
after fixing the minor niggles, however this e-mail seemed to be a
good avenue to discuss the progress of this new port.
The project page is at http://vg4nbsd.berlios.de
We would be more than happy to help in getting the regtest framework
in shape, and also maybe a side discussion on abstracting some
frameworks a bit more to help the non linux port would be of good
benifit, and help us share code as much as we can, among new ports.
Regards,
Kailash
>
> New ports for 3.3.0
> ~~~~~~~~~~~~~~~~~~~
> This year there has been quiet but steady work towards porting V away
> from Linux. There are now ports to FreeBSD, MacOSX and AIX5 in
> various states of progress, and it seems likely that some of those
> will appear in the mainline tree at some point.
>
> I am expecting that our existing porting infrastructure will continue
> to be refined and extended so that these ports can be accommodated
> without majorly intrusive changes in the majority of the code base.
> So far with the Linux ports to x86,amd64,ppc32,ppc64, the
> target-specific stuff has been isolated into a relatively few places
> (eg, m_syswrap, m_sigframe, m_syscall, VEX), leaving the rest of the
> system fairly untouched, and I am hoping this can be continued.
>
> The regression test infrastructure has proven invaluable in making V
> as reliable as it is. However, even with Linux it is too sensitive to
> changes in stack backtraces and address space layouts, and as a result
> causes tests to fail when really they should succeed. With new ports
> on the horizon this problem is about to get much worse. If anyone is
> motivated to overhaul this unglamorous but critical subsystem, that
> would be much appreciated.
|
|
From: Tom H. <to...@co...> - 2006-09-05 02:45:46
|
Nightly build on dunsmere ( athlon, Fedora Core 5 ) started at 2006-09-05 03:30:06 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 239 tests, 5 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2006-09-05 02:25:24
|
Nightly build on dellow ( x86_64, Fedora Core 5 ) started at 2006-09-05 03:10:03 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 266 tests, 4 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/mempool (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2006-09-05 02:24:33
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2006-09-05 03:15:02 BST Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Last 20 lines of verbose log follow echo /tmp/ccEC7kUg.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccEC7kUg.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccEC7kUg.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccEC7kUg.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccEC7kUg.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccEC7kUg.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccEC7kUg.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccEC7kUg.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 rm insn_mmx.c insn_sse2.c insn_fpu.c insn_mmxext.c insn_sse.c insn_sse3.c insn_cmov.c insn_basic.c make[5]: Leaving directory `/tmp/valgrind.27153/valgrind/none/tests/x86' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.27153/valgrind/none/tests/x86' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.27153/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.27153/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.27153/valgrind' make: *** [check] Error 2 ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Last 20 lines of verbose log follow echo /tmp/ccxPV7y2.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccxPV7y2.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccxPV7y2.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccxPV7y2.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccxPV7y2.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccxPV7y2.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccxPV7y2.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccxPV7y2.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 rm insn_mmx.c insn_sse2.c insn_fpu.c insn_mmxext.c insn_sse.c insn_sse3.c insn_cmov.c insn_basic.c make[5]: Leaving directory `/tmp/valgrind.27153/valgrind/none/tests/x86' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.27153/valgrind/none/tests/x86' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.27153/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.27153/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.27153/valgrind' make: *** [check] Error 2 ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Tue Sep 5 03:19:47 2006 --- new.short Tue Sep 5 03:24:26 2006 *************** *** 7,16 **** Last 20 lines of verbose log follow echo ! /tmp/ccxPV7y2.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccxPV7y2.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccxPV7y2.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccxPV7y2.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccxPV7y2.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccxPV7y2.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccxPV7y2.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccxPV7y2.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 --- 7,16 ---- Last 20 lines of verbose log follow echo ! /tmp/ccEC7kUg.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccEC7kUg.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccEC7kUg.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccEC7kUg.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccEC7kUg.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccEC7kUg.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccEC7kUg.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccEC7kUg.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 |
|
From: Tom H. <th...@cy...> - 2006-09-05 02:19:31
|
Nightly build on lloyd ( x86_64, Fedora Core 3 ) started at 2006-09-05 03:05:04 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 266 tests, 6 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/leakotron (stdout) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2006-09-05 02:14:52
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2006-09-05 03:00:02 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 268 tests, 6 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/mempool (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |