> I have tried using umem (First set some environment variables, then > run the program, then "gcore pid_of_program", then "mdb gcore_xxx" ) > to detect memory leak with a simple test program, but it didn't find > any memory leak but it should find.
This does not sound right, but it's outside of the scope of this thread.
I am curious, if you want send me the source privately.
> Come back to the original dtrace issue. I don't want to use file
> system or pipe ( in nature it use file system ? ) because in
> performance test, the application has many many memory operations
> (malloc or free), and the D script will output a big amount of
> information (ustack is big ).
I found in some situations that using gzip on dtrace output let me
collect huge amount of data quickly.
dtrace -n ' ... ' | gzip -c > file
> This big amount information need to be analyzed by another program
> (since D script itself cannot save stack information keyed by some
> value e.g. returned address ). The analysis program store the memory
> allocation infomation <returned address, stack>, when free() is
> called the corresponding information is deleted. When application
> terminates, the leaked memory information is saved in the analysis
> program.
I would still try to use another solution, for example valgrind is
excellent tool (actually I'm not sure how excellent it is on Solaris,
but on Linux it works more then well).
> So the critical issue is how to efficiently pass the output data from
> the D script to the analysis program.
You could also use drace | gzip -c > /tmp/file, where /tmp is ramdisk.
That's what just crossed my mind, I hope it helps.
--
Vlad
pgpbosj9PRYIM.pgp
Description: PGP signature
_______________________________________________ dtrace-discuss mailing list [email protected]
