You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
1
(9) |
2
(16) |
|
3
(9) |
4
(8) |
5
(9) |
6
(10) |
7
(14) |
8
(10) |
9
(7) |
|
10
(14) |
11
(19) |
12
(22) |
13
(18) |
14
(20) |
15
(10) |
16
(12) |
|
17
(13) |
18
(7) |
19
(12) |
20
(13) |
21
(9) |
22
(12) |
23
(6) |
|
24
(5) |
25
(5) |
26
(6) |
27
(7) |
28
(9) |
29
(13) |
30
(21) |
|
From: Bryan M. <om...@br...> - 2006-09-07 22:05:39
|
Well, as a developer of an external tool, I am both really excited and intimidated at the same time. >From a development point of view, keeping Omega out of subversion hasn't hurt at all. I simply got a clean checkout of valgrind, svn added my code and directories as I went along and occasionally push out a diff to the tree with 'svn diff . VEX > file.patch'. People are downloading the patch, applying it, giving Omega a try and some are reporting bugs back to me (no success stories outside of my office yet but there must be at least one out there :D). The intimidating bit is that with Omega in Valgrinds' subversion repo, even when marked experimental and all the rest of it, there will be an increased expectation. It's either going to be a very positive experience or people are going find bugs, grow to hate it and then it wont get used due to a lousy reputation. This is on top of the extra visibility which on the one hand I want Omega to have (it's a really good tool when it works as it should) but on the other hand, being just me at the moment, I don't know if I can support it properly in the face of a sudden influx of users. There should definitely be some additional hurdles to inclusion though - I keep asking people to post reports to the list as well so you can all see some traffic as this shows that there is some user base forming that has an interest in the tool, rather than it just being a weekend hobby project. The other thing would be being able to show some progress against stated functionality. That gets difficult though - I have run Omega on some massive codebases at work without any problems whereas a couple of my bug reporters got it to die with embarrassing ease (fixed now - honest). I suppose this is another case where being able to show a community forming around a tool would give some confidence that it is actually doing something that others find useful. I am certainly willing to be a guinea pig on this if you want to add Omega in the first batch. (Omega has two small VEX tweaks that you might want to consider before inclusion). If I get swamped with bug reports and feature requests and end up having a nervous breakdown trying to work through them all then maybe you will have to rethink things before the next tool comes along :P Bryan Nicholas Nethercote wrote: > On Thu, 7 Sep 2006, Josef Weidendorfer wrote: > >> Currently, a VG tool author can distribute his/her tool by >> (1) convince VG core authors to include it into VG package >> (2) hack a VG source distribution to include his/her tool, thus >> distributing a customized Valgrind package >> (3) distribute an external VG tool package >> [...] >> IMHO, it is worth it because (3) lowers the barrier for new tool authors >> by giving them choice. And exposure also is possible by naming external >> tools on the web site. > > Sure, keeping open (3) as a possibility is a good idea. What the new > policy does is allow (1) in addition to (2) and (3). > > Nick > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Nicholas N. <nj...@cs...> - 2006-09-07 21:21:26
|
On Thu, 7 Sep 2006, Josef Weidendorfer wrote: > Currently, a VG tool author can distribute his/her tool by > (1) convince VG core authors to include it into VG package > (2) hack a VG source distribution to include his/her tool, thus > distributing a customized Valgrind package > (3) distribute an external VG tool package > [...] > IMHO, it is worth it because (3) lowers the barrier for new tool authors > by giving them choice. And exposure also is possible by naming external > tools on the web site. Sure, keeping open (3) as a possibility is a good idea. What the new policy does is allow (1) in addition to (2) and (3). Nick |
|
From: Christoph B. <bar...@gm...> - 2006-09-07 18:45:36
|
Hi, Here is another crash of the same problem: sleep BB# 418 Callgrind: callstack.c:211 (vgCallgrind_push_call_stack): Assertion 'current_entry->cxt != 0' failed. ==21768== at 0x380189DA: report_and_quit (m_libcassert.c:136) ==21768== by 0x38018D3D: vgPlain_assert_fail (m_libcassert.c:200) ==21768== by 0x38010CAB: vgCallgrind_push_call_stack (callstack.c:211) ==21768== by 0x38006864: vgCallgrind_setup_bbcc (bbcc.c:529) ==21768== by 0x4028D5181: ??? ==21768== by 0x38020A87: mkFreeBlock (m_mallocfree.c:916) ==21768== by 0x4028818FF: ??? ==21768== by 0x4021354AF: ??? ==21768== by 0x10: ??? ==21768== by 0xCBB4F: ??? ==21768== by 0x4005B5: main (debug-prog2.C:8) Here is also a minimal set of options necessary for the problem: valgrind --tool=callgrind ./a.out but one then has to interate callgrind_control -i off callgrind_control -i on callgrind_control -d till valgrind crashes. Greetings, Christoph Bartoschek |
|
From: Josef W. <Jos...@gm...> - 2006-09-07 12:11:27
|
On Thursday 07 September 2006 09:49, Nicholas Nethercote wrote: > On Thu, 7 Sep 2006, Josef Weidendorfer wrote: > > > I think it would be better for experimental tools to first live outside > > of VGs core code base; we should provide an example "external VG tool > > package". I did this a long time with callgrind, and it was > > working quite well (with the exception of biarch). > > I disagree. This was the approach we took with Callgrind for a long time, > but in hindsight I think it was the wrong one. Presence in the > distribution gives a tool much more exposure, and I think it makes it more > likely that new tools will become popular and good. Just thinking about pros/contras for external VG tools. Currently, a VG tool author can distribute his/her tool by (1) convince VG core authors to include it into VG package (2) hack a VG source distribution to include his/her tool, thus distributing a customized Valgrind package (3) distribute an external VG tool package IMHO, (2) is only useful in the development process of a tool, but not very good for distribution because of installation conflicts with the official VG package. (2) is of course the only way when starting a port to another platform. For the tool author, (3) does have some benefits * No need to convince VG core authors to include it into VG package * Allows for very loose development, independent from VG release cycles * Allows for small source package, dependent on an official VG installation in the user system * Allows the tool to be packed with visualization/post processing/... applications, which could be a problem integrating into VG source (eg. QT/GTK dependency) However, when the author can convince VG core authors to include it into VG package, (1) is nice for a number of reasons: * Exposure * Possibly better direct help from VG authors * Possibly less bugs because more eyes scan the code * No version mismatch possible * Better influence in additions to core/tool API * Simple integration into existing regression test suite, and automatic testing overnight on different platforms * Easy integration of documentation The last to items were actually a problem with callgrind before. Now, it is questionable whether we want to support (3) at all in the future, which really needs a check whether all header files, needed libraries, correct *.pc file are installed. IMHO, it is worth it because (3) lowers the barrier for new tool authors by giving them choice. And exposure also is possible by naming external tools on the web site. Josef |
|
From: <js...@ac...> - 2006-09-07 11:30:27
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2006-09-07 09: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 == 207 tests, 10 stderr failures, 6 stdout failures, 0 posttest failures == memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigaltstack (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (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: Nicholas N. <nj...@cs...> - 2006-09-07 07:49:33
|
On Thu, 7 Sep 2006, Josef Weidendorfer wrote: > I think it would be better for experimental tools to first live outside > of VGs core code base; we should provide an example "external VG tool > package". I did this a long time with callgrind, and it was > working quite well (with the exception of biarch). I disagree. This was the approach we took with Callgrind for a long time, but in hindsight I think it was the wrong one. Presence in the distribution gives a tool much more exposure, and I think it makes it more likely that new tools will become popular and good. I think it's a good idea to make things more open where possible, because currently too much responsibility lies on Julian's shoulders -- he only has so many hours in the day. This is one attempt to open things up, and I think it's a good one because tools are nicely separate from the rest of the system -- if a tool is broken it doesn't drag the rest of the system down. Another area in which it would be nice to have this mature/experimental divide is in ports to new platforms. Unfortunately ports are less modular than tools, so the mechanics of how to do this are less clear. Nick |
|
From: <js...@ac...> - 2006-09-07 04:11:57
|
Nightly build on phoenix ( SuSE 10.0 ) started at 2006-09-07 04:30:01 BST Checking out vex source tree ... done Building vex ... done Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 237 tests, 5 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/leak-tree (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <to...@co...> - 2006-09-07 02:45:39
|
Nightly build on dunsmere ( athlon, Fedora Core 5 ) started at 2006-09-07 03:30: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 == 239 tests, 5 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2006-09-07 02:25:28
|
Nightly build on dellow ( x86_64, Fedora Core 5 ) started at 2006-09-07 03:10:04 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 266 tests, 4 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/mempool (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2006-09-07 02:24:37
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2006-09-07 03:15:02 BST Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Last 20 lines of verbose log follow echo /tmp/ccyNZ0Zv.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccyNZ0Zv.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccyNZ0Zv.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccyNZ0Zv.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccyNZ0Zv.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccyNZ0Zv.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccyNZ0Zv.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccyNZ0Zv.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 rm insn_mmx.c insn_sse2.c insn_fpu.c insn_mmxext.c insn_sse.c insn_sse3.c insn_cmov.c insn_basic.c make[5]: Leaving directory `/tmp/valgrind.23361/valgrind/none/tests/x86' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.23361/valgrind/none/tests/x86' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.23361/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.23361/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.23361/valgrind' make: *** [check] Error 2 ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Last 20 lines of verbose log follow echo /tmp/ccgLXmla.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccgLXmla.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccgLXmla.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccgLXmla.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccgLXmla.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccgLXmla.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccgLXmla.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccgLXmla.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 rm insn_mmx.c insn_sse2.c insn_fpu.c insn_mmxext.c insn_sse.c insn_sse3.c insn_cmov.c insn_basic.c make[5]: Leaving directory `/tmp/valgrind.23361/valgrind/none/tests/x86' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.23361/valgrind/none/tests/x86' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.23361/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.23361/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.23361/valgrind' make: *** [check] Error 2 ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Thu Sep 7 03:19:53 2006 --- new.short Thu Sep 7 03:24:32 2006 *************** *** 7,16 **** Last 20 lines of verbose log follow echo ! /tmp/ccgLXmla.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccgLXmla.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccgLXmla.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccgLXmla.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccgLXmla.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccgLXmla.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccgLXmla.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccgLXmla.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 --- 7,16 ---- Last 20 lines of verbose log follow echo ! /tmp/ccyNZ0Zv.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccyNZ0Zv.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccyNZ0Zv.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccyNZ0Zv.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccyNZ0Zv.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccyNZ0Zv.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccyNZ0Zv.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccyNZ0Zv.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 |
|
From: Tom H. <th...@cy...> - 2006-09-07 02:19:38
|
Nightly build on lloyd ( x86_64, Fedora Core 3 ) started at 2006-09-07 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 == 266 tests, 6 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/leakotron (stdout) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2006-09-07 02:14:27
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2006-09-07 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 == 268 tests, 6 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/mempool (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Josef W. <Jos...@gm...> - 2006-09-07 01:31:42
|
On Saturday 02 September 2006 09:22, Oswald Buddenhagen wrote: > On Sat, Sep 02, 2006 at 03:18:56AM +0100, Julian Seward wrote: > > Recording program counters without a stack is of limited use, but I > > can't see how to record a complete stack for each first-write without > > huge space/time overheads. It might be possible to devise a highly > > compressed representation for just the PC values, based on the idea > > that each segment is only going to use a tiny subset of the 2^32/2^64 > > possible PC values. > > > i think saving traces in a tree might work. sounds a bit like callgrind. Yes. In callgrind, I always have the shadow call stack. And from this, I make context IDs on the fly, which is a pointer to a struct (similar to your PC). The context specifies the current stack trace up to a given maximal depth (--separate-callers=maxdepth). The structure contains the PCs in the stack trace; contexts are kept in a hash table. Event counters in callgrind are always related to the current context (maxdepth defaults to depth 1, ie. current function). The only problem is that for greater maxdepth, the number of contexts can get quite large. Some time ago I did some measurements; usually, a konqueror run touches around 25000 functions; with --separate-callers=20, I get 500000. Still reasonable. I could try to split the shadow call stack / context generation stuff out of callgrind into some helper module for tools. Note however, that this needs a callback at every BB start (like in callgrind). Josef |
|
From: Josef W. <Jos...@gm...> - 2006-09-07 00:34:02
|
On Saturday 02 September 2006 03:34, Julian Seward wrote: > New tools for 3.3.0 > ~~~~~~~~~~~~~~~~~~~ > ... > The problem with experimental tools is they need a lot of engineering > effort to get them to a production status (or conclusion that the tool > cannot be moved to production status for technical reasons.) Getting > that effort means having users try them out and contribute feedback > and patches. Putting the tools in the tree, and having them compile, > even if they don't work well, makes it a lot easier for users to do > that. It's also more inclusive for the tool authors. > > There are downsides: > > - more code in the tree inevitably means a higher maintenance overhead > > - stability of the existing code base is important, and we don't want to > undermine that > > I'm thinking of an arrangement in which experimental tool authors have > commit access to the tree, but > > - we make it clear it is their responsibility to keep tools compiling > and working > > - we ask that such authors do not commit changes outside of their individual > tools without first consulting with the core developers I think it would be better for experimental tools to first live outside of VGs core code base; we should provide an example "external VG tool package". I did this a long time with callgrind, and it was working quite well (with the exception of biarch). I can come up with "lackey" externally packaged. This should also give us a test whether it is really working. As recently noted on the list, we currently install an invalid valgrind.pc file (with a nonsense @VG_PLATFORM@ string) :-( A drawback is that experimental tools sometimes need additions in the interface to VG core - but such a change needs agreement with core developers, and after doing the change, the external tool simply needs an SVN version as dependency. We could even integrate additions to the tool interface in 3.2.x to help external, experimental tools. Josef |