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
(33) |
2
(15) |
3
(20) |
4
(22) |
5
(13) |
|
6
(12) |
7
(32) |
8
(17) |
9
(31) |
10
(21) |
11
(7) |
12
(13) |
|
13
(13) |
14
(12) |
15
(10) |
16
(8) |
17
(7) |
18
(28) |
19
(5) |
|
20
(5) |
21
(7) |
22
(11) |
23
(7) |
24
(13) |
25
(7) |
26
(7) |
|
27
(7) |
28
(15) |
29
(30) |
30
(21) |
31
(6) |
|
|
|
From: Julian S. <js...@ac...> - 2008-07-24 19:57:23
|
Hi, Sounds interesting. > So my questions is that it seems record and replay is not too > difficult to do in valgrind and it is useful. But why hasn't anyone > done it? Am I missing something that is too difficult to do? > Is there not enough benefits? Well, have you seen Robert O'Callahan's work on Amber? It sounds like there might be some considerable area of overlap between Amber and what you are thinking of. See http://www.ocallahan.org/Amber.pdf J |
|
From: Julian S. <js...@ac...> - 2008-07-24 19:28:20
|
On Thursday 24 July 2008 17:18, Andrei Soare wrote: > Can someone please tell me how I could use rand() in the source code ? #include "pub_tool_libcbase.h" and then use VG_(rand). Perhaps not the best random number generator but better than nothing. J |
|
From: Andrei S. <and...@gm...> - 2008-07-24 15:18:26
|
Hello, I am trying to modify the massif tool in Valgrind and I need the function rand() or any other function that generates random numbers. Can someone please tell me how I could use rand() in the source code ? I need to #include <stdlib.h> but that is not permitted, I see the Makefile compiles ms_main.c with -nodefaultlibs. Even if I delete the -nodefaultlibs option, it compiles successfully and builds, but I get an error at execution. Please help. Thank you. Regards, Andrei Soare |
|
From: <sv...@va...> - 2008-07-24 10:34:05
|
Author: sewardj
Date: 2008-07-24 11:34:12 +0100 (Thu, 24 Jul 2008)
New Revision: 8460
Log:
* use NONPTR in some places where UNKNOWN was previously used.
* make the lossage-detecting machinery collect stack traces, not
just IPs.
Modified:
branches/PTRCHECK/exp-ptrcheck/pc_main.c
Modified: branches/PTRCHECK/exp-ptrcheck/pc_main.c
===================================================================
--- branches/PTRCHECK/exp-ptrcheck/pc_main.c 2008-07-24 10:33:01 UTC (rev 8459)
+++ branches/PTRCHECK/exp-ptrcheck/pc_main.c 2008-07-24 10:34:12 UTC (rev 8460)
@@ -54,6 +54,10 @@
// instrumentation
// GetI kludge: is at least safe; will abort in unhandled cases
+// FIXME: check nothing is mapped in the lowest 1M of memory at
+// startup, or quit (to do with nonptr_or_unknown, also sync 1M
+// magic value with PIE default load address in m_ume.c.
+
// XXX: recycle freed segments
//--------------------------------------------------------------
@@ -483,7 +487,7 @@
Int i;
for (i = 0; i < SEC_MAP_WORDS; i++)
- distinguished_secondary_map.vseg[i] = UNKNOWN;
+ distinguished_secondary_map.vseg[i] = NONPTR;
for (i = 0; i < N_PRIMAP_L1; i++) {
primap_L1[i].base = 1; /* not 64k aligned, so doesn't match any
@@ -583,7 +587,7 @@
sizeof(SecMap) );
for (i = 0; i < SEC_MAP_WORDS; i++)
- map->vseg[i] = UNKNOWN;
+ map->vseg[i] = NONPTR;
if (0) VG_(printf)("XXX new secmap %p\n", map);
return map;
}
@@ -1721,6 +1725,7 @@
|| f == (Addr)pc_replace_memalign
|| f == (Addr)pc_replace_realloc)
{
+ // if (f == (Addr)pc_replace_realloc)return;
// We remembered the last added segment; make sure it's the right one.
/* What's going on: at this point, the scheduler has just called
'f' -- one of our malloc replacement functions -- and it has
@@ -1740,7 +1745,7 @@
if ((UInt)NULL == p) {
// if alloc failed, eg. realloc on bogus pointer
put_guest_intreg(tid, 1/*first-shadow*/,
- guest_state_offset, size, (UWord)UNKNOWN );
+ guest_state_offset, size, (UWord)NONPTR );
} else {
// alloc didn't fail. Check we have the correct segment.
tl_assert(p == Seg__a(last_seg_added));
@@ -1758,7 +1763,7 @@
// non-pointer.
tl_assert(is_integer_guest_reg(guest_state_offset, size));
put_guest_intreg(tid, 1/*first-shadow*/,
- guest_state_offset, size, (UWord)UNKNOWN );
+ guest_state_offset, size, (UWord)NONPTR );
}
else {
// Anything else, probably best to set return value to non-pointer.
@@ -1889,7 +1894,8 @@
# endif
case __NR_uname:
case __NR_write:
- VG_(set_syscall_return_shadows)( tid, (UWord)UNKNOWN, 0 );
+ //VG_(set_syscall_return_shadows)( tid, (UWord)UNKNOWN, 0 );
+ VG_(set_syscall_return_shadows)( tid, (UWord)NONPTR, 0 );
break;
/* These ones definitely don't return pointers. They're not
@@ -1934,6 +1940,7 @@
# endif
case __NR_gettimeofday:
case __NR_getuid:
+ case __NR_inotify_init:
case __NR_kill:
case __NR_link:
# if defined(__NR_listen)
@@ -2073,7 +2080,7 @@
return (a > 0x01000000UL && a < 0xFF000000UL);
} else {
//return (a > 0x01000000UL && a < 0xFF00000000000000UL);
- return (a >= 0x10000UL && a < 0xFF00000000000000UL);
+ return (a >= 16 * 0x10000UL && a < 0xFF00000000000000UL);
}
}
@@ -2097,24 +2104,24 @@
static ULong stats__refs_lost_seg = 0;
typedef
- struct { Addr ip; UWord count; }
+ struct { ExeContext* ec; UWord count; }
Lossage;
static OSet* lossage = NULL;
-static void inc_lossage ( Addr ip )
+static void inc_lossage ( ExeContext* ec )
{
Lossage key, *res, *nyu;
- key.ip = ip;
+ key.ec = ec;
key.count = 0; /* frivolous */
res = VG_(OSetGen_Lookup)(lossage, &key);
if (res) {
- tl_assert(res->ip == ip);
+ tl_assert(res->ec == ec);
res->count++;
} else {
nyu = (Lossage*)VG_(OSetGen_AllocNode)(lossage, sizeof(Lossage));
tl_assert(nyu);
- nyu->ip = ip;
+ nyu->ec = ec;
nyu->count = 1;
VG_(OSetGen_Insert)( lossage, nyu );
}
@@ -2122,7 +2129,7 @@
static void init_lossage ( void )
{
- lossage = VG_(OSetGen_Create)( /*keyOff*/ offsetof(Lossage,ip),
+ lossage = VG_(OSetGen_Create)( /*keyOff*/ offsetof(Lossage,ec),
/*fastCmp*/NULL,
VG_(malloc), VG_(free) );
tl_assert(lossage);
@@ -2131,12 +2138,17 @@
static void show_lossage ( void )
{
Lossage* elem;
+return;
VG_(OSetGen_ResetIter)( lossage );
while ( (elem = VG_(OSetGen_Next)(lossage)) ) {
- Char buf[100];
- (void)VG_(describe_IP)(elem->ip, buf, sizeof(buf)-1);
- buf[sizeof(buf)-1] = 0;
- VG_(printf)(" %,8lu %s\n", elem->count, buf);
+
+ if (elem->count < 10) continue;
+ //Char buf[100];
+ //(void)VG_(describe_IP)(elem->ec, buf, sizeof(buf)-1);
+ //buf[sizeof(buf)-1] = 0;
+ //VG_(printf)(" %,8lu %s\n", elem->count, buf);
+ VG_(message)(Vg_UserMsg, "Lossage count %,lu at", elem->count);
+ VG_(pp_ExeContext)(elem->ec);
}
}
@@ -2159,16 +2171,24 @@
stats__refs_in_a_seg++;
if (UNKNOWN == mptr_vseg
|| BOTTOM == mptr_vseg || NONPTR == mptr_vseg) {
- Addr ip;
+ ExeContext* ec;
Char buf[100];
static UWord xx = 0;
stats__refs_lost_seg++;
- ip = VG_(get_IP)( VG_(get_running_tid)() );
- inc_lossage(ip);
+ //ip = VG_(get_IP)( VG_(get_running_tid)() );
+ ec = VG_(record_ExeContext)( VG_(get_running_tid)(), 0 );
+ inc_lossage(ec);
+ if (0) {
+ VG_(message)(Vg_DebugMsg, "");
+ VG_(message)(Vg_DebugMsg,
+ "Lossage %s %p sz %lu inside block alloc'd",
+ is_write ? "wr" : "rd", m, (UWord)sz);
+ VG_(pp_ExeContext)(Seg__where(seg));
+ }
if (xx++ < 0) {
- (void)VG_(describe_IP)(ip, buf, sizeof(buf)-1);
+ (void)VG_(describe_IP)(ec, buf, sizeof(buf)-1);
buf[sizeof(buf)-1] = 0;
- VG_(printf)("lossage at %p %s\n", ip, buf );
+ VG_(printf)("lossage at %p %s\n", ec, buf );
}
}
}
@@ -3397,6 +3417,19 @@
} else {
tl_assert(pce->gWordTy == Ity_I64);
+
+#if 0
+ /* special handling of t +/- const: return the shadow for t
+ regardless of how big the const is. Otherwise the result may
+ degrade to Unknown if the const is declared unknown by
+ nonptr_or_unknown(). */
+ if (1 && op == Iop_Add64
+ && a1->tag == Iex_RdTmp && a2->tag == Iex_Const) {
+ a1v = schemeEw_Atom( pce, a1 );
+ assign( 'I', pce, dstv, a1v );
+ return;
+ }
+#endif
switch (op) {
/* For these cases, pass Segs for both arguments, and the
|
|
From: <sv...@va...> - 2008-07-24 10:32:53
|
Author: sewardj
Date: 2008-07-24 11:33:01 +0100 (Thu, 24 Jul 2008)
New Revision: 8459
Log:
Change default load address for PIEs to 1MB, so that exp-ptrcheck can
assume that all constants below 1MB are NONPTR.
Modified:
branches/PTRCHECK/coregrind/m_ume.c
Modified: branches/PTRCHECK/coregrind/m_ume.c
===================================================================
--- branches/PTRCHECK/coregrind/m_ume.c 2008-07-24 10:30:20 UTC (rev 8458)
+++ branches/PTRCHECK/coregrind/m_ume.c 2008-07-24 10:33:01 UTC (rev 8459)
@@ -360,10 +360,10 @@
/* We really don't want to load PIEs at zero or too close. It
works, but it's unrobust (NULL pointer reads and writes
become legit, which is really bad) and causes problems for
- exp-ptrcheck, which assumes all numbers below 64k are
- nonpointers. So, hackily, move it above 64k. */
- if (ebase < 0x10000)
- ebase = 0x10000;
+ exp-ptrcheck, which assumes all numbers below 1MB are
+ nonpointers. So, hackily, move it above 1MB. */
+ if (ebase < 0x100000)
+ ebase = 0x100000;
}
info->phnum = e->e.e_phnum;
|
|
From: <sv...@va...> - 2008-07-24 10:30:14
|
Author: sewardj
Date: 2008-07-24 11:30:20 +0100 (Thu, 24 Jul 2008)
New Revision: 8458
Log:
Intercept memcpy, as part of trying to track down sources of
inaccuracy.
Modified:
branches/PTRCHECK/exp-ptrcheck/pc_intercepts.c
Modified: branches/PTRCHECK/exp-ptrcheck/pc_intercepts.c
===================================================================
--- branches/PTRCHECK/exp-ptrcheck/pc_intercepts.c 2008-07-23 20:08:41 UTC (rev 8457)
+++ branches/PTRCHECK/exp-ptrcheck/pc_intercepts.c 2008-07-24 10:30:20 UTC (rev 8458)
@@ -111,6 +111,53 @@
STRLEN(m_ld_linux_x86_64_so_2, strlen)
+#define MEMCPY(soname, fnname) \
+ void* VG_REPLACE_FUNCTION_ZU(soname,fnname) \
+ ( void *dst, const void *src, SizeT sz ); \
+ void* VG_REPLACE_FUNCTION_ZU(soname,fnname) \
+ ( void *dest, const void *src, SizeT sz ) \
+ { \
+ const UChar* s = (const UChar*)src; \
+ UChar* d = (UChar*)dest; \
+ const UWord* sW = (const UWord*)src; \
+ UWord* dW = (UWord*)dest; \
+ const UWord al = sizeof(UWord)-1; \
+ \
+ if (0 == (((UWord)dW) & al) && 0 == (((UWord)sW) & al)) { \
+ while (sz >= 4 * sizeof(UWord)) { \
+ dW[0] = sW[0]; \
+ dW[1] = sW[1]; \
+ dW[2] = sW[2]; \
+ dW[3] = sW[3]; \
+ sz -= 4 * sizeof(UWord); \
+ dW += 4; \
+ sW += 4; \
+ } \
+ if (sz == 0) \
+ return dest; \
+ while (sz >= 1 * sizeof(UWord)) { \
+ dW[0] = sW[0]; \
+ sz -= 1 * sizeof(UWord); \
+ dW += 1; \
+ sW += 1; \
+ } \
+ if (sz == 0) \
+ return dest; \
+ s = (const UChar*)sW; \
+ d = (UChar*)dW; \
+ } \
+ \
+ while (sz--) \
+ *d++ = *s++; \
+ \
+ return dest; \
+ }
+
+MEMCPY(m_libc_soname, memcpy)
+MEMCPY(m_ld_so_1, memcpy) /* ld.so.1 */
+MEMCPY(m_ld64_so_1, memcpy) /* ld64.so.1 */
+
+
/*--------------------------------------------------------------------*/
/*--- end pc_intercepts.c ---*/
/*--------------------------------------------------------------------*/
|
|
From: James C. <cl...@cc...> - 2008-07-24 03:45:38
|
Mojiong I think this work sounds great. I've done a good deal of work on capture / replay systems; you can check out my webpage (www.cc.gatech.edu ~clause) for some additional information some of the techniques I've come up with. I think the main reason that no one has done this before is simply because no one has gotten around to it. There's also a few similar tools like Jockey (http://home.gna.org/jockey/) that make it less interesting from an academic standpoint. The thing that excites me the most is that you've got an analysis working on the replay. This is something that's been talked about a lot but hasn't really had a good implementation. Are you willing to share your code? If you put it out there some other people may help you fill in the details. ~Jim On Jul 23, 2008, at 6:39 PM, MoJiong Qiu wrote: > Hi, > I am a new valgrind hacker. I apologize if this question has > been raised and discussed before. I'm interested in recording a > program execution with valgrind and replaying it in valgrind with > added analysis. > > I have spent some time implementing a prototype of record and > replay in the valgrind core based on intercepting and recording > syscall results and playing back their results. So far, I have only > wrapped a dozen or so syscalls and valgrind only records and replays > small single threaded programs. I am able to record execution for > these small programs with this modified valgrind core with no > analysis, and have the core replay the execution while turning on > instrumentation and analysis (I turned on cachegrind while > replaying). More complex client programs can be supported as more > syscalls are recorded and replayed. It doesn't currently support > multithreading or signal delivery, though I expect recording and > replaying these should be doable as well. > > In my prototype, no valgrind tools are needed during recording, > hence recording is 2-4x slowdown (roughly the overhead of nullgrind > itself). > Valgrind tools like cachegrind can be enabled during replay (in > theory memcheck can be supported too, but requires a little more > work on the recording end to deal with its changes to the memory > allocator). > > Why record and replay? The recording overhead is roughly > comparable to nullgrind, which will generally be smaller > (potentially much > smaller) than directly doing the analysis. This means it can be > more efficient to record a phenomenon and analyze its execution > after it has been captured. This is particularly good for capturing > executions that aren't easily reproducible, like those triggered by > external inputs (e.g., querying results from a database). Record > and replay can capture the buggy executions and enable more > effective debugging. > > Second, for interactive programs, say firefox, the slowdown > caused by online memcheck may be too high for user interaction. > Record and replay moves this slowdown to replay time, when the > playback is automated. > > So my questions is that it seems record and replay is not too > difficult to do in valgrind and it is useful. But why hasn't anyone > done it? Am I missing something that is too difficult to do? Is > there not enough benefits? > > Thanks, > Mojiong > > Discover the new Windows Vista Learn more! > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/_______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Tom H. <th...@cy...> - 2008-07-24 03:05:11
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2008-07-24 03:15: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 == 345 tests, 60 stderr failures, 1 stdout failure, 29 post failures == memcheck/tests/file_locking (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/long_namespace_xml (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/origin1-yes (stderr) memcheck/tests/origin4-many (stderr) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/varinfo1 (stderr) memcheck/tests/varinfo2 (stderr) memcheck/tests/varinfo3 (stderr) memcheck/tests/varinfo4 (stderr) memcheck/tests/varinfo5 (stderr) memcheck/tests/varinfo6 (stderr) memcheck/tests/x86/bug152022 (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/xor-undef-x86 (stderr) memcheck/tests/xml1 (stderr) massif/tests/alloc-fns-A (post) massif/tests/alloc-fns-B (post) massif/tests/basic (post) massif/tests/basic2 (post) massif/tests/big-alloc (post) massif/tests/culling1 (stderr) massif/tests/culling2 (stderr) massif/tests/custom_alloc (post) massif/tests/deep-A (post) massif/tests/deep-B (stderr) massif/tests/deep-B (post) massif/tests/deep-C (stderr) massif/tests/deep-C (post) massif/tests/deep-D (post) massif/tests/ignoring (post) massif/tests/insig (post) massif/tests/long-names (post) massif/tests/long-time (post) massif/tests/new-cpp (post) massif/tests/null (post) massif/tests/one (post) massif/tests/overloaded-new (post) massif/tests/peak (post) massif/tests/peak2 (stderr) massif/tests/peak2 (post) massif/tests/realloc (stderr) massif/tests/realloc (post) massif/tests/thresholds_0_0 (post) massif/tests/thresholds_0_10 (post) massif/tests/thresholds_10_0 (post) massif/tests/thresholds_10_10 (post) massif/tests/thresholds_5_0 (post) massif/tests/thresholds_5_10 (post) massif/tests/zero1 (post) massif/tests/zero2 (post) none/tests/blockfault (stderr) none/tests/mremap2 (stdout) none/tests/shell (stderr) none/tests/shell_valid1 (stderr) none/tests/shell_valid2 (stderr) none/tests/shell_valid3 (stderr) helgrind/tests/hg01_all_ok (stderr) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/hg06_readshared (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc02_simple_tls (stderr) helgrind/tests/tc03_re_excl (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc07_hbl1 (stderr) helgrind/tests/tc08_hbl2 (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc11_XCHG (stderr) helgrind/tests/tc12_rwl_trivial (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) helgrind/tests/tc24_nonzero_sem (stderr) |
|
From: Tom H. <th...@cy...> - 2008-07-24 02:55:45
|
Nightly build on aston ( x86_64, Fedora Core 5 ) started at 2008-07-24 03:20:05 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 == 443 tests, 8 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/file_locking (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/x86/scalar (stderr) none/tests/blockfault (stderr) none/tests/mremap2 (stdout) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) |
|
From: Tom H. <th...@cy...> - 2008-07-24 02:42:47
|
Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2008-07-24 03:05:05 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 == 437 tests, 6 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/file_locking (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) none/tests/mremap2 (stdout) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc22_exit_w_lock (stderr) |
|
From: Tom H. <th...@cy...> - 2008-07-24 02:42:04
|
Nightly build on trojan ( x86_64, Fedora Core 6 ) started at 2008-07-24 03:25: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 == 441 tests, 8 stderr failures, 5 stdout failures, 0 post failures == memcheck/tests/file_locking (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/bug133694 (stdout) memcheck/tests/x86/bug133694 (stderr) memcheck/tests/x86/scalar (stderr) none/tests/cmdline1 (stdout) none/tests/cmdline2 (stdout) none/tests/mremap2 (stdout) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) |
|
From: Tom H. <th...@cy...> - 2008-07-24 02:23:51
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2008-07-24 03:00: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 == 443 tests, 32 stderr failures, 3 stdout failures, 0 post failures == memcheck/tests/file_locking (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/varinfo6 (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/amd64/insn_ssse3 (stdout) none/tests/amd64/insn_ssse3 (stderr) none/tests/amd64/ssse3_misaligned (stderr) none/tests/blockfault (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap2 (stdout) none/tests/x86/insn_ssse3 (stdout) none/tests/x86/insn_ssse3 (stderr) none/tests/x86/ssse3_misaligned (stderr) helgrind/tests/hg01_all_ok (stderr) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) drd/tests/atomic_var (stderr) |
|
From: MoJiong Q. <qm...@ho...> - 2008-07-24 01:39:37
|
Hi,
I am a new valgrind hacker. I apologize if this question has been raised and discussed before. I'm interested in recording a program execution with valgrind and replaying it in valgrind with added analysis.
I have spent some time implementing a prototype of record and replay in the valgrind core based on intercepting and recording syscall results and playing back their results. So far, I have only wrapped a dozen or so syscalls and valgrind only records and replays small single threaded programs. I am able to record execution for these small programs with this modified valgrind core with no analysis, and have the core replay the execution while turning on instrumentation and analysis (I turned on cachegrind while replaying). More complex client programs can be supported as more syscalls are recorded and replayed. It doesn't currently support multithreading or signal delivery, though I expect recording and replaying these should be doable as well.
In my prototype, no valgrind tools are needed during recording, hence recording is 2-4x slowdown (roughly the overhead of nullgrind itself).Valgrind tools like cachegrind can be enabled during replay (in theory memcheck can be supported too, but requires a little more work on the recording end to deal with its changes to the memory allocator).
Why record and replay? The recording overhead is roughly comparable to nullgrind, which will generally be smaller (potentially muchsmaller) than directly doing the analysis. This means it can be more efficient to record a phenomenon and analyze its execution after it has been captured. This is particularly good for capturing executions that aren't easily reproducible, like those triggered by external inputs (e.g., querying results from a database). Record and replay can capture the buggy executions and enable more effective debugging.
Second, for interactive programs, say firefox, the slowdown caused by online memcheck may be too high for user interaction. Record and replay moves this slowdown to replay time, when the playback is automated.
So my questions is that it seems record and replay is not too difficult to do in valgrind and it is useful. But why hasn't anyone done it? Am I missing something that is too difficult to do? Is there not enough benefits?
Thanks,
Mojiong
_________________________________________________________________
Discover the new Windows Vista
http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE |