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
(11) |
3
(21) |
4
(15) |
5
(10) |
|
6
(7) |
7
(7) |
8
(5) |
9
(7) |
10
(5) |
11
(1) |
12
(21) |
|
13
(8) |
14
(17) |
15
(6) |
16
(10) |
17
(7) |
18
(6) |
19
(15) |
|
20
(12) |
21
(16) |
22
(25) |
23
(14) |
24
(10) |
25
(7) |
26
(6) |
|
27
(34) |
28
(13) |
29
(10) |
30
(8) |
|
|
|
|
From: Nicholas N. <nj...@ca...> - 2004-06-23 21:35:28
|
On Wed, 23 Jun 2004, Bob Friesenhahn wrote: > I have a GUI program (Gtk-based with one background thread) that I am > trying to run under valgrind. When running under valgrind, the > program sometimes locks up solid so that only 'kill -9' terminates the > process. Valgrind does not print any associated warning/error. The > program does not lock up outside of valgrind. > > Is there a way to tell how the program has locked up so that the > problem can be diagnosed? Some of the debug tracing options (see --help-debug) might help, especially --trace-syscalls=yes. N |
|
From: Bob F. <bfr...@si...> - 2004-06-23 20:20:04
|
I have a GUI program (Gtk-based with one background thread) that I am trying to run under valgrind. When running under valgrind, the program sometimes locks up solid so that only 'kill -9' terminates the process. Valgrind does not print any associated warning/error. The program does not lock up outside of valgrind. Is there a way to tell how the program has locked up so that the problem can be diagnosed? Bob ====================================== Bob Friesenhahn bfr...@si... http://www.simplesystems.org/users/bfriesen |
|
From: Jeremy F. <je...@go...> - 2004-06-23 17:11:46
|
On Wed, 2004-06-23 at 09:24 +0100, Nicholas Nethercote wrote: > On Tue, 22 Jun 2004, Jeremy Fitzhardinge wrote: > > > Valgrind does have a heap - it's where VG_(malloc) goes, allocated with > > VG_(brk). valgrind_base->valgrind_map_end is used for when V mmaps > > files, but not memory allocation. The mmap area only needs to be big > > enough to fix one .so at a time when reading symbols. > > I see. Unfortunately, some people have very big .so files (one guy had a > 500MB one!) Yes, it's a problem. I think the correct fix is to 1) implement the dwarf reader properly 2) use incremental loading 3) not require mapping the whole thing (at the very least, we only need the debug info, not all the text+data; we could probably only map parts of the debug info as needed, or not at all if we just read() it). > > I picked all the initial numbers out of the air, so this is definitely a > > tuning process I expected to happen. > > Ok. I might commit a couple of the small tweaks (eg. shrink > CLIENT_SIZE_MULTIPLE), and then think about and experiment with bigger > changes. > > My goal is to just split the user-space into two, the low part for the > client, and the high part for Valgrind + tool + shadow memory. The > boundary between them would not be fixed, but move up or down if either > part became full while the other half wasn't. (The --pointercheck segment > would be adjusted as this happened.) Yes, that's an idea. You could make shadow grow down as the userspace grows up. > That's why the stack size is important, because if the stack is at the top > of the user part, growing down, that fixes the client/Valgrind dividing > line. It would be nice if no command-line args were needed for the tricky > cases (ie. programs with big stacks) but this might be a case of making > the common case (small stacks) easy, and the unusual case (big stacks) > possible. Well, there's no reason the stack needs to be at the top of the address space. Solaris x86 puts it down low, under the executable. You could fit a 128Mbyte stack there without it getting in the way. J |
|
From: Chris J. <ch...@at...> - 2004-06-23 16:53:27
|
> On Wed, 23 Jun 2004, Chris January wrote:
>
> > I am trying to find a way to match function calls up with returns.
> >
> > [snip]
> >
> > I don't want the trampoline code instrumented so I decided
> to manually
> > insert a non-instrumneted copy (compiled from Ucode) in the
> > translation table. Unfortunately this requires the use of some
> > internal functions and is generally messy.
> >
> > Can anyone help me out here and suggest a better way to do what I'm
> > doing?v
>
> A better way for matching call/ret pairs, or a better way for
> the trampoline bit? If the latter, can you give more detail
> about your current approach -- the description you've given
> is too vague to be much use. Can you insert UCode before a
> RET that calls your trampoline code?
No, I can't insert UCode before a RET because I don't want to instrument
the code that's being called.
What I'd really like to do is:
...
Record function call
CALL ...
Record function return
...
But unfortunately the CALL ends the basic block so this doesn't work.
So what I've tried to do is modify the return address to point to some
trampoline code that does the "Record function return" bit then returns
to the real return address.
The code looks something like this:
Char return_marker[100];
....
if (VG_(search_transtab) ((Addr) return_marker) == (Addr)0) {
...
cb = VG_(alloc_UCodeBlock) ();
cb->orig_eip = (Addr) return_marker;
t1 = newTemp (cb);
uInstr1 (cb, POP, 4, TempReg, t1);
VG_(set_global_var) (cb, (Addr) &jump_data1, t1);
uInstr1 (cb, POP, 4, TempReg, t1);
uInstr1 (cb, JMP, 4, TempReg, t1);
VG_(get_last_instr)(cb)->jmpkind = JmpBoring;
VG_(get_last_instr)(cb)->cond = CondAlways;
code = VG_(emit_code) (cb, &len, jumps);
VG_(add_to_trans_tab) ((Addr) return_marker, 100, (Addr), code, len,
jumps);
VG_(arena_free) (VG_ARG_JITTER, (void *)code);
VG_(free_UCodeBlock) (cb);
}
...
if (u_in->jmpkind == JmpCall) {
...
t1 = newTemp (cb);
t2 = newTemp (cb);
uInstr2 (cb, MOV, 4, Literal, 0, TempReg, t1);
uLiteral (cb, (Addr) &sequence);
uInstr2 (cb, LOAD, 4, TempReg, t1, TempReg, t2);
uInstr1 (cb, PUSH, 4, TempReg, t2);
uInstr2 (cb, MOV, 4, Literal, 0, TempReg, t1);
uLiteral (cb, (Addr) return_marker);
uInstr1(cb, PUSH, 4, TempReg, t1);
}
Unfortunately VG_(emit_code) complains the Ucode isn't sane
(specifically the first POP instruction).
The trampoline idea is a bit of a dirty hack and requires importing a
number of internal functions like VG_(add_to_trans_tab) and the
definition of UCodeBlock.
I'd really like to find a better way of adding instrumentation either
side of the CALL but I don't know of any.
Regards,
Chris
|
|
From: Nicholas N. <nj...@ca...> - 2004-06-23 16:15:15
|
CVS commit by nethercote: Reduce rounding size for gap between shadow memory and Valgrind's space from 64MB to 1MB. Gives tools a bit more address space to play with. M +1 -1 vg_main.c 1.163 --- valgrind/coregrind/vg_main.c #1.162:1.163 @@ -82,5 +82,5 @@ /* size multiple for client address space */ -#define CLIENT_SIZE_MULTIPLE (64 * 1024*1024) +#define CLIENT_SIZE_MULTIPLE (1 * 1024*1024) #define ISSPACE(cc) ((cc) == ' ' || (cc) == '\t' || (cc) == '\n') |
|
From: Nicholas N. <nj...@ca...> - 2004-06-23 13:20:44
|
On Wed, 23 Jun 2004, Chris January wrote: > I am trying to find a way to match function calls up with returns. > > [snip] > > I don't want the trampoline code instrumented so I decided to manually > insert a non-instrumneted copy (compiled from Ucode) in the translation > table. Unfortunately this requires the use of some internal functions > and is generally messy. > > Can anyone help me out here and suggest a better way to do what I'm > doing? A better way for matching call/ret pairs, or a better way for the trampoline bit? If the latter, can you give more detail about your current approach -- the description you've given is too vague to be much use. Can you insert UCode before a RET that calls your trampoline code? N |
|
From: Chris J. <ch...@at...> - 2004-06-23 11:33:27
|
Hello, I am trying to find a way to match function calls up with returns. For example: XXX: CALL somecode somecode: . . . YYY: RET I want to match the return at YYY with the call at XXX. Whatever method I use must be able to cope with 1) the stack pointer warping (e.g. due to longjmp) and 2) not all calls/returns being instrumented. To cope with 1) I decided to give each CALL instance a unique index and pushed this value on the stack. The instrumented RET would pop this value from the stack and in this way the RET could be matched with the CALL. To cope with 2) I decided that when an instrumented CALL occurred it would have to modify the return address on the stack to point to some trampoline code that would also pop the extra index from the stack. I hope I am making sense so far! I don't want the trampoline code instrumented so I decided to manually insert a non-instrumneted copy (compiled from Ucode) in the translation table. Unfortunately this requires the use of some internal functions and is generally messy. Can anyone help me out here and suggest a better way to do what I'm doing? Regargs, Chris -- http://www.atomice.com |
|
From: Nicholas N. <nj...@ca...> - 2004-06-23 08:28:49
|
On Tue, 22 Jun 2004, Tom Hughes wrote: > > > * What's considered a normal client stack size? Is it reasonable to > > > limit it? > > > > 8MB is probably enough for most of the class of applications that > > people use Valgrind on. However, there are numerical apps that want > > 1GB or so. > > Can we configure it at run time based on the user's stacksize limit > or is this something that needs to be fixed at build time? I think it can be done at run-time, so using the stacksize limit if it's there is a good idea, otherwise, having a default size that can be adjusted with a cmd-line arg sounds reasonable. N |
|
From: Nicholas N. <nj...@ca...> - 2004-06-23 08:24:57
|
On Tue, 22 Jun 2004, Jeremy Fitzhardinge wrote: > Valgrind does have a heap - it's where VG_(malloc) goes, allocated with > VG_(brk). valgrind_base->valgrind_map_end is used for when V mmaps > files, but not memory allocation. The mmap area only needs to be big > enough to fix one .so at a time when reading symbols. I see. Unfortunately, some people have very big .so files (one guy had a 500MB one!) > I picked all the initial numbers out of the air, so this is definitely a > tuning process I expected to happen. Ok. I might commit a couple of the small tweaks (eg. shrink CLIENT_SIZE_MULTIPLE), and then think about and experiment with bigger changes. My goal is to just split the user-space into two, the low part for the client, and the high part for Valgrind + tool + shadow memory. The boundary between them would not be fixed, but move up or down if either part became full while the other half wasn't. (The --pointercheck segment would be adjusted as this happened.) That's why the stack size is important, because if the stack is at the top of the user part, growing down, that fixes the client/Valgrind dividing line. It would be nice if no command-line args were needed for the tricky cases (ie. programs with big stacks) but this might be a case of making the common case (small stacks) easy, and the unusual case (big stacks) possible. N |
|
From: Tom H. <to...@co...> - 2004-06-23 02:25:11
|
Nightly build on dunsmere ( Fedora Core 2 ) started at 2004-06-23 03:20:03 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 ---------------------------------------- == 168 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-06-23 02:20:06
|
Nightly build on audi ( Red Hat 9 ) started at 2004-06-23 03:15:02 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 ---------------------------------------- == 168 tests, 7 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/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-06-23 02:13:43
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2004-06-23 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 ---------------------------------------- == 168 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-06-23 02:08:16
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2004-06-23 03:05:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow 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 ---------------------------------------- == 168 tests, 8 stderr failures, 1 stdout failure ================= helgrind/tests/deadlock (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (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-06-23 02:08:03
|
Nightly build on standard ( Red Hat 7.2 ) started at 2004-06-23 03:00: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 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 ---------------------------------------- == 168 tests, 1 stderr failure, 0 stdout failures ================= memcheck/tests/badfree-2trace (stderr) make: *** [regtest] Error 1 |