RE: seeing memory leak in cimprovagt process

If possible please attend, User's day meet at meet on Thurday 10am and 12 
Noon, So that we can discuss your pain points. 
Warm Regards
D>L> Meetei
9538270270 

IBM India Software Lab, STG
6th Floor, A0202, 
EGL -D,Bangalore, India



From:   <[email protected]>
To:     Devchandra Leishangthem/India/IBM@IBMIN, 
<[email protected]>, 
Cc:     <[email protected]>, <[email protected]>, 
<[email protected]>
Date:   08/09/2012 04:08 PM
Subject:        RE: seeing memory leak in cimprovagt process



 
Hi Rohini,
 
Thank you.
 
 
Hi Devchandra,
 
I am using release version of 2.11.1.
 
Thanks & Regards,
Pialy
 
From: Devchandra Leishangthem [mailto:[email protected]] 
Sent: Thursday, August 09, 2012 3:49 PM
To: Deshpande, Rohini (IESL)
Cc: Anirban Bhattacharyya (WT01 - Manufacturing & Hi Tech); 
[email protected]; [email protected]; Pialy Ghosh (WT01 - 
Manufacturing & Hi Tech)
Subject: RE: seeing memory leak in cimprovagt process
 




From:        "Deshpande, Rohini \(IESL\)" <[email protected]> 
To:        "[email protected]" <[email protected]>, 
"[email protected]" <[email protected]>, 
Cc:        "[email protected]" <[email protected]>, 
"[email protected]" <[email protected]> 
Date:        08/09/2012 03:42 PM 
Subject:        RE: seeing memory leak in cimprovagt process 




Hi Pialy, 
  
This is done on the current branch (2.12). 
  
Valgrind has run on 2.11 before 2.12 branch was created. We haven’t done 
it on 2.11.1. 
>Oh, I did not know this, I was thinking it is tested for 2.11.1 also. 
Then in such case, we should really check as mentioned by Rohini. 
>Let me also check on my sys, 
@Pialy, u r using the release version of 2.11.1 or the cvs 
version(development build)? 

  
We can run valgrind on 2.11.1 and check if any leaks are detected with the 
build time options that you have mentioned. This will take some time and 
we’ll let you know the results after this is complete. 
  
Regards, 
Rohini 
  
From: [email protected] [mailto:[email protected]] 
Sent: Thursday, August 09, 2012 3:12 PM
To: Deshpande, Rohini (IESL); [email protected]
Cc: [email protected]; [email protected]
Subject: RE: seeing memory leak in cimprovagt process 
  
Hi Rohini, 
  
We are using OP 2.11.1, I am checking it on Rhel5 32 bit Linux Platform. 
My build variables are: 
  
PEGASUS_ENABLE_CMPI_PROVIDER_MANAGER=true 
PEGASUS_ENABLE_IPV6=true 
PEGASUS_ENABLE_SLP=true 
PEGASUS_SNIA_EXTENSIONS=true 
PEGASUS_PLATFORM=LINUX_IX86_GNU 
PEGASUS_HAS_SSL=true 
PEGASUS_PAM_AUTHENTICATION=1 
  
In which OP version this report is generated, please can you inform me. 
  
  
  
  
Hi Devchandra, 
  
No significant increase in our application is measured from the heap  and 
stack memory usages by the application. Heap memory is increased by 80 KB 
maximum and no increment in stack memory usages, so, it’s almost constant. 

  
When we are running cimserver, then we can see cimprovagt process heap 
usages is increased from 8876 KB to 22000KB in 18hours. 
  
Thanks & Regards, 
Pialy 
  
  
  
From: Deshpande, Rohini (IESL) [mailto:[email protected]] 
Sent: Thursday, August 09, 2012 2:19 PM
To: Devchandra L Meetei; Pialy Ghosh (WT01 - Manufacturing & Hi Tech)
Cc: [email protected]; Anirban Bhattacharyya (WT01 - Manufacturing 
& Hi Tech)
Subject: RE: seeing memory leak in cimprovagt process 
  
On which OP version are you seeing this? 
  
We run nightly builds with valgrind. Here are the results 
http://nbat.openpegasus.org/platform.php?id=372&archive=N&sort=0 . 
  
I guess your build time options are different. Can you send us your 
environment build variables? 
  
Regards, 
Rohini 
  
From: Devchandra L Meetei [mailto:[email protected]] 
Sent: Thursday, August 09, 2012 12:54 PM
To: [email protected]
Cc: [email protected]; [email protected]
Subject: Re: seeing memory leak in cimprovagt process 
  
Thanks for all of your responses. 
If we simply start and stop the server, then also we can see memory leak 
from Valgrind report. To separate out the memory leak area, we created a 
single application with our provider code. And by executing the 
application with Valgrind, it’s not reporting any memory leak. We put our 
standalone application  overnight and there is no significant increase in 
memory usage. 
  
How are you measuring exactly? No Significant increase? would appreciate a 
quantification. 
  
But when we run cimserver overnight, not doing any operation on it, we can 
see increase in memory. 
So, by summarizing this, can we suspect some memory leak in the 
serverside? 
How you find that the memory being leaked is from cimserver? 
If there is some serverside leak, it would have been detected by the 
valgrind test, which have been runring on daily nightly build testing. 
  
  
Please give your input on this asap. 
On Thu, Aug 9, 2012 at 12:39 PM, <[email protected]> wrote: 
Hi All, 
  
Thanks for all of your responses. 
If we simply start and stop the server, then also we can see memory leak 
from Valgrind report. To separate out the memory leak area, we created a 
single application with our provider code. And by executing the 
application with Valgrind, it’s not reporting any memory leak. We put our 
standalone application  overnight and there is no significant increase in 
memory usage. 
  
But when we run cimserver overnight, not doing any operation on it, we can 
see increase in memory. 
So, by summarizing this, can we suspect some memory leak in the 
serverside? 
  
Please give your input on this asap. 
  
Thanks & Regards, 
Pialy 
  
  
  
From: Karl Schopmeyer [mailto:[email protected]] 
Sent: Wednesday, August 08, 2012 1:54 AM
To: Pialy Ghosh (WT01 - Manufacturing & Hi Tech); 
[email protected]
Cc: Anirban Bhattacharyya (WT01 - Manufacturing & Hi Tech)
Subject: RE: seeing memory leak in cimprovagt process 
 
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 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.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 
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 
 
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 
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