|
From: Nicholas N. <nj...@ca...> - 2003-08-09 16:41:12
|
Hi, I've written a new skin for Valgrind. It's called Massif, and does detailed space (memory) profiling. AFAIK, it is, astonishingly enough, the first decent tool anyone has made for profiling C and C++ programs -- I'm not aware of any others that give anything like as much information as Massif does. (If you know of any, I'd like to hear about them.) You can download a Valgrind bundle containing it from www.cl.cam.ac.uk/~njn25/valgrind.html. This is the first release, and although I've tested it reasonably thoroughly (it runs OpenOffice and Phoenix ok), don't expect too much. I would strongly suggest you read the docs before using it; they're not very long, they're available in the main documentation in the bundle (section 7), and also standalone on the above webpage. I'd love to hear feedback from anyone who tries it -- if you think it's useful, if you have any suggestions on how to improve it, if you find any bugs, or anything else. Thanks. N |
|
From: John L. <le...@mo...> - 2003-08-10 12:34:06
|
On Sat, Aug 09, 2003 at 05:41:07PM +0100, Nicholas Nethercote wrote:
> I've written a new skin for Valgrind. It's called Massif, and does
2.6.0-test1 works fine. Allow it.
regards
john
diff -Naur -x Makefile -x .deps -x autom4te-2.53.cache -x config.log -x config.status -x configure valgrind-MASSIF/configure.in v/configure.in
--- valgrind-MASSIF/configure.in 2003-08-09 16:43:05.000000000 +0100
+++ v/configure.in 2003-08-10 13:49:59.000000000 +0100
@@ -97,6 +97,11 @@
kernel=`uname -r`
case "${kernel}" in
+ 2.6.*)
+ AC_MSG_RESULT([2.6 family (${kernel})])
+ AC_DEFINE([KERNEL_2_6], 1, [Define to 1 if you're using Linux 2.6.x])
+ ;;
+
2.5.*)
AC_MSG_RESULT([2.5 family (${kernel})])
AC_DEFINE([KERNEL_2_5], 1, [Define to 1 if you're using Linux 2.5.x])
--
Khendon's Law:
If the same point is made twice by the same person, the thread is over.
|
|
From: John L. <le...@mo...> - 2003-08-12 17:24:43
|
On Sun, Aug 10, 2003 at 01:29:57PM +0100, John Levon wrote: > > I've written a new skin for Valgrind. It's called Massif, and does > > 2.6.0-test1 works fine. Allow it. Is there some reason you dropped this patch ? regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over. |
|
From: Nicholas N. <nj...@ca...> - 2003-08-12 17:51:34
|
On Tue, 12 Aug 2003, John Levon wrote: > Is there some reason you dropped this patch ? Sorry, I forgot to actually copy the new version to the webpage [sigh]. Should be fixed now. N |
|
From: John L. <le...@mo...> - 2003-08-10 12:35:14
|
On Sat, Aug 09, 2003 at 05:41:07PM +0100, Nicholas Nethercote wrote: > I've written a new skin for Valgrind. It's called Massif, and does Fix cut and paste problem in the docs. regards john diff -Naur -x Makefile -x .deps -x autom4te-2.53.cache -x config.log -x config.status -x configure valgrind-MASSIF/massif/docs/ms_main.html v/massif/docs/ms_main.html --- valgrind-MASSIF/massif/docs/ms_main.html 2003-08-08 18:52:02.000000000 +0100 +++ v/massif/docs/ms_main.html 2003-08-10 13:51:38.000000000 +0100 @@ -106,12 +106,12 @@ <a name="basicresults"></a> <h3>7.4 Basic Results of Profiling</h3> -Cache profiling is enabled by using the <code>--skin=massif</code> -option to the <code>valgrind</code> shell script. To gather cache profiling +Space profiling is enabled by using the <code>--skin=massif</code> +option to the <code>valgrind</code> shell script. To gather space profiling information about the program <code>date</code>, type: <p> <blockquote> -<code>valgrind --skin=cachegrind date</code> +<code>valgrind --skin=massif date</code> </blockquote> <p> The program will execute (slowly). Upon completion, summary statistics |
|
From: Philippe E. <ph...@wa...> - 2003-08-10 14:17:06
|
Nicholas Nethercote wrote: > Hi, Hi, > You can download a Valgrind bundle containing it from > www.cl.cam.ac.uk/~njn25/valgrind.html. This is the first release, and the example date.gif is missing in the directory www.cl.cam.ac.uk/~njn25/valgrind > although I've tested it reasonably thoroughly (it runs OpenOffice and > Phoenix ok), don't expect too much. I would strongly suggest you read the > docs before using it; they're not very long, they're available in the > main documentation in the bundle (section 7), and also standalone on the > above webpage. I suggest you emphasize than hp2ps is very usefull to interpret results since at first I was not very tempted to download and install haskell. It helped me a lot for learning how to interpret results. > I'd love to hear feedback from anyone who tries it -- if you think it's > useful, if you have any suggestions on how to improve it, if you find any > bugs, or anything else. Thanks. Very nice works, some minor problem with peculiar application: memory use is dominated by obstack in libfd (and stl memory pool too) but it already allowed me to learn this libbfd behavior. Adding a paragraph about pool allocator, garbage collector and obstack which can show different behavior than the naive program expect ? regards, Philippe Elie |
|
From: Nicholas N. <nj...@ca...> - 2003-08-12 16:42:59
|
Hi all, Thanks very much for the feedback so far about Massif. I've put a new version (v0.0.2) up at www.cl.cam.ac.uk/~njn25/valgrind.html. I've also put up there source and binary versions of hp2ps, the graph-producing program, so you don't have to download Glasgow Haskell any more. (Nb: These versions I have put up don't have the minor bug involving the marks on the x-axis.) Changes: - Got rid of the "xNN" names, now using code addresses and function names. This makes the graph more user-friendly. - Fixed this bug (hopefully): Massif: ms_main.c:444 (get_XCon): Assertion `0 == xpt->children[i]->n_children' failed. - Now noticing brk() (included in the "data" count) - Now noticing signal handler stacks (in the "stack(s)" count) - Corresponding documentation changes. More feedback welcome. N |
|
From: Paul A. C. <pa...@us...> - 2003-08-12 22:57:40
|
Does Valgrind support x86-64 executables? I assume x86-32 executables on an x86-64 chip would be supported as normal. (I couldn't find anything specific in the documentation, but I did check first! ;-) Also, has anyone even thought about a port (rewrite?) to the Power/PowerPC architecture? Regards, Paul Clarke |
|
From: Jeremy F. <je...@go...> - 2003-08-13 01:05:51
|
On Tue, 2003-08-12 at 15:42, Paul A. Clarke wrote:
> Does Valgrind support x86-64 executables?
No.
> I assume x86-32 executables on an x86-64 chip would be supported as
> normal.
Yes.
> (I couldn't find anything specific in the documentation, but I did check
> first! ;-)
>
> Also, has anyone even thought about a port (rewrite?) to the
> Power/PowerPC architecture?
Yes.
J
|
|
From: Nicholas N. <nj...@ca...> - 2003-08-12 16:46:22
|
On Sun, 10 Aug 2003, Philippe Elie wrote: > Very nice works, some minor problem with peculiar application: > memory use is dominated by obstack in libfd (and stl memory pool > too) but it already allowed me to learn this libbfd behavior. > Adding a paragraph about pool allocator, garbage collector and > obstack which can show different behavior than the naive program > expect ? Can you give me some more details about this different behaviour? Can you give me example programs that demonstrate it? Thanks. N |
|
From: Philippe E. <ph...@wa...> - 2003-08-12 20:22:57
|
Nicholas Nethercote wrote: > On Sun, 10 Aug 2003, Philippe Elie wrote: > > >>Very nice works, some minor problem with peculiar application: >>memory use is dominated by obstack in libfd (and stl memory pool >>too) but it already allowed me to learn this libbfd behavior. >>Adding a paragraph about pool allocator, garbage collector and >>obstack which can show different behavior than the naive program >>expect ? > > > Can you give me some more details about this different behaviour? Can you > give me example programs that demonstrate it? nervermind, I was confused about program behavior, the memory profile is ok. regards, Phil |
|
From: Stephane D. <ste...@ex...> - 2003-08-11 08:54:03
|
Hello, this new skin is a VERY good idea, I installed it as soon as I saw your message. Unfortunately, when using it with my program, it failed with the following message: Massif: ms_main.c:461 (update_XCon): Assertion `0 != space_delta' failed. sched status: Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 ==9654== at 0x4001A44E: realloc (vg_replace_malloc.c:347) ==9654== by 0x40D00BFC: insert_subtrees_rec (nglib.h:4384) ==9654== by 0x40D00B31: insert_subtrees_rec (create_dispatch.c:142) ==9654== by 0x40CFD39B: EcuUpToDateSet (create_dispatch.c:225) ==9654== by 0x40110791: IsCompiledPackageNotRequiringRecompilation (exafecompil.c:158) when trying another program (a server program, that crashed when creating its first task thread), another assertion failed: Massif: ms_main.c:444 (get_XCon): Assertion `0 == xpt->children[i]->n_children' failed. sched status: Thread 1: status = Sleeping, associated_mx = 0x0, associated_cv = 0x0 ==9899== at 0x40068C51: vgAllRoadsLeadToRome_poll (vg_intercept.c:95) ==9899== by 0x40068D03: __poll (vg_intercept.c:366) ==9899== by 0x40069A37: vgAllRoadsLeadToRome_wait_for_fd_to_be_readable_or_er ring (vg_intercept.c:883) ==9899== by 0x40068F0A: vgAllRoadsLeadToRome_accept (vg_intercept.c:481) ==9899== by 0x40068F99: accept (vg_intercept.c:488) ==9899== by 0x40120F77: TCPServerAccept (ngtcp.c:1484) ==9899== by 0x409C4F14: NGServerStart (server/ngserver.c:2604) ==9899== by 0x8066E7B: main (ngindex.c:709) ==9899== by 0x40AB77F6: __libc_start_main (in /lib/i686/libc-2.3.1.so) ==9899== by 0x804E400: (within /ng/src/donze/ng/bin/intel-linux/exe/ngindex) Thread 2: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 ==9899== at 0x4001A34A: calloc (vg_replace_malloc.c:321) ==9899== by 0x40CFCED5: zcalloc (in /lib/libz.so.1.1.4) don't hesitate to ask me for more precise information if needed. Regards, -- Stephane Donze On Sat, 2003-08-09 at 18:41, Nicholas Nethercote wrote: > Hi, > > I've written a new skin for Valgrind. It's called Massif, and does > detailed space (memory) profiling. AFAIK, it is, astonishingly enough, > the first decent tool anyone has made for profiling C and C++ programs -- > I'm not aware of any others that give anything like as much information as > Massif does. (If you know of any, I'd like to hear about them.) > > You can download a Valgrind bundle containing it from > www.cl.cam.ac.uk/~njn25/valgrind.html. This is the first release, and > although I've tested it reasonably thoroughly (it runs OpenOffice and > Phoenix ok), don't expect too much. I would strongly suggest you read the > docs before using it; they're not very long, they're available in the > main documentation in the bundle (section 7), and also standalone on the > above webpage. > > I'd love to hear feedback from anyone who tries it -- if you think it's > useful, if you have any suggestions on how to improve it, if you find any > bugs, or anything else. Thanks. > > N > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Nicholas N. <nj...@ca...> - 2003-08-11 11:47:33
|
On 11 Aug 2003, Stephane Donze wrote: > this new skin is a VERY good idea, I installed it as soon as I saw your > message. Unfortunately, when using it with my program, it failed with > the following message: > > Massif: ms_main.c:461 (update_XCon): Assertion `0 != space_delta' > failed. Ah, that one was straightforward, I've put a new tarball up at www.cl.cam.ac.uk/~njn25/valgrind/valgrind-MASSIF.tar.bz2 that should fix this problem. [OT] Just as an aside, can anyone explain to me the use of allocating a heap block of size zero? It seems to be quite common, but I don't know why... the only reason I can think of is that it's a cheap way to get a unique address. > when trying another program (a server program, that crashed when > creating its first task thread), another assertion failed: > > Massif: ms_main.c:444 (get_XCon): Assertion `0 == xpt->children[i]->n_children' failed. This one's harder to diagnose. Are you able to send me a copy of your program, or a cut-down version? It will be very difficult for me to work out the problem otherwise. Thanks very much for the bug reports, I'm glad this tool is useful to you. N |
|
From: Tom H. <th...@cy...> - 2003-08-11 12:07:42
|
In message <Pin...@gr...>
Nicholas Nethercote <nj...@ca...> wrote:
> [OT] Just as an aside, can anyone explain to me the use of allocating a
> heap block of size zero? It seems to be quite common, but I don't know
> why... the only reason I can think of is that it's a cheap way to get a
> unique address.
It isn't actually a good way of getting a unique address, as
the C standard allows malloc to return NULL when asked for a block
of size zero, and some implementations do that. This is usually
not something you would notice as calling free or realloc on a null
pointer is also required to work by the C standard.
You're right that it doesn't generally sense to explicitly allocate
zero bytes, but it often arises as an edge case in a general purpose
algorithm where a routine is a given a size of some sort and allocates
a buffer of that size and just sometimes the size will be zero.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Joerg B. <jo...@we...> - 2003-08-11 13:08:10
|
Nicholas Nethercote wrote: > On 11 Aug 2003, Stephane Donze wrote: > > >>this new skin is a VERY good idea, I installed it as soon as I saw your >>message. Unfortunately, when using it with my program, it failed with >>the following message: >> >>Massif: ms_main.c:461 (update_XCon): Assertion `0 != space_delta' >>failed. > > > Ah, that one was straightforward, I've put a new tarball up at > www.cl.cam.ac.uk/~njn25/valgrind/valgrind-MASSIF.tar.bz2 that should fix > this problem. Nicholas, I donwloaded and built it (works fine on SuSE 8.1, gcc-3.2) and tried it on a large program (largs in mem usage, it needs about 30M without valgrind). Thats fine, but I have little trouble in reading the results. This is what I get in the hp.pid.txt file: Heap allocation functions accounted for 99.4% of measured spacetime Called from: 78.6% : x793 : 0x4142590C: std::__default_alloc_template<true, 0>::allocate(unsigned) (in /usr/lib/libstdc++.so.5.0.0) 8.2% : x11C : 0x41425E01: std::__default_alloc_template<true, 0>::_S_chunk_alloc(unsigned, int&) (in /usr/lib/libstdc++.so.5.0.0) What are "x793" and "x11C" ? I read the documentation, please tell me which part of it describes these names. thanks Joerg |
|
From: Nicholas N. <nj...@ca...> - 2003-08-11 13:24:01
|
On Mon, 11 Aug 2003, Joerg Beyer wrote: > Thats fine, but I have little trouble in reading the results. > This is what I get in the hp.pid.txt file: > > Heap allocation functions accounted for 99.4% of measured spacetime > > Called from: > 78.6% : x793 : 0x4142590C: std::__default_alloc_template<true, > 0>::allocate(unsigned) (in /usr/lib/libstdc++.so.5.0.0) > > 8.2% : x11C : 0x41425E01: std::__default_alloc_template<true, > 0>::_S_chunk_alloc(unsigned, int&) (in /usr/lib/libstdc++.so.5.0.0) > > > What are "x793" and "x11C" ? I read the documentation, please > tell me which part of it describes these names. Section 7.5 says: Each "xNN" band represents a single line of your program that does some heap allocation; that band represents all the allocations and deallocations done from that line. The actual names are meaningless, but it's necessary to have a name for each allocation site so you can search back and forth for them. Search for "x793" and "x11C" in the output file, you'll see the same allocation site appearing with more detail the further down the file you go. If the documentation doesn't explain this adequately and you can see how to improve it, please let me know -- it's hard for me to judge the clarity of the documentation clearly, it's obvious to me how Massif works :) N |
|
From: Joerg B. <jo...@we...> - 2003-08-11 13:45:38
|
Nicholas Nethercote wrote:
> Section 7.5 says:
>
> Each "xNN" band represents a single line of your program that does some
> heap allocation; that band represents all the allocations and
> deallocations done from that line.
>
> The actual names are meaningless, but it's necessary to have a name for
> each allocation site so you can search back and forth for them. Search
> for "x793" and "x11C" in the output file, you'll see the same allocation
> site appearing with more detail the further down the file you go.
>
> If the documentation doesn't explain this adequately and you can see how
> to improve it, please let me know -- it's hard for me to judge the clarity
> of the documentation clearly, it's obvious to me how Massif works :)
>
> N
It might help, change this:
Each "xNN" band represents a single line of your program that does some
heap allocation.
into :
Each "xNN" band represents a single line of your program that does some
heap allocation. The name "xNN" is just a dummy for reference, it has
no (hidden or deeper ) meaning.
I confused me, that there are no file:lineno positions, but that is
clear (now) to me, since the used library (libstdc++) has no debugging
symbols. My sources are dumped with this positions and I can track the
libstdc++ usage back to my sources.
I have a line in the output, that looks like this:
Called from:
39.9% : ???: 0x4046BD6A: std::_Vector_alloc_base<xalanc_1_5::XToken,
std::allocator<xalanc_1_5::XToken>, true>::_M_allocate(unsigned)
(/usr/include/g++/bits/stl_vector.h:121)
Do you know, why there is "???" printed instead of a name?
Really a nice skin and I will track some mem usage down to the
application code. something you simply cant do without this skin.
Joerg
|
|
From: Nicholas N. <nj...@ca...> - 2003-08-11 14:09:34
|
On Mon, 11 Aug 2003, Joerg Beyer wrote: > It might help, change this: > Each "xNN" band represents a single line of your program that does some > heap allocation. > > into : > Each "xNN" band represents a single line of your program that does some > heap allocation. The name "xNN" is just a dummy for reference, it has > no (hidden or deeper ) meaning. Ok, will do. > I have a line in the output, that looks like this: > Called from: > 39.9% : ???: 0x4046BD6A: std::_Vector_alloc_base<xalanc_1_5::XToken, > std::allocator<xalanc_1_5::XToken>, true>::_M_allocate(unsigned) > (/usr/include/g++/bits/stl_vector.h:121) > > Do you know, why there is "???" printed instead of a name? Depending on the --depth command line argument, the information is only collected on stack traces of a certain depth. Beyond this depth no information is collected. The "???" represents that there is no more information beyond this level (presumably you will have navigated down from the top-level context down through a couple of levels to get to this point). But yes, it is confusing, especially since "???" is also used in the code address descriptions. I will change it and make the documentation clearer. Thanks for the feedback. N |
|
From: Joerg B. <jo...@we...> - 2003-08-11 14:23:01
|
Nicholas Nethercote wrote:
> On Mon, 11 Aug 2003, Joerg Beyer wrote:
>
>
>>It might help, change this:
>>Each "xNN" band represents a single line of your program that does some
>>heap allocation.
>>
>>into :
>>Each "xNN" band represents a single line of your program that does some
>>heap allocation. The name "xNN" is just a dummy for reference, it has
>>no (hidden or deeper ) meaning.
>
>
> Ok, will do.
I now downloaded the haskell visualisation tool, that you use to
make images, that show where memory is allocated or freed and
how costly that is. In the image it would be easier to read,
if the labels where a location (file:lineno) instead of
"xNN"-dummy names.
On the other hand: one could still look them up in
the hp.pid.txt-file.
Joerg
|
|
From: <ste...@ex...> - 2003-08-27 20:35:26
|
Hello, when trying to convert a hp file produced by massif, I get the following message: $ hp2ps hp.25447.hp hp2ps: hp.25447.hp, line 11: integer unexpected any idea ? I tryed Haskell's hp2ps and the version you put on your page, and both versions (maybe it's the same ?) failed. here is the head of my .hp file: JOB "/ng/src/donze/ng/bin/intel-linux/exe/exa -free -p exa.lang (32 ms/ sample)" DATE "(time and date)" SAMPLE_UNIT "ms" VALUE_UNIT "bytes" MARK 3.0 BEGIN_SAMPLE 3.0 stack(s) 2820 END_SAMPLE 3.0 MARK 36.0 BEGIN_SAMPLE 36.0 0x40A717AF:get_or_allocate 200 heap-admin 8 stack(s) 3980 END_SAMPLE 36.0 MARK 68.0 BEGIN_SAMPLE 68.0 0x402CECB9:ChannelNew 23444 0x40A717AF:get_or_allocate 200 0x40DE68D9:HashMalloc 207 0x402DCCA8:NGDigestNew 104 0x40DE6C0E:HashTableNew 52 Stephane |
|
From: Olivier C. <oli...@fr...> - 2003-08-27 21:48:23
|
On Wed, Aug 27, 2003 at 10:35:26PM +0200, Stéphane Donzé wrote: > Hello, > > when trying to convert a hp file produced by massif, I get the following > message: > > $ hp2ps hp.25447.hp > hp2ps: hp.25447.hp, line 11: integer unexpected > > any idea ? I tryed Haskell's hp2ps and the version you put on your page, > and both versions (maybe it's the same ?) failed. > I get the same problem. A (tmp?) fix: [olivier@snoopy olivier]$ perl -ne 's/.*://; print' hp.25447.hp> fixedhp.25447.hp [olivier@snoopy olivier]$ hp2ps -c -t0 fixedhp.25447.hp [olivier@snoopy olivier]$ gv -seascape -scalebase 2 fixedhp.25447.ps & Regards, Olivier |
|
From: Nicholas N. <nj...@ca...> - 2003-08-28 06:35:50
|
On 27 Aug 2003, St=E9phane Donz=E9 wrote: > $ hp2ps hp.25447.hp > hp2ps: hp.25447.hp, line 11: integer unexpected > > any idea ? I tryed Haskell's hp2ps and the version you put on your page, > and both versions (maybe it's the same ?) failed. It was a problem with Massif rather than hp2ps. It's been fixed, please try the latest version at www.cl.cam.ac.uk/~njn25/valgrind/valgrind-MASSIF.tar.bz2. Sorry for the inconvenience. N |
|
From: <ar...@fl...> - 2003-08-11 14:31:34
|
Would it be possible to make a backport of massif to work along with the latest stable version of valgrind (20039725)? I tried to put together massif and crocus with this version and I got relocations errors. It will be great to have these skins available to the stable version for being packaged for some GNU/Linux distributions like Debian. Thanks in advance. Nicholas Nethercote <nj...@ca...> writes: > Hi, > > I've written a new skin for Valgrind. It's called Massif, and does > detailed space (memory) profiling. AFAIK, it is, astonishingly enough, > the first decent tool anyone has made for profiling C and C++ programs -- > I'm not aware of any others that give anything like as much information as > Massif does. (If you know of any, I'd like to hear about them.) > > You can download a Valgrind bundle containing it from > www.cl.cam.ac.uk/~njn25/valgrind.html. This is the first release, and > although I've tested it reasonably thoroughly (it runs OpenOffice and > Phoenix ok), don't expect too much. I would strongly suggest you read the > docs before using it; they're not very long, they're available in the > main documentation in the bundle (section 7), and also standalone on the > above webpage. > > I'd love to hear feedback from anyone who tries it -- if you think it's > useful, if you have any suggestions on how to improve it, if you find any > bugs, or anything else. Thanks. > > N > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users -- Andres Roldan <ar...@fl...> http://people.fluidsignal.com/~aroldan CSO, Fluidsignal Group |
|
From: Nicholas N. <nj...@ca...> - 2003-08-11 14:12:34
|
On Mon, 11 Aug 2003, Andr=E9s Rold=E1n wrote: > Would it be possible to make a backport of massif to work along with the > latest stable version of valgrind (20039725)? I tried to put together > massif and crocus with this version and I got relocations errors. It will > be great to have these skins available to the stable version for being > packaged for some GNU/Linux distributions like Debian. Unfortunately not, to get Massif working required some minor changes to valgrind-20039725. However, it wouldn't be hard to work those minor changes into the next release of Valgrind (which will probably be in the next couple of weeks or so), and then Massif could be packaged up with it. Although I don't think Massif deserves the description "stable" yet :) N |
|
From: Steve G <lin...@ya...> - 2003-08-12 00:34:31
|
>>I tried to put together massif and crocus with this >>version and I got relocations errors. <snip> >However, it wouldn't be hard to work those minor changes >into the next release of Valgrind and then Massif could >be packaged up with it. Although I don't think Massif >deserves the description "stable" yet :) I was starting to wonder what the status of crocus was, too. I think that one is stable enough to be rolled out as is. After a few rounds of comments, I think you can accelerate the maturity of Massif by distributing it with valgrind so that people have easier access to it. You basically have to be a subscriber to this mail list just to know about these extra skins unless Julian has linked your home page to the valgrind web site. I understand the caution with rolling it out, but to get thorough testing...people have to have an easy way to find it. Best Regards, Steve Grubb __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com |