Fletcher,
If the page scanner is running, and or you have anonymous paging
(vmstat -p)
then it is RSS that is part of your problem.
If you are interested in further leak analysis see
http://developers.sun.com/solaris/articles/libumem_library.html
if you want your leaks to magically disappear see
h
Am using the latest version of DtraceTool-kit 0.99 and getting these errors on
the tcptop and tcptop_snv scripts.
tcptop: tcp_q_g - Unknown Symbol Name.
tcptop_snv :probe description fbt:ip:tcp_xchg:entry does not match any probes
I have verified that the scripts are latest based on the dicusss
Hi Brendan,
I have been trying to get the tcptop script working on one of our servers. Its
givin me the same issue whcih has been reported earlier . I am using Solaris
5.10 /i86pc. The error is the "tcp_q_g Unable to resolve symbol error" .
I have verified it for the latest version based on
My original posts were to the dtrace list and the mailman list
"Python process size grows 30x in 8 hours (memory leak?) "
and I did not assume it would be a memory leak, but suspected it could be.
I did a pmap early on - posted to the mailman group - it shows the heap is
the portion growing - but
Fletcher,
libc malloc being called or not only had to do with the
naming of your probe.
Looking at your configure options :
--with-pymalloc
This imples to me that python has his own malloc.
I do not recall, but why do you think you have a memory leak ?
Just because the process grows over time and
Ok, maybe this is significant in the context of explaining why my python
(mailman) processes seem to grow abnormally?
If the libc malloc is not being called, why and is that an important issue?
[EMAIL PROTECTED]:~ 2:17pm 54 # ldd /bin/python
libresolv.so.2 =>/lib/libresolv.so.2
Yes, removing libc.so.1
Output ! - now to analyze the output I will bring in my parallel
mailman-users' thread folks :) - having the stack trace is awesome by
itself...
thanks
0 42246 realloc:return Ptr=0x824c268 Oldptr=0x0 Size=16
libc.so.1`realloc+0x33a
The below command should list all the available probemod and probefunc
combination. Check if malloc is listed and if so against which
probemod is it listed.
$ dtrace -lv pid$target:::enter -p
-Shiv
On Wed, Jul 2, 2008 at 8:16 PM, rickey c weisner <[EMAIL PROTECTED]> wrote:
> Fletcher,
> This lo
Fletcher,
This looks suspicious. Perhaps your malloc is not in libc ?
> [690] | 0| 0|FILE |LOCL |0|ABS|obmalloc.c
remove the libc.so.1 from your probe description.
rick
On Wed, Jul 02, 2008 at 07:23:49AM -0700, Fletcher Cocquyt wrote:
> Date: Wed, 02 Jul 2008 07:23:49 -0700
Sanjeev, I get this with your new version:
[EMAIL PROTECTED]:~ 7:26am 64 # ./memleak2.d 7560
dtrace: failed to compile script ./memleak2.d: line 3: probe description
pid7560:libc.so.1:malloc:0 does not match any probes
[EMAIL PROTECTED]:~ 7:27am 65 # ps -ef | grep 7560
mailman 7560 718 0 06
Looks OK:
[EMAIL PROTECTED]:~ 7:22am 60 # !nm
nm /bin/python | egrep malloc
[3597] | 134599012| 0|FUNC |GLOB |0|UNDEF |malloc
[690] | 0| 0|FILE |LOCL |0|ABS|obmalloc.c
On 7/2/08 6:11 AM, "rickey c weisner" <[EMAIL PROTECTED]> wrote:
> Fletcher,
> First confi
Right, dtrace does not have an if-then-else construct. Try this:
fbt:mydriver:curiousfunction:entry{
self->follow = timestamp;
self->spec = speculation();
}
fbt:mydriver:curiousfunction:return
/self->spec && self->follow && (timestamp - self->follow) > 80/
{
speculate(self
Thanks for your idea,
the "if" statement in the dtrace code causes a syntax error on
my machine?
Sigi
--
This message posted from opensolaris.org
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
Just as a follow up, it appears that calling speculate with a value
that does not represent a currently active speculation buffer
terminates the current probe clause. No error, just ends the clause at
that point.
Brian Utterback wrote:
> After my last foray into speculations while diagnosing a
Fletcher,
First confirm that malloc is in your binary.
arwen:nm a.out | grep malloc
[70]| 134547228| 0|FUNC |GLOB |0|UNDEF |malloc
Then key on any malloc.
Something like:
pid$target::malloc:return,
pid$target::memalign:return,
pid$target::realloc:return,
pid$target::valloc:return
Fletcher,
Mark Durney hit similar problem and while I was working with him and
talking to
my colleague he pointed out that we could use "function:offset" notation
when we
are using pid-provider.
So, I have modified the script to enable the first instruction of malloc.
Attached is the script.
Fletcher,
You could attach mdb to the running process and disassemble the routine
in question :
-- snip --
# mdb -p
> malloc::dis
libc.so.1`malloc: pushl %ebp
libc.so.1`malloc+1: movl %esp,%ebp
libc.so.1`malloc+3: pushl %ebx
libc.so.1`malloc+4:
17 matches
Mail list logo
