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
(4) |
|
2
(5) |
3
(3) |
4
(3) |
5
(7) |
6
(7) |
7
(9) |
8
(10) |
|
9
(12) |
10
(26) |
11
(9) |
12
(6) |
13
(7) |
14
(15) |
15
(25) |
|
16
(20) |
17
(32) |
18
(11) |
19
(19) |
20
(22) |
21
(6) |
22
(8) |
|
23
(16) |
24
(25) |
25
(11) |
26
(16) |
27
(12) |
28
(15) |
29
(11) |
|
30
(5) |
31
(8) |
|
|
|
|
|
|
From: Jeremy F. <je...@go...> - 2005-01-07 07:59:41
|
On Thu, 2005-01-06 at 21:06 -0800, Jeremy Fitzhardinge wrote: > The basic idea came from Eric Estievenart in a discussion earlier this > year. Erm, last year. I should have proofread the draft? J |
|
From: Jeremy F. <je...@go...> - 2005-01-07 05:06:31
|
Over the hols I decided it would be fun to rewrite Valgrind's syscall/threading stuff again. The basic idea came from Eric Estievenart in a discussion earlier this year. Rather than having the "main thread" with a bunch of proxy LWP threads to deal with signals and so on, every app-level thread gets its own kernel-level thread, so that the thread/process structure of the program is identical inside and outside Valgrind. The thread execution is still serialized, so that only one client thread can run at once. In addition to this change, I killed Valgrind's pthread library. Instead, Valgrind supports the clone syscall, plus all the other threading-related syscalls (futex, set_thread_area, set_pid_address, gettid, tkill, tgkill, etc). This allows the system threads library to work under Valgrind. I don't support full general clone, but it does work with both NPTL and LinuxThreads, as well as using clone() to do fork and vfork (vfork is mapped to fork, as before). The chief advantage of these changes is simplicity. Valgrind now implements a much thinner layer over the kernel, and doesn't try to second-guess the kernel's behaviour. This means, for example, that there's no more "mode switch" for 2.4 and 2.6-style kernels - they both work equally well, despite having significant differences in thread support and signal handling. vg_libthread has been becoming increasingly troublesome, and is basically completely broken (for example, when using a multithreaded program with a Tool which doesn't replace malloc, there was no locking to protect the libc malloc from concurrent access). Any system thread library should work now, including home-rolled ones (with a bit of tweaking). All this has resulted in Valgrind shrinking by about 6600 lines of code, including all of vg_proxylwp.c, vg_libpthread.c and about 2200 lines from vg_scheduler.c - some of the hairest, trickiest and error-prone code in the codebase. There are some disadvantages though. In losing vg_libpthread, Valgrind has a much more limited understanding of what's going on inside a threaded program. It can see threads starting and exiting, but that's about it. It can't tell when a mutex has been locked or unlocked; it can't even really tell which threads are waiting for another to exit. This means that all the core pthreads error reporting has gone, and helgrind is basically useless. We can probably glean a bit more information than we currently are, but not a lot. Probably the best way to fix this is to work with the glibc people to try to build some Valgrind support into glibc, and/or take advantage of the existing hooks which gdb uses. I haven't investigated this at all yet. The patch as it currently stands works well for me. I've mostly tested it on my FC2/2.6.10 system, using both LinuxThreads and NPTL threads libraries. The regression tests mostly pass, and I can run OOo and firefox under nulgrind and memcheck. Other changes: I took advantage of the general upheaval to try to isolate more of the OS/arch/platform dependent code. vg_scheduler is now (almost?) completely free of OS-specific knowledge: it just assumes there are things called threads, they can be running or blocked, interrupted by async events, and eventually they exit, but all the details are left up to other OS-specific code. Also, one widespread change was renaming get_current_tid to get_VCPU_tid. The old name was too ambiguous in the context of the new threading, and the new name better describes what it actually does. So, the patch is at http://www.goop.org/~jeremy/valgrind/new-threading.patch.bz2 If people could try it out and see if it basically works for them, I'll check it in the next few days. In particular, I'd like it if the people considering porting Valgrind to other OS's could have a look and see how these changes affect them. TODO: * Examine all the regression test failures, and work out what's going on. Some are trivial (thread IDs have changed), some are irrelevent (pthreads error checking) and some are strange (particularly the programs which work when run standalone, but fail when run in harness). * Examine all the new errors popping out of libpthread, and work out what's going on. Some need suppressing, but some might be real bugs (in either Valgrind or libpthread). * Test on more machines. I did a brief test on an RH7.3/2.4 machine, and it nearly worked. It seems that its libpthread does something interesting with segment registers which isn't supported by Valgrind. I think it wants LDT entries shared between threads. It should be possible to get 2.4 (or even 2.2 if we wanted to) systems supported without too much programming effort. * Try to recover the lost pthreads functionality. All that pthreads API usage checking was useful, and it uncovered a lot of bugs. We should do as much as we can to try to work out what the client is doing using available evidence, and also look into getting help from the threads library. The tricky part will be making sure this doesn't end up being another track-the-version-of-the-day maintenance headache. * I implemented the thread-serializing run_sema with both a futex and a pipe-based token-passing scheme. The futex code is more efficient, but the pipe scheme works everywhere, so that's what is enabled by default. Switching is a compile-time option, but it could be done at runtime. WOULD LIKE TO DO (comments?): * I noticed that ThreadState * and ThreadId are synonyms, and there's a lot of redundant code for converting between the two. I would like to drop ThreadId, and just use ThreadState * everywhere. Outside the core, it would just be an opaque pointer. * As a corollary, I would also like to get rid of the VG_(threads) array and dynamically allocate ThreadState structures, and get rid of the hard upper limit of VG_N_THREADS. The only significant bad effect this might have is on Tools which maintain their own arrays for storing per-thread information (like helgrind). We can just change them to add a per-thread-info-for-Tools field to ThreadState. J |
|
From: <js...@ac...> - 2005-01-07 03:59:39
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2005-01-07 03:50:01 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 188 tests, 5 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_fcntl (stderr) memcheck/tests/scalar (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <to...@co...> - 2005-01-07 03:24:21
|
Nightly build on dunsmere ( Fedora Core 3 ) started at 2005-01-07 03:20:04 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int sh: line 1: 31496 Illegal instruction VALGRINDLIB=/tmp/valgrind.15455/valgrind/.in_place /tmp/valgrind.15455/valgrind/./coregrind/valgrind --tool=none ./int >int.stdout.out 2>int.stderr.out rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 193 tests, 3 stderr failures, 1 stdout failure ================= memcheck/tests/scalar (stderr) memcheck/tests/scalar_supp (stderr) memcheck/tests/vgtest_ume (stderr) none/tests/exec-sigmask (stdout) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-01-07 03:20:21
|
Nightly build on audi ( Red Hat 9 ) started at 2005-01-07 03:15:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 193 tests, 12 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) memcheck/tests/badpoll (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/execve2 (stderr) memcheck/tests/scalar (stderr) memcheck/tests/scalar_exit_group (stderr) memcheck/tests/scalar_supp (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-01-07 03:13:53
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2005-01-07 03:10:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_cmov: valgrind ./insn_cmov insn_fpu: valgrind ./insn_fpu insn_mmx: valgrind ./insn_mmx insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 193 tests, 1 stderr failure, 0 stdout failures ================= memcheck/tests/scalar (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-01-07 03:08:36
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2005-01-07 03:05:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 193 tests, 3 stderr failures, 1 stdout failure ================= memcheck/tests/scalar (stderr) memcheck/tests/vgtest_ume (stderr) none/tests/susphello (stdout) none/tests/susphello (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-01-07 03:04:00
|
Nightly build on standard ( Red Hat 7.2 ) started at 2005-01-07 03:00:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 193 tests, 3 stderr failures, 1 stdout failure ================= memcheck/tests/scalar (stderr) memcheck/tests/vgtest_ume (stderr) none/tests/susphello (stdout) none/tests/susphello (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-01-07 00:17:46
|
In message <200...@we...>
Naveen Kumar <g_n...@ya...> wrote:
> Ok so I finally got valgrind to compile on
> solaris-x86.
> when I run the executable this is what I get
>
> bash-2.03$ ~/my_local/bin/valgrind
> Executable range b0000000-b01df900 is outside the
> acceptable range 80a3000-8047000
> valgrind: failed to load
> /export/home/msat/my_local//lib/valgrind/stage2: Not
> enough space
>
> I suppose I have to tweak the KICKSTART_BASE and some
> other size parameters only I'm not sure how to go
> about finding out what values I should put in here.
Your problem is that valgrind uses the initial stack pointer
to find the top of memory and derives the 8047000 limit from
that value.
I believe that Solaris puts the stack under the executable
rather than at the top of memory so you will need some other
way to find the top of the user address space.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|