Quantcast

Memory leak in CimResource_Enumerate_EP ?!

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Memory leak in CimResource_Enumerate_EP ?!

Klaus Kaempf
Following up from message [hidden email] in
sblim-devel, I'd like to propose the following patch to fix the
cleanup of CimResource_Enumerate_EP.

This patch destroys the allocated cimclient independant of the retval. As CimResource_destroy()
includes freeing up the selectors, this code is removed.

diff --git a/src/plugins/cim/cim_data_stubs.c b/src/plugins/cim/cim_data_stubs.c
index 932183a..c6f0136 100644
--- a/src/plugins/cim/cim_data_stubs.c
+++ b/src/plugins/cim/cim_data_stubs.c
@@ -456,19 +456,12 @@ CimResource_Enumerate_EP( WsContextH cntx,
  int index2 = enumInfo->index + 1;
  if (enumInfo->totalItems == 0 ||index2 == enumInfo->totalItems)  {
  cim_release_enum_context(enumInfo);
- CimResource_destroy(cimclient);
- return retval;
  }
  }
 cleanup:
- if (retval && cimclient) {
+ if (cimclient) {
  CimResource_destroy(cimclient);
  }
- else if(cimclient && cimclient->selectors) {
- hash_free(cimclient->selectors);
- cimclient->selectors = NULL;
- debug("selectors destroyed");
- }
  return retval;
 }


Comments ?

Klaus
---
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Maxfeldstraße 5, 90409 Nürnberg, Germany

------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Openwsman-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openwsman-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Memory leak in CimResource_Enumerate_EP ?!

Suresh Sundriyal-2
Commit 13029fcfc6a56b48dda648b328d0cf4e7678f680.

I believe it's reused in CimResource_Pull_EP and cleaned up when CimResource_Release_EP
or CimResource_Pull_EP is called. I think the release_ep is also called when the enums
expire. So there might not be a memory leak, just the lingering client till the
transaction completes.

--
Suresh

----- Original Message -----

> From: "Klaus Kaempf" <[hidden email]>
> To: [hidden email]
> Cc: "Chris Poblete" <[hidden email]>
> Sent: Friday, May 13, 2011 12:56:40 AM
> Subject: [Openwsman-devel] Memory leak in CimResource_Enumerate_EP ?!
>
> Following up from message [hidden email] in
> sblim-devel, I'd like to propose the following patch to fix the
> cleanup of CimResource_Enumerate_EP.
>
> This patch destroys the allocated cimclient independant of the
> retval. As CimResource_destroy()
> includes freeing up the selectors, this code is removed.
>
> diff --git a/src/plugins/cim/cim_data_stubs.c
> b/src/plugins/cim/cim_data_stubs.c
> index 932183a..c6f0136 100644
> --- a/src/plugins/cim/cim_data_stubs.c
> +++ b/src/plugins/cim/cim_data_stubs.c
> @@ -456,19 +456,12 @@ CimResource_Enumerate_EP( WsContextH cntx,
>   int index2 = enumInfo->index + 1;
>   if (enumInfo->totalItems == 0 ||index2 == enumInfo->totalItems)  {
>   cim_release_enum_context(enumInfo);
> - CimResource_destroy(cimclient);
> - return retval;
>   }
>   }
>  cleanup:
> - if (retval && cimclient) {
> + if (cimclient) {
>   CimResource_destroy(cimclient);
>   }
> - else if(cimclient && cimclient->selectors) {
> - hash_free(cimclient->selectors);
> - cimclient->selectors = NULL;
> - debug("selectors destroyed");
> - }
>   return retval;
>  }
>
>
> Comments ?
>
> Klaus
> ---
> SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix
> Imendörffer, HRB 16746 (AG Nürnberg)
> Maxfeldstraße 5, 90409 Nürnberg, Germany
>
> ------------------------------------------------------------------------------
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Openwsman-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/openwsman-devel
>

------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Openwsman-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openwsman-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Memory leak in CimResource_Enumerate_EP ?!

Klaus Kaempf
* Suresh Sundriyal <[hidden email]> [May 13. 2011 10:57]:
> Commit 13029fcfc6a56b48dda648b328d0cf4e7678f680.
>
> I believe it's reused in CimResource_Pull_EP and cleaned up when CimResource_Release_EP
> or CimResource_Pull_EP is called. I think the release_ep is also called when the enums
> expire. So there might not be a memory leak, just the lingering client till the
> transaction completes.

Yeah, you're right. Sorry for the noise.

Klaus
P.S.: You learn something new every day :-)
---
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Maxfeldstraße 5, 90409 Nürnberg, Germany

------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Openwsman-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openwsman-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Memory leak in CimResource_Enumerate_EP ?!

Suresh Sundriyal-2
> Yeah, you're right. Sorry for the noise.
>
> Klaus
> P.S.: You learn something new every day :-)
> ---
> SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix
> Imendörffer, HRB 16746 (AG Nürnberg)
> Maxfeldstraße 5, 90409 Nürnberg, Germany
>

Confused me as well, till I tracked down the original commit. :)

It might be a good idea to add a comment regarding the delayed
cleanup and reuse in CimResource_Enumerate_EP cleanup code for
future reference.

--
Suresh

------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Openwsman-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openwsman-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Memory leak in CimResource_Enumerate_EP ?!

Klaus Kaempf
* Suresh Sundriyal <[hidden email]> [May 13. 2011 11:26]:

> > Yeah, you're right. Sorry for the noise.
> >
> > Klaus
> > P.S.: You learn something new every day :-)
> > ---
> > SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix
> > Imendörffer, HRB 16746 (AG Nürnberg)
> > Maxfeldstraße 5, 90409 Nürnberg, Germany
> >
>
> Confused me as well, till I tracked down the original commit. :)
>
> It might be a good idea to add a comment regarding the delayed
> cleanup and reuse in CimResource_Enumerate_EP cleanup code for
> future reference.

That's exactly what I did.
Great minds think alike ;-)

Thanks again,

Klaus
---
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Maxfeldstraße 5, 90409 Nürnberg, Germany

------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Openwsman-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openwsman-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Memory leak in CimResource_Enumerate_EP ?!

Chris_Poblete
Good news that's not a leak.
Bad news there's still a leak somewhere.

Using openwsman 2.2.1, sfcc 2.2.1 and sfcb 1.3.5, I recorded the memory usage of openwsman service and client running in a loop enumerating CIM_ComputerSystem with 2 instances (no pull). It leaks 4 Kb per command. The memory usage does not drop after stopping the client. There is also a 688 Kb increase on the first command after service start up.  A graph of data taken is attached.

Switching to openwsman 2.2.5, the leak ranges 4 - 16 Kb per command (majority is 12 kb).

Any ideas?

Thanks,
-Chris Poblete


-----Original Message-----
From: Klaus Kaempf [mailto:[hidden email]]
Sent: Friday, May 13, 2011 4:36 AM
To: Suresh Sundriyal
Cc: Poblete, Chris; [hidden email]
Subject: Re: [Openwsman-devel] Memory leak in CimResource_Enumerate_EP ?!

* Suresh Sundriyal <[hidden email]> [May 13. 2011 11:26]:

> > Yeah, you're right. Sorry for the noise.
> >
> > Klaus
> > P.S.: You learn something new every day :-)
> > ---
> > SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix
> > Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409
> > Nürnberg, Germany
> >
>
> Confused me as well, till I tracked down the original commit. :)
>
> It might be a good idea to add a comment regarding the delayed cleanup
> and reuse in CimResource_Enumerate_EP cleanup code for future
> reference.
That's exactly what I did.
Great minds think alike ;-)

Thanks again,

Klaus
---
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany

------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Openwsman-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openwsman-devel

openwsman-memleak.jpg (91K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Memory leak in CimResource_Enumerate_EP ?!

Klaus Kaempf
* [hidden email] <[hidden email]> [May 13. 2011 15:38]:
> Good news that's not a leak.
> Bad news there's still a leak somewhere.
>

> Using openwsman 2.2.1, sfcc 2.2.1 and sfcb 1.3.5, I recorded the
> memory usage of openwsman service and client running in a loop
> enumerating CIM_ComputerSystem with 2 instances (no pull). It leaks 4
  ^^^^^^^^^^^                                      ^^^^^^^
> Kb per command.

Thats actually to be expected since the openwsman service keeps the
enumeration context around for future Pull/Release calls.
However, there should be a timeout for these contexts to have them
freed.

Klaus
---
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Maxfeldstraße 5, 90409 Nürnberg, Germany

------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Openwsman-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openwsman-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Memory leak in CimResource_Enumerate_EP ?!

Suresh Sundriyal-2
> Thats actually to be expected since the openwsman service keeps the
> enumeration context around for future Pull/Release calls.
> However, there should be a timeout for these contexts to have them
> freed.
>
> Klaus
> ---
> SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix
> Imendörffer, HRB 16746 (AG Nürnberg)
> Maxfeldstraße 5, 90409 Nürnberg, Germany
>

I believe there is a timeout for the contexts and it's 100 seconds by
default and it can be adjusted using the "server:enum_idle_timeout"
parameter in the config file.

--
Suresh

------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Openwsman-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openwsman-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Memory leak in CimResource_Enumerate_EP ?!

Chris_Poblete
The memory increase is permanent.  According to the default the context is freed and usage should go down. Besides the command is optimized with large max elements so no pull is performed. Leak is still there.

-Chris Poblete


-----Original Message-----
From: Suresh Sundriyal [mailto:[hidden email]]
Sent: Monday, May 16, 2011 1:56 PM
To: Klaus Kaempf
Cc: [hidden email]; Poblete, Chris
Subject: Re: [Openwsman-devel] Memory leak in CimResource_Enumerate_EP ?!

> Thats actually to be expected since the openwsman service keeps the
> enumeration context around for future Pull/Release calls.
> However, there should be a timeout for these contexts to have them
> freed.
>
> Klaus
> ---
> SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix
> Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg,
> Germany
>

I believe there is a timeout for the contexts and it's 100 seconds by default and it can be adjusted using the "server:enum_idle_timeout"
parameter in the config file.

--
Suresh
------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Openwsman-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openwsman-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Memory leak in CimResource_Enumerate_EP ?!

Klaus Kaempf
* [hidden email] <[hidden email]> [May 17. 2011 03:49]:

> The memory increase is permanent.  According to the default the
> context is freed and usage should go down. Besides the command is
> optimized with large max elements so no pull is performed. Leak is
> still there.

Since I couldn't find any obvious leaks from code inspection, I used
valgrind to track memory allocations and got pointed to
sfcc-interface.c:1174
          enumeration = cc->ft->enumInstances(cc, objectpath, ...

Then I checked out and compiled sfcc and ran valgrind on TEST/test_ei.c
(I changed it to enumerate CIM_ComputerSystem which has a single
instance in my setup).
Valgrind reports:

==11421== 258 (40 direct, 218 indirect) bytes in 1 blocks are definitely lost in loss record 18 of 25
==11421==    at 0x4C24F19: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==11421==    by 0x5DC74DF: __new_empty_cop (objectpath.c:255)
==11421==    by 0x5DD21DD: createPath (parserUtil.c:69)
==11421==    by 0x5DD1883: iMethodRespContent (grammar.c:479)
==11421==    by 0x5DD2098: startParsing (grammar.c:153)
==11421==    by 0x5DD59B4: scanCimXmlResponse (cimXmlParser.c:1395)
==11421==    by 0x5DCB9D3: enumInstances (client.c:1713)
==11421==    by 0x40086B: main (test_ei.c:54)

I'll check further now.

Klaus
---
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Maxfeldstraße 5, 90409 Nürnberg, Germany

------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Openwsman-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openwsman-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Memory leak in CimResource_Enumerate_EP ?!

Klaus Kaempf
* Klaus Kaempf <[hidden email]> [May 17. 2011 16:15]:
>
> I'll check further now.

Now I checked openwsman using valgrind and SfcbLocal to connect to the
CIMOM.

In this scenario, valgrind reports two issues. One in cim_getElementAt
(sfcc-interface.c:1241) and one in cmciConnect2 (sfcclient.c:103)

These look more like the real culprit.

Klaus
---
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Maxfeldstraße 5, 90409 Nürnberg, Germany

------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Openwsman-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openwsman-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Memory leak in CimResource_Enumerate_EP ?!

Chris_Poblete
One report from Valgrind associated to CMPIConnect2 is malloc from setupControl.  Doing a trace from connect perspective, setupControl is called twice while sunsetControl once. It seems that the sunset is not called on the release counterpart of CMPIConnect2.  The attached patch seems to control the leak.  Hopefully you see the difference as well.

There's more leak though...

Thanks,
-Chris Poblete


-----Original Message-----
From: Klaus Kaempf [mailto:[hidden email]]
Sent: Tuesday, May 17, 2011 9:47 AM
To: Poblete, Chris
Cc: [hidden email]
Subject: Re: [Openwsman-devel] Memory leak in CimResource_Enumerate_EP ?!

* Klaus Kaempf <[hidden email]> [May 17. 2011 16:15]:
>
> I'll check further now.

Now I checked openwsman using valgrind and SfcbLocal to connect to the CIMOM.

In this scenario, valgrind reports two issues. One in cim_getElementAt
(sfcc-interface.c:1241) and one in cmciConnect2 (sfcclient.c:103)

These look more like the real culprit.

Klaus
---
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany

------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Openwsman-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openwsman-devel

patch-sfcb-1.3.10-memleak-connect-fix.txt (412 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Memory leak in CimResource_Enumerate_EP ?!

Klaus Kaempf
In reply to this post by Chris_Poblete
* [hidden email] <[hidden email]> [May 13. 2011 15:38]:
> Good news that's not a leak.
> Bad news there's still a leak somewhere.
>
> Using openwsman 2.2.1, sfcc 2.2.1 and sfcb 1.3.5, I recorded the memory usage of openwsman service and client running in a loop enumerating CIM_ComputerSystem with 2 instances (no pull). It leaks 4 Kb per command. The memory usage does not drop after stopping the client. There is also a 688 Kb increase on the first command after service start up.  A graph of data taken is attached.

I couldn't reproduce this setup, so I used openwsman 2.2.6, sfcc 2.2.2
and sfcb 1.3.11 under valgrind with the 'massif' tool.

The KDE massif visualizer
(https://projects.kde.org/projects/extragear/sdk/massif-visualizer)
allows to drill down into every memory allocation.

Observations
- just starting openwsman consumes ~90k
- A CIM operation ('wsman enumerate ...CIM_ComputerSystem' using the
  local interface) adds ~60k
  (55k of which are due to cim_getElementAt() which valgrind is unable
   to trace completely)
- Peak consumption is ~210k with two(!) threads calling cim_getElementAt()
- heap consumption goes down to ~90k afterwards

I also do not see any major leak fixes going into openwsman after
2.2.1. However there were leaks fixed in sfcc 2.2.2 as well as sfcb
after 1.3.5.

Chris, could the 'leak' you're seeing in openwsman be caused by the
threads spawned for every request ? How does the memory consumption
look like with different thread settings in openwsman.conf ?


Klaus
---
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Maxfeldstraße 5, 90409 Nürnberg, Germany

------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
Openwsman-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openwsman-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Memory leak in CimResource_Enumerate_EP ?!

Klaus Kaempf
* Klaus Kaempf <[hidden email]> [May 24. 2011 15:50]:
>
> Chris, could the 'leak' you're seeing in openwsman be caused by the
> threads spawned for every request ? How does the memory consumption
> look like with different thread settings in openwsman.conf ?
>

Well, I can answer this myself now.
Instead of using 'wsman' I re-ran the tests using the Ruby bindings
and small Ruby script to enumerate CIM_Process. This esp. allowed me
to control enumerate, pull, and release in a granular way.

Observations:
- the initial Enumerate raises heap consumption from ~90k (idle) to
  ~1MB (approx 200 process instances)
- each subsequent Pull increased(!) memory use by 200k
  (one thread calling cim_enum_instances() staying at 900k, one thread
   also calling cim_enum_instances() increasing by 200k for each Pull)
- the final Release call freed the memory used by the Pull requests
  but not(!) below 1MB
  (there's still one thread calling cim_enum_instances() using ~950k)

Klaus
---
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Maxfeldstraße 5, 90409 Nürnberg, Germany

------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
Openwsman-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openwsman-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Memory leak in CimResource_Enumerate_EP ?!

Klaus Kaempf
* Klaus Kaempf <[hidden email]> [May 24. 2011 16:36]:

>
> Observations:
> - the initial Enumerate raises heap consumption from ~90k (idle) to
>   ~1MB (approx 200 process instances)
> - each subsequent Pull increased(!) memory use by 200k
>   (one thread calling cim_enum_instances() staying at 900k, one thread
>    also calling cim_enum_instances() increasing by 200k for each Pull)
> - the final Release call freed the memory used by the Pull requests
>   but not(!) below 1MB
>   (there's still one thread calling cim_enum_instances() using ~950k)

No, thats all wrong. I misread the 'massif' output, as it defaults to
instructions executed, not wall clock time.

- the idle consumption of openwsmand is ~90k
- the Enumerate request spawns a thread using ~900k
- the peak consumption is 1.9MB with two threads calling
  cim_enum_instances()
- each Pull request spawns a thread with ~50k
- after Release of the enum context, the 900k thread is gone and
  memory consumption is back at ~90k

Then I looked as wsmancli and noticed that "wsman enum" does not(!)
release the enum context.

It looks like as if openwsman keeps the enum context as a thread (of
the initial Enumerate call). This would explain the raise in memory
consumption you're seeing with your 'stress' tests which never release
the enum context.


Klaus
---
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Maxfeldstraße 5, 90409 Nürnberg, Germany

------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
Openwsman-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openwsman-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Memory leak in CimResource_Enumerate_EP ?!

Klaus Kaempf
In reply to this post by Chris_Poblete
* [hidden email] <[hidden email]> [May 17. 2011 18:22]:
> One report from Valgrind associated to CMPIConnect2 is malloc from setupControl.  Doing a trace from connect perspective, setupControl is called twice while sunsetControl once. It seems that the sunset is not called on the release counterpart of CMPIConnect2.  The attached patch seems to control the leak.  Hopefully you see the difference as well.

Hmm, after applying this patch to sfcb 1.3.11 I get double-free
crashes :-/

Klaus

>
> There's more leak though...
>
> Thanks,
> -Chris Poblete
>
>
> -----Original Message-----
> From: Klaus Kaempf [mailto:[hidden email]]
> Sent: Tuesday, May 17, 2011 9:47 AM
> To: Poblete, Chris
> Cc: [hidden email]
> Subject: Re: [Openwsman-devel] Memory leak in CimResource_Enumerate_EP ?!
>
> * Klaus Kaempf <[hidden email]> [May 17. 2011 16:15]:
> >
> > I'll check further now.
>
> Now I checked openwsman using valgrind and SfcbLocal to connect to the CIMOM.
>
> In this scenario, valgrind reports two issues. One in cim_getElementAt
> (sfcc-interface.c:1241) and one in cmciConnect2 (sfcclient.c:103)
>
> These look more like the real culprit.
>
> Klaus
> ---
> SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany

> --- sblim-sfcb-1.3.10-orig/cimcClientSfcbLocal.c 2010-11-10 17:48:25.000000000 -0600
> +++ sblim-sfcb-1.3.10/cimcClientSfcbLocal.c 2011-05-17 11:18:38.000000000 -0500
> @@ -1901,6 +1901,7 @@
>     }
>     CONNECT_UNLOCK();
>     free(ce);
> +   sunsetControl();
>     uninitGarbageCollector();
>     return lib;
>  }

> ------------------------------------------------------------------------------
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay

> _______________________________________________
> Openwsman-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/openwsman-devel

---
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Maxfeldstraße 5, 90409 Nürnberg, Germany

------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
Openwsman-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openwsman-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Memory leak in CimResource_Enumerate_EP ?!

Klaus Kaempf
* Klaus Kaempf <[hidden email]> [May 25. 2011 13:10]:
> * [hidden email] <[hidden email]> [May 17. 2011 18:22]:
> > One report from Valgrind associated to CMPIConnect2 is malloc from setupControl.  Doing a trace from connect perspective, setupControl is called twice while sunsetControl once. It seems that the sunset is not called on the release counterpart of CMPIConnect2.  The attached patch seems to control the leak.  Hopefully you see the difference as well.
>
> Hmm, after applying this patch to sfcb 1.3.11 I get double-free
> crashes :-/

It crashes if the CIMOM connection fails. Find a reworked patch below.

Klaus
---
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Maxfeldstraße 5, 90409 Nürnberg, Germany

------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
Openwsman-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openwsman-devel

x (523 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Memory leak in CimResource_Enumerate_EP ?!

Klaus Kaempf
In reply to this post by Chris_Poblete
* [hidden email] <[hidden email]> [May 13. 2011 15:38]:
> Good news that's not a leak.
> Bad news there's still a leak somewhere.
>
> Using openwsman 2.2.1, sfcc 2.2.1 and sfcb 1.3.5, I recorded the memory usage of openwsman service and client running in a loop enumerating CIM_ComputerSystem with 2 instances (no pull). It leaks 4 Kb per command. The memory usage does not drop after stopping the client. There is also a 688 Kb increase on the first command after service start up.  A graph of data taken is attached.
>
> Switching to openwsman 2.2.5, the leak ranges 4 - 16 Kb per command (majority is 12 kb).
>
> Any ideas?

Chris,

I can now verify the problem with valgrind and the 'massif' tool.

Running your 'stress.sh' shows a steady increase in memory
consumption. I'm still trying to wrap my head around the information
'massif' shows me.

Currently it points to fdopen() in sfcb's 'mlog.c'. There's also a call
to Class::clone in getConstClass() of providerMgr.c, being tracked in
sfcb's memAdd(). Maybe its cleanup function gets called too late.

Klaus
---
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Maxfeldstraße 5, 90409 Nürnberg, Germany

------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
Openwsman-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openwsman-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Memory leak in CimResource_Enumerate_EP ?!

Raveendra Reddy P
Hi All,

we are using Openwsman 2.4.7 sblim-sfcc 2.2.7 sblim-sfcb 1.3.10

Still Observing memory leaks while doing stress test. Meaning once the memory of openwsman increases it never comes back.

Any proposed solutions for this issue. Please share latest updates on this issue.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Memory leak in CimResource_Enumerate_EP ?!

Klaus Kaempf
* Raveendra Reddy P <[hidden email]> [Aug 25. 2014 08:02]:
> Hi All,
>
> we are using Openwsman 2.4.7 sblim-sfcc 2.2.7 sblim-sfcb 1.3.10

Raveendra,

latest Openwsman release is 2.4.10, sblim-sfcb is at 1.4.8
Please consider updating to the latest releases first.

>
> Still Observing memory leaks while doing stress test. Meaning once the
> memory of openwsman increases it never comes back.

How do you access the sfcb cimom ? Via XML or SfcbLocal ? Does the
leak also occur if you change the setting of cim_client_frontend in
openwsman.conf ?

>
> Any proposed solutions for this issue. Please share latest updates on this
> issue.

Please share your test setup with us so we can re-create your issue.

Klaus
--
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Maxfeldstraße 5, 90409 Nürnberg, Germany

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Openwsman-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openwsman-devel
12
Loading...