RE: seeing memory leak in cimprovagt process

Karl Schopmeyer <[email protected]>
Newsgroups gmane.network.open-pegasus.general
Message-ID <[email protected]>
Note that there are still some memory issues in Pegasus shutdown so 
that this may be some of what you are seeing.  To separate these out, 
simply start and stop the server. with valgrind running. That will 
give you a clue what things valgrind reports with without your 
provider being called.

Second, you might be better to test the provider in out-of-process 
mode where you are running valgrind only on the particular provider 
and OOP agent to determine if the error is from the provider or agent 
vs. the server.
If you have issues setting this up, there is an example of a script 
to run valgrind on just cimprovagt by replacing cimprovagt executable 
with a script like the following


#!/bin/sh
## Original Author: Tim Potter
# move cimprovagt to cimprovagt.real
# move this file to cimprovagt
#
# mv /usr/sbin/cimprovagt /usr/sbin/cimprovagt.real
# cp cimprovagt.wrapper /usr/sbin/cimprovagt
## By default the script doesn't call valgrind - enable it by
## creating a semaphore file of the form /tmp/$MODULE.valgrind where module
## is the module name in the output of "cimprovider -l".
## Or create a file /tmp/LogAll.valgrind which valgrinds all providers.
module=$5
VALGRIND_ARGS="--leak-check=yes --trace-children=yes 
--log-file=/tmp/$module.valgrind"
if [ -e /tmp/$module.valgrind -o -e /tmp/LogAll.valgrind ]; then
         exec /usr/bin/valgrind $VALGRIND_ARGS \
       /usr/sbin/cimprovagt.real "$@"
else
         exec /usr/sbin/cimprovagt.real "$@"
fi

Karl

Thanks for your message at 06:14 AM 8/7/2012. Your message was:
>Hi All,
>
>Thanks for all of your response.
>We have configured cimserver "forceProviderProcesses=false", so that 
>all the provider processes will be in the same context.
>Now, we run "Valgrind" for cimserver process. And then, we have 
>generated one event for our provider and stop the cimserver process after that.
>
>Then from "Valgrind" memory leak report, we can see many definitely 
>lost memory issue are coming from Pegasus. Please check the attached 
>file for details of it. Is this a known issue?
>
>Please give your valuable input. Thanks in advance.
>
>Regards,
>Pialy
>
>
>
>From: Devchandra Leishangthem [mailto:[email protected]]
>Sent: Friday, August 03, 2012 9:52 PM
>To: Pialy Ghosh (WT01 - Manufacturing & Hi Tech)
>Cc: Anirban Bhattacharyya (WT01 - Product Engineering Services); 
>[email protected]
>Subject: Re: seeing memory leak in cimprovagt process
>
>Is the leak seen in a particular cimprovagt or for all the provider 
>processes?
>If It is seen in some particular agent processes, Then most probably 
>it is leak in the corresponding provider.
>See if running under a memory debugger helps for that particular agt 
>processes.
>
>Warm Regards
>D>L> Meetei
>9538270270
>IBM
>
>IBM India Software Lab, STG
>6th Floor, A0202,
>EGL -D,Bangalore, India
>
>
>
>From:        <[email protected]>
>To:        <[email protected]>,
>Cc:        <[email protected]>
>Date:        08/03/2012 05:37 PM
>Subject:        seeing memory leak in cimprovagt process
>
>
>
>
>Hi,
>
>We are seeing some memory leak in cimprovagt process. We are running 
>open Pegasus, cimserver in a windows 64 bit OS. Our provider is 
>running on cimserver.
>After few days long run we can see, memory usages is increased. I 
>have searched in internet and find out same kind of problem is 
>mentioned by others also. So, just wanted to know, is this a known 
>issue in Pegasus? If not, then we will come to know that, issue is 
>coming from our provider.
>
>Your valuable input will be very helpful for us to analyze the issue.
>
>Thanks & Regards,
>Pialy
>
>
>
>Please do not print this email unless it is absolutely necessary.
>
>The information contained in this electronic message and any 
>attachments to this message are intended for the exclusive use of 
>the addressee(s) and may contain proprietary, confidential or 
>privileged information. If you are not the intended recipient, you 
>should not disseminate, distribute or copy this e-mail. Please 
>notify the sender immediately and destroy all copies of this message 
>and any attachments.
>
>WARNING: Computer viruses can be transmitted via email. The 
>recipient should check this email and any attachments for the 
>presence of viruses. The company accepts no liability for any damage 
>caused by any virus transmitted by this email.
>
><www.wipro.htm>www.wipro.com
>
>Please do not print this email unless it is absolutely necessary.
>
>The information contained in this electronic message and any 
>attachments to this message are intended for the exclusive use of 
>the addressee(s) and may contain proprietary, confidential or 
>privileged information. If you are not the intended recipient, you 
>should not disseminate, distribute or copy this e-mail. Please 
>notify the sender immediately and destroy all copies of this message 
>and any attachments.
>
>WARNING: Computer viruses can be transmitted via email. The 
>recipient should check this email and any attachments for the 
>presence of viruses. The company accepts no liability for any damage 
>caused by any virus transmitted by this email.
>
>www.wipro.com
>
>

Karl Schopmeyer                   Inova Development Inc.
305 Spring Creek Village, Suite 475 -  Dallas TX, 75248 USA
EMAIL: [email protected]       FAX: 1-972-239-0326
Phone 1-972-814-5581
Skype: kschopmeyer         Skype Phone: (214) 556-5971
7564c51.gif (image/gif, 1.1 KB) - not displayed
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.