Hi,
This is regarding Dtrace usability for memory leak detection.
We have real-time application written C++ which runs on Solaris 10
having a problem that's the my application grows in size from 130 Mb
to 450Mb in around 15 days.
So there is two possibilities with the application growth of memory
due to Size growth of Dictionary Objects (Like Maps) and Memory Leak.
(Dictionary Objects we can print the size but its live production
site where the problem is happening also there are many such object
used the application)
When I used Dtrace and libumem ( with mdb )to detect memory leak for
C++ code.
When I tried to run dtrace script available in SUN Site it stops
abruptly
With following error
# dtrace -s ./CCagg_1.d `pgrep scadadbproc` | c++filt >>
scadadbproc_dtrace
dtrace: 91102 drops on CPU 0
dtrace: processing aborted: Abort due to systemic unresponsiveness
While suing mdb ( ::findleaks )
It says no memory allocation done and says no leaks found.
1) Is there any way where I can restrict dtrace to look for probe only
certain source files or functions?
2) Is there any way to handle such problems?
3) I got a clue of using "libgc.so" which acts as garbage collector is
there any problem in using and how reliable and effective is this.
( it works fine on sample application but not improvement in real
application ) . I just linked the library "libgc.so" at compile time ?
Anything else need to done for this ?
Your inputs will be highly appreciated. Please do share your thoughts
and techniques.
Thanks & Regards
S L Srikant
SCADA Business Unit
Invensys Development Centre India Pvt. Ltd.
S-210, Plot # 17, Orion Building, Block J
Vanenburg IT Park, Software Units Layout
Madhapur, Hyderabad - 500 081.
Hi Jim,
Thanks you for the inputs .
I am trying with libumem based on the results I will post on
[email protected] .
Once again thank you very much.
rgds
Subject: Re: Regarding DTrace.
Hello - I'd recommend posting to a broader audience. You'll get more
people with a lot of expertise. [EMAIL PROTECTED]
The machine you are running on must be very busy. DTrace implements
a watchdog mechanism to determine if the system is getting extremely
slow
or hung. If dtrace detects an unresponsive system (which it did in your
case),
it will exit. You have three options here:
1. Run the code in a test enviroment on a machine that is less busy.
2. Run dtrace in destructive mode. This disables the watchdog function.
(check the dtrace manual for how to do this).
3. Do not use dtrace to troubleshoot this memory leak - use libumem.
Thanks,
/jim
Sana, Srikant wrote:
> Hi Jim ,
>
> Thanks you very much for the inputs.
>
> I just tried with dtrace but it gives the following error after
> running
> for 2 mins and the size of the output file generated is also around
> 9MB.
>
> # dtrace -s ./CCagg_1.d `pgrep scadadbproc` | c++filt >>
> scadadbproc_dtrace
> dtrace: 91102 drops on CPU 0
> dtrace: processing aborted: Abort due to systemic unresponsiveness
>
> I tried analyzing the output file which where memory allocation is
done
> and freed.
>
> The memory leak happens in a particular in scenario but the script get
> aborted immediately, the issue is we don't when the leak happens to
> identify that we have to run the tool on continuous manner without
> interruption.
>
> Please let me know how I can achieve this.
>
>
> Thanks & Regards
> S L Srikant
>
> SCADA Business Unit
> Invensys Development Centre India Pvt. Ltd.
> S-210, Plot # 17, Orion Building, Block J
> Vanenburg IT Park, Software Units Layout
> Madhapur, Hyderabad - 500 081.
>
> Phone: +91 40 66399721
> Fax: +91 40 66689000
> Mobile: +91 9849666508
>
> eMail: [EMAIL PROTECTED]
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, May 21, 2008 4:33 AM
> To: Sana, Srikant
> Subject: Re: Regarding DTrace.
>
> Hello - there's a good developers article on using dtrace to find
memory
>
> leaks
> in C++ code here:
>
> http://developers.sun.com/solaris/articles/dtrace_cc.html
>
> There's also an alternate malloc implementation in Solaris 10 called
> libumem.
> If you link to libumem (just use LD_PRELOAD), it will do heap
management
> out of libumem instead of libc, and libumem offers some very nice
> features
> for chasing memory leaks. You can read how to do this here:
>
> http://access1.sun.com/techarticles/libumem.html
>
> The two WEB sites referenced above speak directly to what you're
looking
> for, much better than I could so with a long email loaded with
examples.
> ;^)
>
> Hopefully, these tools will help you isolate your memory leak problem.
>
> Thanks,
> /jim
>
>
>
> Sana, Srikant wrote:
>
>> Hi James,
>>
>> This is regarding Dtrace usability for memory leak detection.
>>
>> I read you article on "Solaris 10 & Open Solaris Performance,
>> Observability & Debugging " found very interesting for my problem.
>>
>> We have real-time application written C++ which runs on Solaris 10 (
>> SPARC based ) , having a problem that's the process( application )
>> grows in size from 130 Mb to 450Mb in around 10 days.
>>
>> So there is two possibilities with the application growth of memory
>> due to Size growth of Dictionary Objects (Like Maps) and Memory Leak.
>>
>> 1) How Dtrace can help to identify the problem .
>>
>> (Dictoionary Objects we can print the size but its live production
>> site where the problem is happening also there are many such object
>> used the application)
>>
>> 2) How I can use Dtrace to detect memory leak for C++ code. Can I
have
>>
>
>
>> few examples on it.
>>
>> 3) Also is there any way to handle such problems.
>>
>> I got a clue of using "libgc.so" which acts as garbage collector is
>> there any problem in using and how reliable and effective is this.
>>
>> I righting directly to you without any support since we are in great
>> hurry to resolve the issue.
>>
>> Your inputs will be highly appreciated. Please do share your thoughts
>> and techniques.
>>
>> Thanks & Regards
>>
>> S L Srikant
>>
>> SCADA Business Unit
>> Invensys Development Centre India Pvt. Ltd.
>> S-210, Plot # 17, Orion Building, Block J
>> Vanenburg IT Park, Software Units Layout
>> Madhapur, Hyderabad - 500 081.
>>
>> Phone: +91 40 66399721
>> Fax: +91 40 66689000
>> Mobile: +91 9849666508
>>
>> eMail: [EMAIL PROTECTED]
>> <mailto:[EMAIL PROTECTED]>
>>
>>
>> *
>>
>>
>
------------------------------------------------------------------------
>
>> ** Confidential Notice: *This e-mail and any associated files are
>> intended solely for the individual or entity to whom they are
>> addressed. Please do not copy it or use it for any purposes, or
>> disclose its contents to any other person. Further, this e-mail and
>> any associated files may be confidential and further may be legally
>> privileged. This email is from the Invensys Process Systems business
>> unit of Invensys plc which is a company registered in England and
>> Wales with its registered office at Portland House, Bressenden Place,
>> London, SW1E 5BF (Registered number 166023). For a list of European
>> legal entities within the Invensys Process Systems business group,
>> please click here
>>
>>
>
http://www.invensys.com/legal/default.asp?top_nav_id=77&nav_id=80&prev_i
> d=77
>
>
<http://www.invensys.com/legal/default.asp?top_nav_id=77&nav_id=80&prev_
> id=77>.
>
>> If you have received this e-mail in error, you are on notice of its
>> status. Please notify us immediately by reply e-mail and then delete
>> this message from your system. Thank you for your co-operation. You
>> may contact our Helpdesk on +44 (0)20 7821 3859 / 2105 or email
>> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>.
>> This e-mail and any attachments thereto may be subject to the terms
of
>>
>
>
>> any agreements between Invensys (and/or its subsidiaries and
>> affiliates) and the recipient (and/or its subsidiaries and
>>
> affiliates).
>
>
------------------------------------------------------------------------
>
>>
>
>
> * Confidentiality Notice:
> This e-mail and any associated files are intended solely for the
individual or entity to whom they are addressed. Please do not copy it
or use it for any purposes, or disclose its contents to any other
person. Further, this e-mail and any associated files may be
confidential and further may be legally privileged. This email is from
the Invensys Process Systems business unit of Invensys plc which is a
company registered in England and Wales with its registered office at
Portland House, Bressenden Place, London, SW1E 5BF (Registered number
166023). For a list of European legal entities within the Invensys
Process Systems business group, please click here
http://www.invensys.com/legal/default.asp?top_nav_id=77&nav_id=80&prev_i
d=77.
>
> If you have received this e-mail in error, you are on notice of its
status. Please notify us immediately by reply e-mail and then delete
this message from your system. Thank you for your co-operation. You may
contact our Helpdesk on +44 (0)20 7821 3859 / 2105 or email
[EMAIL PROTECTED] This e-mail and any attachments thereto
may be subject to the terms of any agreements between Invensys (and/or
its subsidiaries and affiliates) and the recipient (and/or its
subsidiaries and affiliates).
>
>
>
* Confidentiality Notice:
This e-mail and any associated files are intended solely for the individual or
entity to whom they are addressed. Please do not copy it or use it for any
purposes, or disclose its contents to any other person. Further, this e-mail
and any associated files may be confidential and further may be legally
privileged. This email is from the Invensys Process Systems business unit of
Invensys plc which is a company registered in England and Wales with its
registered office at Portland House, Bressenden Place, London, SW1E 5BF
(Registered number 166023). For a list of European legal entities within the
Invensys Process Systems business group, please click here
http://www.invensys.com/legal/default.asp?top_nav_id=77&nav_id=80&prev_id=77.
If you have received this e-mail in error, you are on notice of its status.
Please notify us immediately by reply e-mail and then delete this message from
your system. Thank you for your co-operation. You may contact our Helpdesk on
+44 (0)20 7821 3859 / 2105 or email [EMAIL PROTECTED] This e-mail and any
attachments thereto may be subject to the terms of any agreements between
Invensys (and/or its subsidiaries and affiliates) and the recipient (and/or its
subsidiaries and affiliates).
_______________________________________________
dtrace-discuss mailing list
[email protected]
