Shiv, S h i v wrote: > Hi Sanjeev, > > I have attached a script that does some more processing on the dtrace > output to provide more information in the summary. > > Thanks !
> On Mon, Jun 30, 2008 at 7:04 PM, Sanjeev Bagewadi > <[EMAIL PROTECTED]> wrote: > >> I have a simple script for the userland and the details are available on >> my blog : >> http://blogs.sun.com/sanjeevb/ >> >> The script is fairly rudimentary and I have intentionally avoided any >> processing during collection. >> All the intelligence is in the postprocessing Perl script. >> >> Probably there is room for optimization but, need to explore them. >> >> Hope they are of use. >> >> > > In the dtrace output using the dtrace script I see instances of malloc > for a pointer(at a location) happening more than once without a free. > See example below. What to make of this? How can malloc return a > pointer location that was already returned by an earlier call to > malloc? > (this is for an actual application, I donot have a sample program that > can reproduce this scenario) > > malloc:return tid=1 ptr=<ptr-value> size=48 > <ustack_1> > ....few lines without free..... > malloc:return tid=1 ptr=<*same* ptr-value> size=86 <- same memory > location > <different_ustack> > ....few lines.... > free:entry ptr=<ptr-value> > Need to doublecheck.. probably this was a realloc(). Or did you notice a drop during that period ? The drop would explain the missing free... Thanks again for the enhancements !! Regards, Sanjeev. > > I had used your dtrace script and had found it to be quite useful. > Since the logs that used to be collected were often huge, the level of > detail perl script output provided wasn't sufficient. > The attached script (python) does little more work. > Ofcourse some more optimizations and still better reporting is possible. > For ex: I see some stacks in our app leak sporadically under heavy > load due to call drops and alternate execution paths that get > triggered. Such stacks aren't *always leaky*. This information can be > captured in the output. > > ======================================================= > > ERROR line: <lineno> : Freeing non-existant memory at <ptr-value> > LEAK <nnn> bytes leaked. Allocated at line <line1> ptr <ptr-value> is > re-alloced at line <line2> > ......multiple lines as above....... > ======================================================= > INFO Leaks along with stack information is as follows: > ======================================================= > Stack position (line no.): <line1> <line2> <line3>... > Pointers: <ptr1> <ptr2> <ptr3> ... > Size leaked: <bytes1> <bytes2> <bytes3> > Total size leaked: sumof(<bytes1> <bytes2> <bytes3> ...) > N(stack executions): <no of times the leaky stack got executed> > > STACK IS: > <actual-stack> > ......multiple stack info as above.... > > > > In the malloc related query, I was referring to the output line "LEAK > <nnn> bytes leaked. Allocated at line <line1> ptr <ptr-value> is > re-alloced at line <line2>" > This output is when there are 2 mallocs at <line1> and <line2> in the > dtrace output without a intermediate free. > > -Shiv > > ------------------------------------------------------------------------ > > _______________________________________________ > dtrace-discuss mailing list > [email protected] -- Solaris Revenue Products Engineering, India Engineering Center, Sun Microsystems India Pvt Ltd. Tel: x27521 +91 80 669 27521 _______________________________________________ dtrace-discuss mailing list [email protected]
