|
From: Bruce M. <bm...@gm...> - 2010-12-05 15:02:13
|
Hello I've been developing a Valgrind tool for logging addresses of data accesses (with a more compact binary format than the lackey output) and a corresponding graphical viewer. I'd like to find out whether there is interest from the Valgrind developer community for this to be incorporated into Valgrind at some point. It would still need some polishing and lots of testing before it would be ready for a release, but fairly fully implemented and ready for anyone who wants to have a play with it. You can see some pictures of what it's good for at http://blog.brucemerry.org.za/2010/09/visualising-sorting-algorithms.html (screenshots are from an older version - the current viewer uses GTK+), and download git repositories from http://www.brucemerry.org.za/git/datagrind/ (Valgrind 3.6.0 plus the new tool; has a .gitmodules to pull in VEX 3.6.0) http://www.brucemerry.org.za/git/dg_view (the viewer: requires SCons and GTK+) Feedback and advice on how best to make this ready for inclusion in Valgrind are welcome; in particular I couldn't quite work out what the difference between some of the types (e.g. Word, HWord, SizeT, Address) was, and so I've probably used the wrong ones in various places. Regards Bruce -- Dr Bruce Merry bmerry <@> gmail <.> com http://www.brucemerry.org.za/ http://blog.brucemerry.org.za/ |
|
From: Michal <kor...@gm...> - 2010-12-05 19:12:36
|
Hi, I've cloned your repo at http://www.brucemerry.org.za/git/datagrind/, but am unable to find anything about datagrind in it. Anyway, at work I often deal with reference counted memory management, which unfortunately is not well supported by valgrind. In order to debug memory leaks I've created a similar, but weaker, tool to yours (http://gitorious.org/watchgrind/watchgrind). As you can see on every memory write to specified addresses (such as object's reference count) I dump stack trace. Unfortunately I can't use gdb for that, as most of the applications are threaded and gdb's watchpoints don't like that. If your tool would support such scenario easily that would be nice :), especially if (as opposed to my tool) it would correctly support atomic instructions. I am sorry, but I am unable to help you with inclusion of your tool to valgrind I am just a lurker here. Best Regards, Michal. On Sun, Dec 5, 2010 at 4:02 PM, Bruce Merry <bm...@gm...> wrote: > Hello > > I've been developing a Valgrind tool for logging addresses of data > accesses (with a more compact binary format than the lackey output) > and a corresponding graphical viewer. I'd like to find out whether > there is interest from the Valgrind developer community for this to be > incorporated into Valgrind at some point. It would still need some > polishing and lots of testing before it would be ready for a release, > but fairly fully implemented and ready for anyone who wants to have a > play with it. You can see some pictures of what it's good for at > http://blog.brucemerry.org.za/2010/09/visualising-sorting-algorithms.html > (screenshots are from an older version - the current viewer uses > GTK+), and download git repositories from > > http://www.brucemerry.org.za/git/datagrind/ (Valgrind 3.6.0 plus the > new tool; has a .gitmodules to pull in VEX 3.6.0) > http://www.brucemerry.org.za/git/dg_view (the viewer: requires SCons and GTK+) > > Feedback and advice on how best to make this ready for inclusion in > Valgrind are welcome; in particular I couldn't quite work out what the > difference between some of the types (e.g. Word, HWord, SizeT, > Address) was, and so I've probably used the wrong ones in various > places. > > Regards > Bruce > -- > Dr Bruce Merry > bmerry <@> gmail <.> com > http://www.brucemerry.org.za/ > http://blog.brucemerry.org.za/ > > ------------------------------------------------------------------------------ > What happens now with your Lotus Notes apps - do you make another costly > upgrade, or settle for being marooned without product support? Time to move > off Lotus Notes and onto the cloud with Force.com, apps are easier to build, > use, and manage than apps on traditional platforms. Sign up for the Lotus > Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Bruce M. <bm...@gm...> - 2010-12-05 20:40:50
|
On 5 December 2010 19:12, Michal <kor...@gm...> wrote: > Hi, > I've cloned your repo at http://www.brucemerry.org.za/git/datagrind/, > but am unable to find anything about datagrind in it. Apologies, I forgot to mention that it is in a 'datagrind' git branch (the master branch is upstream Valgrind 3.6.0); the tool is called 'exp-datagrind'. > Anyway, at work I often deal with reference counted memory management, > which unfortunately is not well supported by valgrind. In order to > debug memory leaks I've created a similar, but weaker, tool to yours > (http://gitorious.org/watchgrind/watchgrind). As you can see on every > memory write to specified addresses (such as object's reference count) > I dump stack trace. Unfortunately I can't use gdb for that, as most of > the applications are threaded and gdb's watchpoints don't like that. I haven't downloaded your tool yet so I'm not sure if it's really the same thing, but datagrind does store stack-trace information and when one clicks on an access it shows the stack trace of both the accessing instruction and the malloc that allocated the memory (if it came from malloc). > If your tool would support such scenario easily that would be nice :), > especially if (as opposed to my tool) it would correctly support > atomic instructions. Currently it doesn't do anything special for atomics - instructions that modify memory are just represented as a read and a write. It also doesn't implement the hooks necessary to track inputs and outputs of system calls. Bruce -- Dr Bruce Merry bmerry <@> gmail <.> com http://www.brucemerry.org.za/ http://blog.brucemerry.org.za/ |
|
From: Nicholas N. <n.n...@gm...> - 2010-12-06 05:17:21
|
On Mon, Dec 6, 2010 at 2:02 AM, Bruce Merry <bm...@gm...> wrote: > > I've been developing a Valgrind tool for logging addresses of data > accesses (with a more compact binary format than the lackey output) > and a corresponding graphical viewer. I'd like to find out whether > there is interest from the Valgrind developer community for this to be > incorporated into Valgrind at some point. First question: what's it useful for? I see some pictures of sorting algorithms which are pretty but don't seem terribly useful... After that, it would need good docs, preferably some reasonable number of tests, and a commitment from you to maintain it. Nick |
|
From: Bruce M. <bm...@gm...> - 2010-12-06 20:59:11
|
On 6 December 2010 05:16, Nicholas Nethercote <n.n...@gm...> wrote: > On Mon, Dec 6, 2010 at 2:02 AM, Bruce Merry <bm...@gm...> wrote: >> >> I've been developing a Valgrind tool for logging addresses of data >> accesses (with a more compact binary format than the lackey output) >> and a corresponding graphical viewer. I'd like to find out whether >> there is interest from the Valgrind developer community for this to be >> incorporated into Valgrind at some point. > > First question: what's it useful for? I see some pictures of sorting > algorithms which are pretty but don't seem terribly useful... Hi To some extent, the sorting is more pretty than useful, although there may be some applications in reverse engineering (I only thought of running it on sorting algorithms because one of my first tests of the viewer was running it on "ls" and when I looked at the output I could clearly identify a merge sort). The intended use is to be able to visually identify poor memory access patterns. Cachegrind is all well and good for telling you that one small area of code is hammering the cache, but there are a lot of things it doesn't show so clearly. For example, code that simply has to iterate across megabytes of data but has a nice linear access pattern will show up much hotter in cachegrind than code that touches one byte in each of a few hundred cache lines, even though the latter is the only one you can do much about. I've already used it to spot several places where data structure layout can be improved in a performance-critical application. > After that, it would need good docs, preferably some reasonable number > of tests, and a commitment from you to maintain it. Useful info, thanks. I've got some docs written - they're probably not fully up to date at this point, but they're reasonably detailed and written in the DocBook framework that the rest of the Valgrind docs use. I haven't gotten around to writing tests yet. In the short term I wouldn't be able to make any commitments about maintaining it since I have my fingers in too many pies at the moment, but that may change by the time I get around to writing tests and fixing up the known bugs. Perhaps at this stage a more appropriate way to advertise this to interested parties would be with a link on http://valgrind.org/downloads/variants.html? Obviously I'd need to actually write a web page for it to link to first. Thanks Bruce -- Dr Bruce Merry bmerry <@> gmail <.> com http://www.brucemerry.org.za/ http://blog.brucemerry.org.za/ |
|
From: Nicholas N. <n.n...@gm...> - 2010-12-06 22:32:54
|
On Tue, Dec 7, 2010 at 7:59 AM, Bruce Merry <bm...@gm...> wrote: > > The intended use is to be able to visually identify poor memory access > patterns. Cachegrind is all well and good for telling you that one > small area of code is hammering the cache, but there are a lot of > things it doesn't show so clearly. For example, code that simply has > to iterate across megabytes of data but has a nice linear access > pattern will show up much hotter in cachegrind than code that touches > one byte in each of a few hundred cache lines, even though the latter > is the only one you can do much about. I've already used it to spot > several places where data structure layout can be improved in a > performance-critical application. Fair enough, I can believe that would be useful. > Perhaps at this stage a more appropriate way to advertise this to > interested parties would be with a link on > http://valgrind.org/downloads/variants.html? Obviously I'd need to > actually write a web page for it to link to first. Yes, I'd be happy to put a link there once you have something to link to. Nick |
|
From: Bruce M. <bm...@gm...> - 2010-12-16 21:23:09
|
> > Perhaps at this stage a more appropriate way to advertise this to > > interested parties would be with a link on > > http://valgrind.org/downloads/variants.html? Obviously I'd need to > > actually write a web page for it to link to first. > > Yes, I'd be happy to put a link there once you have something to link to. > > Nick Hi Nicholas I've finally gotten around to putting this up on Gitorious with some instructions on building it and a link to an online copy of the manual page: http://gitorious.org/datagrind. For the online copy of the manual page (direct link is http://www.brucemerry.org.za/files/datagrind-docs/dg-manual.html), I just built the HTML docs with my page added in and copied the whole HTML directory. The links I'm distributing are to the datagrind subpage, but I'm slightly worried that it may confuse people if they see what looks like a mirror of the official docs but isn't - the pages don't have any sort of warning that they're a fork of the official docs. Do you have any requests or advice on how to alter the pages so that I don't mislead people? Thanks Bruce -- Dr Bruce Merry bmerry <@> gmail <.> com http://www.brucemerry.org.za/ http://blog.brucemerry.org.za/ |
|
From: Nicholas N. <n.n...@gm...> - 2010-12-17 06:22:46
|
[Bruce, please reply to the mailing list] On Thu, Dec 16, 2010 at 1:23 PM, Bruce Merry <bm...@gm...> wrote: > > Hi Nicholas > > I've finally gotten around to putting this up on Gitorious with some > instructions on building it and a link to an online copy of the manual > page: http://gitorious.org/datagrind. > > For the online copy of the manual page (direct link is > http://www.brucemerry.org.za/files/datagrind-docs/dg-manual.html), I > just built the HTML docs with my page added in and copied the whole > HTML directory. The links I'm distributing are to the datagrind > subpage, but I'm slightly worried that it may confuse people if they > see what looks like a mirror of the official docs but isn't - the > pages don't have any sort of warning that they're a fork of the > official docs. Do you have any requests or advice on how to alter the > pages so that I don't mislead people? I wouldn't worry about that, it seems unlikely people will find it. BTW, "Datagrind" isn't the most exciting/clear name and the "grind" suffix is kind of overused. Can you think of something else? Just a thought. Nick |
|
From: Bruce M. <bm...@gm...> - 2010-12-18 08:52:17
|
> BTW, "Datagrind" isn't the most exciting/clear name and the "grind" > suffix is kind of overused. Can you think of something else? Just a > thought. I agree, it's not a very good name. Unfortunately I'm not very good with names, and haven't been able to think of a better one. Does anyone on the list have a suggestion? Thanks Bruce -- Dr Bruce Merry bmerry <@> gmail <.> com http://www.brucemerry.org.za/ http://blog.brucemerry.org.za/ |