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
(12) |
|
2
(6) |
3
(13) |
4
(9) |
5
(6) |
6
(8) |
7
(5) |
8
(5) |
|
9
(15) |
10
(18) |
11
(18) |
12
(18) |
13
(7) |
14
(11) |
15
(6) |
|
16
(12) |
17
(28) |
18
(15) |
19
(12) |
20
(17) |
21
(23) |
22
(10) |
|
23
(9) |
24
(11) |
25
(7) |
26
(21) |
27
(12) |
28
(6) |
29
(6) |
|
30
(8) |
|
|
|
|
|
|
|
From: <js...@ac...> - 2007-09-06 12:12:04
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2007-09-06 09:00:01 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 == 220 tests, 10 stderr failures, 6 stdout failures, 0 posttest failures == memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-fp (stderr) none/tests/ppc32/round (stdout) none/tests/ppc32/round (stderr) none/tests/ppc32/test_fx (stdout) none/tests/ppc32/test_fx (stderr) none/tests/ppc32/test_gx (stdout) |
|
From: Julian S. <js...@ac...> - 2007-09-06 08:31:39
|
> What else must I do to tell memcheck and other tools about my new > address space? One giant kludge is just to tell memcheck to ignore it. Check out the svn trunk (this won't work with 3.2.3), find out apriori where your hardware is getting mapped, and tell memcheck using this flag: --ignore-ranges=0xPP-0xQQ[,0xRR-0xSS] assume given addresses are OK J |
|
From: Tom H. <th...@cy...> - 2007-09-06 02:31:11
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2007-09-06 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 == 256 tests, 27 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/addressable (stderr) memcheck/tests/badjump (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/erringfds (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-pool-0 (stderr) memcheck/tests/leak-pool-1 (stderr) memcheck/tests/leak-pool-2 (stderr) memcheck/tests/leak-pool-3 (stderr) memcheck/tests/leak-pool-4 (stderr) memcheck/tests/leak-pool-5 (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/long_namespace_xml (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/partial_load_dflt (stderr) memcheck/tests/partial_load_ok (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigkill (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/xor-undef-x86 (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2007-09-06 02:23:38
|
Nightly build on dellow ( x86_64, Fedora 7 ) started at 2007-09-06 03:10:08 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 == 293 tests, 4 stderr failures, 3 stdout failures, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/pth_detached (stdout) |
|
From: Tom H. <th...@cy...> - 2007-09-06 02:17:27
|
Nightly build on lloyd ( x86_64, Fedora Core 3 ) started at 2007-09-06 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 == 293 tests, 6 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/x86/scalar_supp (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2007-09-06 02:11:24
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2007-09-06 03:00: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 == 295 tests, 6 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/x86/scalar_supp (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: kewal7 <inv...@sh...> - 2007-09-06 00:34:22
|
Just a friendly reminder that I invited you to Shelfari. Come see the books= I love and see if we have any in common. Then pick my next book so I can= keep on reading.=0A=0AClick below to join my group of friends on Shelfari!= =0A=0Ahttp://www.shelfari.com/Register.aspx?ActivityId=3D8451383&InvitationCode=3D89864e93-e692-4c3c-9cf6-d7de90a847ae= =0A=0Akewal7=0A=0AShelfari is a free site that lets you share book ratings= and reviews with friends and meet people who have similar tastes in books.= It also lets you build an online bookshelf, join book clubs, and get good= book recommendations from friends. You should check it out.=0A=0A--------= =0A=0AYou have received this email because kewal7 (ke...@gm...) directly= invited you to join his/her community on Shelfari.=0A=0AIt is against Shelfari's= policies to invite people who you don't know directly. Follow this link= (http://www.shelfari.com/actions/emailoptout.aspx?email=3Dv...@li...&activityid=3D8451383)= to prevent future invitations to this address. If you believe you do not= know this person, you may view (http://www.shelfari.com/kewal7) his/her= Shelfari page or report him/her in our feedback (http://www.shelfari.com/Feedback.aspx)= section.=0A=0AShelfari, 616 1st Ave #300, Seattle, WA 98104=0A |
|
From: Chris D. <Chr...@am...> - 2007-09-06 00:25:19
|
Hi, I am looking for some advice on supporting a user-space driver toolkit in valgrind. I am working off v3.2.3. This is on x86 Linux. The driver toolkit consists of a kernel module that exports a whole mess of ioctls. So, I have been working in syswrap-generic.c adding the needed ioctls. I think that I understand that part OK with the PRE_MEM_READ()/POST_MEM_WRITE() stuff, but the key routine maps a PCI card into userspace. In other words it acts like mmap(), shmat(), or sbrk() and adds a mapping of a PCI card's memory spaces into my program. I do not know that mapped addresses until after registering the card, and there is no way to influence the addresses the kernel picks. What I have done so far is to take advantage of the mmap() hooks in aspacem. In the POST_ioctl wrapper I page align the address and size for my new mapping and then call am_notify_client_mmap(). I then call VG_TRACK(new_mem_mmap...) to hopefully let the core and client tool know about the new memory. The problem is that it doesn't seem to work when my program actually accesses the mapped addresses. e.g. I get this when Address 0x40001000 is most certainly mapped. ==251== Invalid read of size 4 ==251== at 0x4101746: FLASH_ReadDword (flash_lib.cpp:647) ==251== by 0x410F8D5: LAS0::read_bit0(bit_id, unsigned long&) (fmmap.cpp:44) ==251== by 0x411568C: module_io::present() (moduleio.cpp:186) ==251== by 0x4108C08: FMCntrlReadData(int, unsigned long long, unsigned char*, unsigned long&) (fmcntrl.cpp:716) ==251== by 0x406F7DF: CFlashMedia::cntrl_get_data(unsigned long long, unsigned char*, int) (csm_fm.cpp:664) ==251== by 0x406D816: CFlashMedia::get_block_header(unsigned long long, unsigned long*) (csm_fm.cpp:77) ==251== by 0x409180D: CPosition::get_timestamp(int, timecode_type&, int*) (position.cpp:2916) ==251== by 0x4090837: CPosition::post_begin_record(timecode_type*) (position.cpp:2644) ==251== by 0x40942C6: CPosition::write_raw_data(unsigned char*, int&) (position.cpp:3840) ==251== by 0x40A3117: recorder::set_raw_data(int&, unsigned char*) (recorder.cpp:253) ==251== by 0x40395C7: CMsgDlg::write_raw_data(void*, int&) (msgdlg.cpp:1234) ==251== by 0x403D84A: FCL_WriteData(int, void*, int&) (ddfc.cpp:222) ==251== Address 0x40001000 is not stack'd, malloc'd or (recently) free'd What else must I do to tell memcheck and other tools about my new address space? Thanks, Chris -- Christopher Douty <Chr...@am...> +1-650-367-3129 Senior Engineer, Software & Systems - AMPEX Data Systems Corp. |
|
From: <js...@ac...> - 2007-09-05 12:07:26
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2007-09-05 09:00:01 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 == 220 tests, 10 stderr failures, 6 stdout failures, 0 posttest failures == memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-fp (stderr) none/tests/ppc32/round (stdout) none/tests/ppc32/round (stderr) none/tests/ppc32/test_fx (stdout) none/tests/ppc32/test_fx (stderr) none/tests/ppc32/test_gx (stdout) |
|
From: Tom H. <th...@cy...> - 2007-09-05 02:31:10
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2007-09-05 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 == 256 tests, 27 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/addressable (stderr) memcheck/tests/badjump (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/erringfds (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-pool-0 (stderr) memcheck/tests/leak-pool-1 (stderr) memcheck/tests/leak-pool-2 (stderr) memcheck/tests/leak-pool-3 (stderr) memcheck/tests/leak-pool-4 (stderr) memcheck/tests/leak-pool-5 (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/long_namespace_xml (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/partial_load_dflt (stderr) memcheck/tests/partial_load_ok (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigkill (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/xor-undef-x86 (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2007-09-05 02:23:21
|
Nightly build on dellow ( x86_64, Fedora 7 ) started at 2007-09-05 03:10:05 BST Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 293 tests, 4 stderr failures, 3 stdout failures, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/pth_detached (stdout) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 293 tests, 4 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Wed Sep 5 03:16:49 2007 --- new.short Wed Sep 5 03:23:16 2007 *************** *** 8,10 **** ! == 293 tests, 4 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/pointer-trace (stderr) --- 8,10 ---- ! == 293 tests, 4 stderr failures, 3 stdout failures, 0 posttest failures == memcheck/tests/pointer-trace (stderr) *************** *** 15,16 **** --- 15,17 ---- none/tests/mremap2 (stdout) + none/tests/pth_detached (stdout) |
|
From: Tom H. <th...@cy...> - 2007-09-05 02:17:33
|
Nightly build on lloyd ( x86_64, Fedora Core 3 ) started at 2007-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 == 293 tests, 6 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/x86/scalar_supp (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2007-09-05 02:11:35
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2007-09-05 03:00: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 == 295 tests, 6 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/x86/scalar_supp (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: <js...@ac...> - 2007-09-05 00:17:30
|
Nightly build on g5 ( SuSE 10.1, ppc970 ) started at 2007-09-05 02:00:01 CEST 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 == 228 tests, 6 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/pointer-trace (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Oriol P. <aut...@gm...> - 2007-09-04 22:32:38
|
> > Some questions about Valgrind internals come to my mind: > > Are VG_ libc functions and regular libc functions using the same file > > descriptor table? > > Everything uses the same file descriptor table. But I'm not sure how that's > relevant. The problematic function calls libc's fwrite function when an event buffer is full. > > What happens with the heap used by translated code and regular code > > called inside Valgrind tools? > > I don't understand the question. But Valgrind tools don't use the normal > heap, they have their own heap space. The code of the other tool is executed in client space (instrumented) when the client program calls to few functions. This tool allocates memory to save events inside, opens a file, and dumps the events to the file when the buffer is full. The memory are allocated in client space like the open operation. If the buffer is flushed in client space there are no problem. When I call the function from valgrind tool space and the buffer is full, this other tool tries to flush its own buffer to it's own opened file. Then crashes with a segmentation fault. Thanks, Oriol 2007/9/5, Nicholas Nethercote <nj...@cs...>: > On Tue, 4 Sep 2007, Oriol Prat wrote: > > > I did it. > > It works until the called function calls a libc function. > > I sent a mail, days ago, explaining all the process that I followed to > > accomplish. > > > > > > It could be a problem to call indirect libc functions in valgrind tool code? > > > > valgrind code -> user library function (hard-coded absolute address) > > -> libc function (like fwrite, printf, etc) > > > > Some questions about Valgrind internals come to my mind: > > Are VG_ libc functions and regular libc functions using the same file > > descriptor table? > > Everything uses the same file descriptor table. But I'm not sure how that's > relevant. > > > What happens with the heap used by translated code and regular code > > called inside Valgrind tools? > > I don't understand the question. But Valgrind tools don't use the normal > heap, they have their own heap space. > > Nick > > > > 2007/9/4, Nicholas Nethercote <nj...@cs...>: > >> On Mon, 3 Sep 2007, Oriol Prat wrote: > >> > >>> Is it possible to call translated code from an instrumented function? > >>> > >>> I have an instrumented function inserted with unsafeIRDirty_0_N and > >>> from inside this function I want to call a function that is part of > >>> the user code. > >>> > >>> I want to do this because I load with LD_PRELOAD another > >>> instrumentation tool at the same time as Valgrind and I want to call a > >>> function of this other tool from Valgrind instrumentation function. > >>> > >>> I understand that this other tool is instrumented by Valgrind like > >>> regular user code and I'm not be able to call it directly from > >>> Valgrind instrumented functions. > >> > >> I'm not sure if you can do this. If you can find a way to just call the > >> code normally from the function, and Valgrind will translate it normally, I > >> think. The hard part may be working out how to call the code from the > >> function, since it won't be visible -- maybe you could do something horrible > >> like put the destination address in a global variable? Not sure. > >> > >> Nick > >> > > > |
|
From: Nicholas N. <nj...@cs...> - 2007-09-04 22:10:02
|
On Tue, 4 Sep 2007, Oriol Prat wrote: > I did it. > It works until the called function calls a libc function. > I sent a mail, days ago, explaining all the process that I followed to > accomplish. > > > It could be a problem to call indirect libc functions in valgrind tool code? > > valgrind code -> user library function (hard-coded absolute address) > -> libc function (like fwrite, printf, etc) > > Some questions about Valgrind internals come to my mind: > Are VG_ libc functions and regular libc functions using the same file > descriptor table? Everything uses the same file descriptor table. But I'm not sure how that's relevant. > What happens with the heap used by translated code and regular code > called inside Valgrind tools? I don't understand the question. But Valgrind tools don't use the normal heap, they have their own heap space. Nick > 2007/9/4, Nicholas Nethercote <nj...@cs...>: >> On Mon, 3 Sep 2007, Oriol Prat wrote: >> >>> Is it possible to call translated code from an instrumented function? >>> >>> I have an instrumented function inserted with unsafeIRDirty_0_N and >>> from inside this function I want to call a function that is part of >>> the user code. >>> >>> I want to do this because I load with LD_PRELOAD another >>> instrumentation tool at the same time as Valgrind and I want to call a >>> function of this other tool from Valgrind instrumentation function. >>> >>> I understand that this other tool is instrumented by Valgrind like >>> regular user code and I'm not be able to call it directly from >>> Valgrind instrumented functions. >> >> I'm not sure if you can do this. If you can find a way to just call the >> code normally from the function, and Valgrind will translate it normally, I >> think. The hard part may be working out how to call the code from the >> function, since it won't be visible -- maybe you could do something horrible >> like put the destination address in a global variable? Not sure. >> >> Nick >> > |
|
From: <js...@ac...> - 2007-09-04 12:03:24
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2007-09-04 09:00:01 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 == 220 tests, 10 stderr failures, 6 stdout failures, 0 posttest failures == memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-fp (stderr) none/tests/ppc32/round (stdout) none/tests/ppc32/round (stderr) none/tests/ppc32/test_fx (stdout) none/tests/ppc32/test_fx (stderr) none/tests/ppc32/test_gx (stdout) |
|
From: <sv...@va...> - 2007-09-04 08:24:35
|
Author: sewardj
Date: 2007-09-04 09:24:28 +0100 (Tue, 04 Sep 2007)
New Revision: 6798
Log:
Make the MASSIF2 branch compile again following recent changes to Vex
and to the core/tool interface. This commit merges r6779, r6787 and
r6791 from trunk.
Modified:
branches/MASSIF2/coregrind/m_scheduler/scheduler.c
branches/MASSIF2/coregrind/m_tooliface.c
branches/MASSIF2/coregrind/m_translate.c
branches/MASSIF2/coregrind/pub_core_tooliface.h
branches/MASSIF2/include/pub_tool_tooliface.h
branches/MASSIF2/memcheck/mc_include.h
branches/MASSIF2/memcheck/mc_main.c
branches/MASSIF2/memcheck/mc_translate.c
Modified: branches/MASSIF2/coregrind/m_scheduler/scheduler.c
===================================================================
--- branches/MASSIF2/coregrind/m_scheduler/scheduler.c 2007-09-01 23:22:39 UTC (rev 6797)
+++ branches/MASSIF2/coregrind/m_scheduler/scheduler.c 2007-09-04 08:24:28 UTC (rev 6798)
@@ -1045,10 +1045,14 @@
break;
}
- case VEX_TRC_JMP_TRAP:
+ case VEX_TRC_JMP_SIGTRAP:
VG_(synth_sigtrap)(tid);
break;
+ case VEX_TRC_JMP_SIGSEGV:
+ VG_(synth_fault)(tid);
+ break;
+
case VEX_TRC_JMP_NODECODE:
VG_(message)(Vg_UserMsg,
"valgrind: Unrecognised instruction at address %p.", VG_(get_IP)(tid));
Modified: branches/MASSIF2/coregrind/m_tooliface.c
===================================================================
--- branches/MASSIF2/coregrind/m_tooliface.c 2007-09-01 23:22:39 UTC (rev 6797)
+++ branches/MASSIF2/coregrind/m_tooliface.c 2007-09-04 08:24:28 UTC (rev 6798)
@@ -94,6 +94,7 @@
.data_syms = False,
.malloc_replacement = False,
.xml_output = False,
+ .final_IR_tidy_pass = False
};
/* static */
@@ -260,6 +261,13 @@
VG_(tdict).tool_client_redzone_szB = client_malloc_redzone_szB;
}
+void VG_(needs_final_IR_tidy_pass)(
+ IRSB*(*final_tidy)(IRSB*)
+)
+{
+ VG_(needs).final_IR_tidy_pass = True;
+ VG_(tdict).tool_final_IR_tidy_pass = final_tidy;
+}
/*--------------------------------------------------------------------*/
/* Tracked events */
Modified: branches/MASSIF2/coregrind/m_translate.c
===================================================================
--- branches/MASSIF2/coregrind/m_translate.c 2007-09-01 23:22:39 UTC (rev 6797)
+++ branches/MASSIF2/coregrind/m_translate.c 2007-09-04 08:24:28 UTC (rev 6798)
@@ -1287,6 +1287,9 @@
vta.instrument2 = need_to_handle_SP_assignment()
? vg_SP_update_pass
: NULL;
+ vta.finaltidy = VG_(needs).final_IR_tidy_pass
+ ? VG_(tdict).tool_final_IR_tidy_pass
+ : NULL;
vta.do_self_check = do_self_check;
vta.traceflags = verbosity;
Modified: branches/MASSIF2/coregrind/pub_core_tooliface.h
===================================================================
--- branches/MASSIF2/coregrind/pub_core_tooliface.h 2007-09-01 23:22:39 UTC (rev 6797)
+++ branches/MASSIF2/coregrind/pub_core_tooliface.h 2007-09-04 08:24:28 UTC (rev 6798)
@@ -91,6 +91,7 @@
Bool data_syms;
Bool malloc_replacement;
Bool xml_output;
+ Bool final_IR_tidy_pass;
}
VgNeeds;
@@ -155,6 +156,9 @@
void* (*tool_realloc) (ThreadId, void*, SizeT);
SizeT tool_client_redzone_szB;
+ // VG_(needs).final_IR_tidy_pass
+ IRSB* (*tool_final_IR_tidy_pass) (IRSB*);
+
// -- Event tracking functions ------------------------------------
void (*track_new_mem_startup) (Addr, SizeT, Bool, Bool, Bool);
void (*track_new_mem_stack_signal)(Addr, SizeT);
Modified: branches/MASSIF2/include/pub_tool_tooliface.h
===================================================================
--- branches/MASSIF2/include/pub_tool_tooliface.h 2007-09-01 23:22:39 UTC (rev 6797)
+++ branches/MASSIF2/include/pub_tool_tooliface.h 2007-09-04 08:24:28 UTC (rev 6798)
@@ -439,6 +439,12 @@
* it". */
extern void VG_(needs_xml_output)( void );
+/* Does the tool want to have one final pass over the IR after tree
+ building but before instruction selection? If so specify the
+ function here. */
+extern void VG_(needs_final_IR_tidy_pass) ( IRSB*(*final_tidy)(IRSB*) );
+
+
/* ------------------------------------------------------------------ */
/* Core events to track */
Modified: branches/MASSIF2/memcheck/mc_include.h
===================================================================
--- branches/MASSIF2/memcheck/mc_include.h 2007-09-01 23:22:39 UTC (rev 6797)
+++ branches/MASSIF2/memcheck/mc_include.h 2007-09-04 08:24:28 UTC (rev 6798)
@@ -320,6 +320,9 @@
VexGuestExtents* vge,
IRType gWordTy, IRType hWordTy );
+extern
+IRSB* MC_(final_tidy) ( IRSB* );
+
#endif /* ndef __MC_INCLUDE_H */
/*--------------------------------------------------------------------*/
Modified: branches/MASSIF2/memcheck/mc_main.c
===================================================================
--- branches/MASSIF2/memcheck/mc_main.c 2007-09-01 23:22:39 UTC (rev 6797)
+++ branches/MASSIF2/memcheck/mc_main.c 2007-09-04 08:24:28 UTC (rev 6798)
@@ -4969,6 +4969,9 @@
MC_(instrument),
mc_fini);
+ VG_(needs_final_IR_tidy_pass) ( MC_(final_tidy) );
+
+
VG_(needs_core_errors) ();
VG_(needs_tool_errors) (mc_eq_Error,
mc_pp_Error,
Modified: branches/MASSIF2/memcheck/mc_translate.c
===================================================================
--- branches/MASSIF2/memcheck/mc_translate.c 2007-09-01 23:22:39 UTC (rev 6797)
+++ branches/MASSIF2/memcheck/mc_translate.c 2007-09-04 08:24:28 UTC (rev 6798)
@@ -37,6 +37,9 @@
#include "pub_tool_machine.h" // VG_(fnptr_to_fnentry)
#include "mc_include.h"
+#include "pub_tool_xarray.h"
+#include "pub_tool_mallocfree.h"
+#include "pub_tool_libcbase.h"
/* This file implements the Memcheck instrumentation, and in
particular contains the core of its undefined value detection
@@ -356,38 +359,22 @@
static IRAtom* mkLeft8 ( MCEnv* mce, IRAtom* a1 ) {
tl_assert(isShadowAtom(mce,a1));
- /* It's safe to duplicate a1 since it's only an atom */
- return assignNew(mce, Ity_I8,
- binop(Iop_Or8, a1,
- assignNew(mce, Ity_I8,
- unop(Iop_Neg8, a1))));
+ return assignNew(mce, Ity_I8, unop(Iop_Left8, a1));
}
static IRAtom* mkLeft16 ( MCEnv* mce, IRAtom* a1 ) {
tl_assert(isShadowAtom(mce,a1));
- /* It's safe to duplicate a1 since it's only an atom */
- return assignNew(mce, Ity_I16,
- binop(Iop_Or16, a1,
- assignNew(mce, Ity_I16,
- unop(Iop_Neg16, a1))));
+ return assignNew(mce, Ity_I16, unop(Iop_Left16, a1));
}
static IRAtom* mkLeft32 ( MCEnv* mce, IRAtom* a1 ) {
tl_assert(isShadowAtom(mce,a1));
- /* It's safe to duplicate a1 since it's only an atom */
- return assignNew(mce, Ity_I32,
- binop(Iop_Or32, a1,
- assignNew(mce, Ity_I32,
- unop(Iop_Neg32, a1))));
+ return assignNew(mce, Ity_I32, unop(Iop_Left32, a1));
}
static IRAtom* mkLeft64 ( MCEnv* mce, IRAtom* a1 ) {
tl_assert(isShadowAtom(mce,a1));
- /* It's safe to duplicate a1 since it's only an atom */
- return assignNew(mce, Ity_I64,
- binop(Iop_Or64, a1,
- assignNew(mce, Ity_I64,
- unop(Iop_Neg64, a1))));
+ return assignNew(mce, Ity_I64, unop(Iop_Left64, a1));
}
/* --------- 'Improvement' functions for AND/OR. --------- */
@@ -502,14 +489,28 @@
static IRAtom* mkPCastTo( MCEnv* mce, IRType dst_ty, IRAtom* vbits )
{
- IRType ty;
+ IRType src_ty;
IRAtom* tmp1;
/* Note, dst_ty is a shadow type, not an original type. */
/* First of all, collapse vbits down to a single bit. */
tl_assert(isShadowAtom(mce,vbits));
- ty = typeOfIRExpr(mce->bb->tyenv, vbits);
- tmp1 = NULL;
- switch (ty) {
+ src_ty = typeOfIRExpr(mce->bb->tyenv, vbits);
+
+ /* Fast-track some common cases */
+ if (src_ty == Ity_I32 && dst_ty == Ity_I32)
+ return assignNew(mce, Ity_I32, unop(Iop_CmpwNEZ32, vbits));
+
+ if (src_ty == Ity_I64 && dst_ty == Ity_I64)
+ return assignNew(mce, Ity_I64, unop(Iop_CmpwNEZ64, vbits));
+
+ if (src_ty == Ity_I32 && dst_ty == Ity_I64) {
+ IRAtom* tmp = assignNew(mce, Ity_I32, unop(Iop_CmpwNEZ32, vbits));
+ return assignNew(mce, Ity_I64, binop(Iop_32HLto64, tmp, tmp));
+ }
+
+ /* Else do it the slow way .. */
+ tmp1 = NULL;
+ switch (src_ty) {
case Ity_I1:
tmp1 = vbits;
break;
@@ -536,7 +537,7 @@
break;
}
default:
- ppIRType(ty);
+ ppIRType(src_ty);
VG_(tool_panic)("mkPCastTo(1)");
}
tl_assert(tmp1);
@@ -1260,12 +1261,30 @@
IRAtom* mkLazyN ( MCEnv* mce,
IRAtom** exprvec, IRType finalVtype, IRCallee* cee )
{
- Int i;
+ Int i;
IRAtom* here;
- IRAtom* curr = definedOfType(Ity_I32);
+ IRAtom* curr;
+ IRType mergeTy;
+ IRType mergeTy64 = True;
+
+ /* Decide on the type of the merge intermediary. If all relevant
+ args are I64, then it's I64. In all other circumstances, use
+ I32. */
for (i = 0; exprvec[i]; i++) {
tl_assert(i < 32);
tl_assert(isOriginalAtom(mce, exprvec[i]));
+ if (cee->mcx_mask & (1<<i))
+ continue;
+ if (typeOfIRExpr(mce->bb->tyenv, exprvec[i]) != Ity_I64)
+ mergeTy64 = False;
+ }
+
+ mergeTy = mergeTy64 ? Ity_I64 : Ity_I32;
+ curr = definedOfType(mergeTy);
+
+ for (i = 0; exprvec[i]; i++) {
+ tl_assert(i < 32);
+ tl_assert(isOriginalAtom(mce, exprvec[i]));
/* Only take notice of this arg if the callee's mc-exclusion
mask does not say it is to be excluded. */
if (cee->mcx_mask & (1<<i)) {
@@ -1275,8 +1294,10 @@
} else {
/* calculate the arg's definedness, and pessimistically merge
it in. */
- here = mkPCastTo( mce, Ity_I32, expr2vbits(mce, exprvec[i]) );
- curr = mkUifU32(mce, here, curr);
+ here = mkPCastTo( mce, mergeTy, expr2vbits(mce, exprvec[i]) );
+ curr = mergeTy64
+ ? mkUifU64(mce, here, curr)
+ : mkUifU32(mce, here, curr);
}
}
return mkPCastTo(mce, finalVtype, curr );
@@ -2465,17 +2486,6 @@
case Iop_Not1:
return vatom;
- /* Neg* really fall under the Add/Sub banner, and as such you
- might think would qualify for the 'expensive add/sub'
- treatment. However, in this case since the implied literal
- is zero (0 - arg), we just do the cheap thing anyway. */
- case Iop_Neg8:
- return mkLeft8(mce, vatom);
- case Iop_Neg16:
- return mkLeft16(mce, vatom);
- case Iop_Neg32:
- return mkLeft32(mce, vatom);
-
default:
ppIROp(op);
VG_(tool_panic)("memcheck:expr2vbits_Unop");
@@ -3461,6 +3471,149 @@
return bb;
}
+/*------------------------------------------------------------*/
+/*--- Post-tree-build final tidying ---*/
+/*------------------------------------------------------------*/
+
+/* This exploits the observation that Memcheck often produces
+ repeated conditional calls of the form
+
+ Dirty G MC_(helperc_value_check0/1/4/8_fail)()
+
+ with the same guard expression G guarding the same helper call.
+ The second and subsequent calls are redundant. This usually
+ results from instrumentation of guest code containing multiple
+ memory references at different constant offsets from the same base
+ register. After optimisation of the instrumentation, you get a
+ test for the definedness of the base register for each memory
+ reference, which is kinda pointless. MC_(final_tidy) therefore
+ looks for such repeated calls and removes all but the first. */
+
+/* A struct for recording which (helper, guard) pairs we have already
+ seen. */
+typedef
+ struct { void* entry; IRExpr* guard; }
+ Pair;
+
+/* Return True if e1 and e2 definitely denote the same value (used to
+ compare guards). Return False if unknown; False is the safe
+ answer. Since guest registers and guest memory do not have the
+ SSA property we must return False if any Gets or Loads appear in
+ the expression. */
+
+static Bool sameIRValue ( IRExpr* e1, IRExpr* e2 )
+{
+ if (e1->tag != e2->tag)
+ return False;
+ switch (e1->tag) {
+ case Iex_Const:
+ return eqIRConst( e1->Iex.Const.con, e2->Iex.Const.con );
+ case Iex_Binop:
+ return e1->Iex.Binop.op == e2->Iex.Binop.op
+ && sameIRValue(e1->Iex.Binop.arg1, e2->Iex.Binop.arg1)
+ && sameIRValue(e1->Iex.Binop.arg2, e2->Iex.Binop.arg2);
+ case Iex_Unop:
+ return e1->Iex.Unop.op == e2->Iex.Unop.op
+ && sameIRValue(e1->Iex.Unop.arg, e2->Iex.Unop.arg);
+ case Iex_RdTmp:
+ return e1->Iex.RdTmp.tmp == e2->Iex.RdTmp.tmp;
+ case Iex_Mux0X:
+ return sameIRValue( e1->Iex.Mux0X.cond, e2->Iex.Mux0X.cond )
+ && sameIRValue( e1->Iex.Mux0X.expr0, e2->Iex.Mux0X.expr0 )
+ && sameIRValue( e1->Iex.Mux0X.exprX, e2->Iex.Mux0X.exprX );
+ case Iex_Qop:
+ case Iex_Triop:
+ case Iex_CCall:
+ /* be lazy. Could define equality for these, but they never
+ appear to be used. */
+ return False;
+ case Iex_Get:
+ case Iex_GetI:
+ case Iex_Load:
+ /* be conservative - these may not give the same value each
+ time */
+ return False;
+ case Iex_Binder:
+ /* should never see this */
+ /* fallthrough */
+ default:
+ VG_(printf)("mc_translate.c: sameIRValue: unhandled: ");
+ ppIRExpr(e1);
+ VG_(tool_panic)("memcheck:sameIRValue");
+ return False;
+ }
+}
+
+/* See if 'pairs' already has an entry for (entry, guard). Return
+ True if so. If not, add an entry. */
+
+static
+Bool check_or_add ( XArray* /*of Pair*/ pairs, IRExpr* guard, void* entry )
+{
+ Pair p;
+ Pair* pp;
+ Int i, n = VG_(sizeXA)( pairs );
+ for (i = 0; i < n; i++) {
+ pp = VG_(indexXA)( pairs, i );
+ if (pp->entry == entry && sameIRValue(pp->guard, guard))
+ return True;
+ }
+ p.guard = guard;
+ p.entry = entry;
+ VG_(addToXA)( pairs, &p );
+ return False;
+}
+
+static Bool is_helperc_value_checkN_fail ( HChar* name )
+{
+ return
+ 0==VG_(strcmp)(name, "MC_(helperc_value_check0_fail)")
+ || 0==VG_(strcmp)(name, "MC_(helperc_value_check1_fail)")
+ || 0==VG_(strcmp)(name, "MC_(helperc_value_check4_fail)")
+ || 0==VG_(strcmp)(name, "MC_(helperc_value_check8_fail)");
+}
+
+IRSB* MC_(final_tidy) ( IRSB* sb_in )
+{
+ Int i;
+ IRStmt* st;
+ IRDirty* di;
+ IRExpr* guard;
+ IRCallee* cee;
+ Bool alreadyPresent;
+ XArray* pairs = VG_(newXA)( VG_(malloc), VG_(free), sizeof(Pair) );
+ /* Scan forwards through the statements. Each time a call to one
+ of the relevant helpers is seen, check if we have made a
+ previous call to the same helper using the same guard
+ expression, and if so, delete the call. */
+ for (i = 0; i < sb_in->stmts_used; i++) {
+ st = sb_in->stmts[i];
+ tl_assert(st);
+ if (st->tag != Ist_Dirty)
+ continue;
+ di = st->Ist.Dirty.details;
+ guard = di->guard;
+ if (!guard)
+ continue;
+ if (0) { ppIRExpr(guard); VG_(printf)("\n"); }
+ cee = di->cee;
+ if (!is_helperc_value_checkN_fail( cee->name ))
+ continue;
+ /* Ok, we have a call to helperc_value_check0/1/4/8_fail with
+ guard 'guard'. Check if we have already seen a call to this
+ function with the same guard. If so, delete it. If not,
+ add it to the set of calls we do know about. */
+ alreadyPresent = check_or_add( pairs, guard, cee->addr );
+ if (alreadyPresent) {
+ sb_in->stmts[i] = IRStmt_NoOp();
+ if (0) VG_(printf)("XX\n");
+ }
+ }
+ VG_(deleteXA)( pairs );
+ return sb_in;
+}
+
+
/*--------------------------------------------------------------------*/
/*--- end mc_translate.c ---*/
/*--------------------------------------------------------------------*/
|
|
From: Tom H. <th...@cy...> - 2007-09-04 02:31:25
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2007-09-04 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 == 256 tests, 27 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/addressable (stderr) memcheck/tests/badjump (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/erringfds (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-pool-0 (stderr) memcheck/tests/leak-pool-1 (stderr) memcheck/tests/leak-pool-2 (stderr) memcheck/tests/leak-pool-3 (stderr) memcheck/tests/leak-pool-4 (stderr) memcheck/tests/leak-pool-5 (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/long_namespace_xml (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/partial_load_dflt (stderr) memcheck/tests/partial_load_ok (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigkill (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/xor-undef-x86 (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2007-09-04 02:23:10
|
Nightly build on dellow ( x86_64, Fedora 7 ) started at 2007-09-04 03:10: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 == 293 tests, 4 stderr failures, 3 stdout failures, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/pth_detached (stdout) |
|
From: Tom H. <th...@cy...> - 2007-09-04 02:17:28
|
Nightly build on lloyd ( x86_64, Fedora Core 3 ) started at 2007-09-04 03:05:07 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 == 293 tests, 6 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/x86/scalar_supp (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2007-09-04 02:10:58
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2007-09-04 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 == 295 tests, 6 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/x86/scalar_supp (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: <js...@ac...> - 2007-09-04 00:38:36
|
Nightly build on g5 ( SuSE 10.1, ppc970 ) started at 2007-09-04 02:00:01 CEST Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 228 tests, 6 stderr failures, 3 stdout failures, 0 posttest failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/pointer-trace (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/res_search (stdout) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 228 tests, 6 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/pointer-trace (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Tue Sep 4 02:08:27 2007 --- new.short Tue Sep 4 02:17:31 2007 *************** *** 8,10 **** ! == 228 tests, 6 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/deep_templates (stdout) --- 8,10 ---- ! == 228 tests, 6 stderr failures, 3 stdout failures, 0 posttest failures == memcheck/tests/deep_templates (stdout) *************** *** 17,18 **** --- 17,19 ---- none/tests/mremap2 (stdout) + none/tests/res_search (stdout) |
|
From: Nicholas N. <nj...@cs...> - 2007-09-03 22:19:42
|
On Mon, 3 Sep 2007, Oriol Prat wrote: > Is it possible to call translated code from an instrumented function? > > I have an instrumented function inserted with unsafeIRDirty_0_N and > from inside this function I want to call a function that is part of > the user code. > > I want to do this because I load with LD_PRELOAD another > instrumentation tool at the same time as Valgrind and I want to call a > function of this other tool from Valgrind instrumentation function. > > I understand that this other tool is instrumented by Valgrind like > regular user code and I'm not be able to call it directly from > Valgrind instrumented functions. I'm not sure if you can do this. If you can find a way to just call the code normally from the function, and Valgrind will translate it normally, I think. The hard part may be working out how to call the code from the function, since it won't be visible -- maybe you could do something horrible like put the destination address in a global variable? Not sure. Nick |
|
From: Jeff J. <n3...@ma...> - 2007-09-03 20:18:22
|
Hi -- rpm just started using add_key/keyctl through keyutils and I noticed that valgrind-3.2.3 doesn't yet support those system calls. Attached is a patch to valgrind-3.2.3 (from Fedora 8) to add support for the keyutils syscalls on linux. Appears to work on x86, I've not tested amd64/ppc32/ppc64, but the syscalls appear generic. Enjoy! 73 de Jeff |