| 2009-10-24 22:33:23 |
Daniel Nurmi |
bug |
|
|
added bug |
| 2009-10-24 22:33:23 |
Daniel Nurmi |
attachment added |
|
rampartc-1.3.0-euca.patch http://launchpadlibrarian.net/34337608/rampartc-1.3.0-euca.patch |
|
| 2009-10-24 22:33:38 |
Daniel Nurmi |
bug task added |
|
eucalyptus |
|
| 2009-10-24 22:34:01 |
Daniel Nurmi |
bug task added |
|
eucalyptus (Ubuntu) |
|
| 2009-10-26 10:09:09 |
Thierry Carrez |
eucalyptus (Ubuntu): status |
New |
Invalid |
|
| 2009-10-26 10:16:20 |
Thierry Carrez |
rampart (Ubuntu): importance |
Undecided |
High |
|
| 2009-10-26 10:16:20 |
Thierry Carrez |
rampart (Ubuntu): status |
New |
Confirmed |
|
| 2009-10-26 21:14:39 |
Daniel Nurmi |
eucalyptus: importance |
Undecided |
High |
|
| 2009-10-27 07:11:46 |
Thierry Carrez |
eucalyptus (Ubuntu): status |
Invalid |
Confirmed |
|
| 2009-10-27 07:11:55 |
Thierry Carrez |
eucalyptus (Ubuntu): importance |
Undecided |
Medium |
|
| 2009-10-27 07:12:19 |
Thierry Carrez |
eucalyptus (Ubuntu): importance |
Medium |
High |
|
| 2009-10-27 07:13:19 |
Thierry Carrez |
rampart (Ubuntu): status |
Confirmed |
Triaged |
|
| 2009-10-27 07:13:19 |
Thierry Carrez |
rampart (Ubuntu): assignee |
|
Thierry Carrez (ttx) |
|
| 2009-10-29 14:49:38 |
Daniel Nurmi |
eucalyptus: status |
New |
Fix Committed |
|
| 2009-10-30 11:02:45 |
Thierry Carrez |
attachment added |
|
rampart.patch http://launchpadlibrarian.net/34675812/rampart.patch |
|
| 2009-11-05 16:32:06 |
Thierry Carrez |
nominated for series |
|
Ubuntu Karmic |
|
| 2009-11-05 16:32:06 |
Thierry Carrez |
bug task added |
|
eucalyptus (Ubuntu Karmic) |
|
| 2009-11-05 16:32:06 |
Thierry Carrez |
bug task added |
|
rampart (Ubuntu Karmic) |
|
| 2009-11-05 16:32:25 |
Thierry Carrez |
eucalyptus (Ubuntu Karmic): status |
New |
Confirmed |
|
| 2009-11-05 16:32:29 |
Thierry Carrez |
eucalyptus (Ubuntu Karmic): importance |
Undecided |
High |
|
| 2009-11-05 16:32:34 |
Thierry Carrez |
rampart (Ubuntu Karmic): importance |
Undecided |
High |
|
| 2009-11-05 16:32:42 |
Thierry Carrez |
rampart (Ubuntu Karmic): status |
New |
Triaged |
|
| 2009-11-05 17:51:52 |
Mathias Gug |
tags |
eucalyptus |
eucalyptus uec |
|
| 2009-11-13 13:54:18 |
Thierry Carrez |
eucalyptus (Ubuntu Karmic): milestone |
|
karmic-updates |
|
| 2009-11-13 13:54:24 |
Thierry Carrez |
rampart (Ubuntu Karmic): milestone |
|
karmic-updates |
|
| 2009-11-13 13:54:28 |
Thierry Carrez |
rampart (Ubuntu Karmic): assignee |
|
Thierry Carrez (ttx) |
|
| 2009-11-13 13:54:34 |
Thierry Carrez |
eucalyptus (Ubuntu): assignee |
|
Thierry Carrez (ttx) |
|
| 2009-11-13 13:54:39 |
Thierry Carrez |
eucalyptus (Ubuntu Karmic): assignee |
|
Thierry Carrez (ttx) |
|
| 2009-11-13 13:55:04 |
Thierry Carrez |
eucalyptus (Ubuntu): status |
Confirmed |
Triaged |
|
| 2009-11-13 13:55:08 |
Thierry Carrez |
eucalyptus (Ubuntu Karmic): status |
Confirmed |
Triaged |
|
| 2009-11-13 13:55:16 |
Thierry Carrez |
eucalyptus (Ubuntu): importance |
High |
Medium |
|
| 2009-11-13 13:55:18 |
Thierry Carrez |
eucalyptus (Ubuntu Karmic): importance |
High |
Medium |
|
| 2009-11-13 13:55:20 |
Thierry Carrez |
rampart (Ubuntu): importance |
High |
Medium |
|
| 2009-11-13 13:55:24 |
Thierry Carrez |
rampart (Ubuntu Karmic): importance |
High |
Medium |
|
| 2009-11-27 10:14:20 |
Launchpad Janitor |
branch linked |
|
lp:~ttx/eucalyptus/karmic-sru2 |
|
| 2009-12-01 15:02:09 |
Launchpad Janitor |
branch linked |
|
lp:~ubuntu-core-dev/eucalyptus/ubuntu-karmic |
|
| 2009-12-01 21:32:01 |
Dustin Kirkland |
rampart (Ubuntu): status |
Triaged |
In Progress |
|
| 2009-12-01 21:32:10 |
Dustin Kirkland |
rampart (Ubuntu): status |
In Progress |
Triaged |
|
| 2009-12-01 21:32:15 |
Dustin Kirkland |
rampart (Ubuntu): assignee |
Thierry Carrez (ttx) |
Dustin Kirkland (kirkland) |
|
| 2009-12-01 21:32:19 |
Dustin Kirkland |
rampart (Ubuntu): assignee |
Dustin Kirkland (kirkland) |
Thierry Carrez (ttx) |
|
| 2009-12-01 21:32:25 |
Dustin Kirkland |
eucalyptus (Ubuntu): assignee |
Thierry Carrez (ttx) |
Dustin Kirkland (kirkland) |
|
| 2009-12-01 21:32:32 |
Dustin Kirkland |
eucalyptus (Ubuntu): status |
Triaged |
In Progress |
|
| 2009-12-01 21:42:10 |
Launchpad Janitor |
branch linked |
|
lp:~ubuntu-core-dev/eucalyptus/ubuntu |
|
| 2009-12-02 03:15:09 |
Launchpad Janitor |
eucalyptus (Ubuntu): status |
In Progress |
Fix Released |
|
| 2009-12-02 04:07:10 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/eucalyptus |
|
| 2009-12-02 23:59:18 |
Dustin Kirkland |
eucalyptus (Ubuntu Karmic): status |
Triaged |
Fix Committed |
|
| 2009-12-03 13:47:25 |
Martin Pitt |
tags |
eucalyptus uec |
eucalyptus uec verification-needed |
|
| 2009-12-03 14:00:29 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/karmic-proposed/eucalyptus |
|
| 2009-12-14 07:46:33 |
Thierry Carrez |
summary |
memory leak; rampart_context not freed (memory leaked per connection) |
Memory leaked per connection |
|
| 2009-12-14 08:00:25 |
Thierry Carrez |
description |
It looks like the rampart_context structure is not freed after processing (in rampart_in_handler.c), and in the rampart_context_free function, the section for freeing the receiver_cert is commented out (in rampart_token_processor.c). In our application (eucalyptus), this is causing the back-end components (axis2c/rampartc web services) to leak memory on every connection, which adds up quickly under load (30-50MB/day). I've attached a patch for review, but since the free section was commented out, it may be that there are other rampart configurations that will fail using this patch (this problem could certainly use some upstream guidance!)
-Dan |
It looks like the rampart_context structure is not freed after processing (in rampart_in_handler.c), and in the rampart_context_free function, the section for freeing the receiver_cert is commented out (in rampart_token_processor.c). In our application (eucalyptus), this is causing the back-end components (axis2c/rampartc web services) to leak memory on every connection, which adds up quickly under load (30-50MB/day). I've attached a patch for review, but since the free section was commented out, it may be that there are other rampart configurations that will fail using this patch (this problem could certainly use some upstream guidance!)
== SRU Report ==
Impact: A small amount of memory is not freed for every connection to an Eucalyptus web service. Under load, this can add up to 50Mb of RAM per day.
Fix in development branch: This needs to be fixed in two places: Eucalyptus and Rampart. The Eucalyptus patch is applied to 1.6.1 in Lucid. The Rampart fix will be shipped asap as 1.3.0-0ubuntu7, same patch applied.
Minimal patches:
Eucalyptus: http://bazaar.launchpad.net/~eucalyptus-maintainers/eucalyptus/1.6/revision/946
Rampart: debian/patches/rampart-memleak.patch (see attachment below)
TEST CASE:
Run a UEC CC/NC setup under load and watch the memory footprint of the associated apache2 processes. Without the patch, the memory used grows, with the patch it should remain stable.
Regression potential: The patch affects memory management of Rampart structures and therefore has some potential for regression. However it was tested and accepted upstream (comment 7) and tested on real setups at Eucalyptus Systems. The only package in archive that uses rampart is eucalyptus. The regression tests are therefore quite limited. |
|
| 2009-12-14 08:01:35 |
Thierry Carrez |
attachment added |
|
debian/patches/rampart-memleak.patch http://launchpadlibrarian.net/36761797/rampart-memleak.patch |
|
| 2009-12-14 08:01:47 |
Thierry Carrez |
rampart (Ubuntu): status |
Triaged |
In Progress |
|
| 2009-12-14 08:01:53 |
Thierry Carrez |
rampart (Ubuntu Karmic): status |
Triaged |
In Progress |
|
| 2009-12-14 08:03:16 |
Thierry Carrez |
description |
It looks like the rampart_context structure is not freed after processing (in rampart_in_handler.c), and in the rampart_context_free function, the section for freeing the receiver_cert is commented out (in rampart_token_processor.c). In our application (eucalyptus), this is causing the back-end components (axis2c/rampartc web services) to leak memory on every connection, which adds up quickly under load (30-50MB/day). I've attached a patch for review, but since the free section was commented out, it may be that there are other rampart configurations that will fail using this patch (this problem could certainly use some upstream guidance!)
== SRU Report ==
Impact: A small amount of memory is not freed for every connection to an Eucalyptus web service. Under load, this can add up to 50Mb of RAM per day.
Fix in development branch: This needs to be fixed in two places: Eucalyptus and Rampart. The Eucalyptus patch is applied to 1.6.1 in Lucid. The Rampart fix will be shipped asap as 1.3.0-0ubuntu7, same patch applied.
Minimal patches:
Eucalyptus: http://bazaar.launchpad.net/~eucalyptus-maintainers/eucalyptus/1.6/revision/946
Rampart: debian/patches/rampart-memleak.patch (see attachment below)
TEST CASE:
Run a UEC CC/NC setup under load and watch the memory footprint of the associated apache2 processes. Without the patch, the memory used grows, with the patch it should remain stable.
Regression potential: The patch affects memory management of Rampart structures and therefore has some potential for regression. However it was tested and accepted upstream (comment 7) and tested on real setups at Eucalyptus Systems. The only package in archive that uses rampart is eucalyptus. The regression tests are therefore quite limited. |
It looks like the rampart_context structure is not freed after processing (in rampart_in_handler.c), and in the rampart_context_free function, the section for freeing the receiver_cert is commented out (in rampart_token_processor.c). In our application (eucalyptus), this is causing the back-end components (axis2c/rampartc web services) to leak memory on every connection, which adds up quickly under load (30-50MB/day). I've attached a patch for review, but since the free section was commented out, it may be that there are other rampart configurations that will fail using this patch (this problem could certainly use some upstream guidance!)
== SRU Report ==
Impact: A small amount of memory is not freed for every connection to an Eucalyptus web service. Under load, this can add up to 50Mb of RAM per day.
Fix in development branch: This needs to be fixed in two places: Eucalyptus and Rampart. The Eucalyptus patch is applied to 1.6.1 in Lucid. The Rampart fix will be shipped asap as 1.3.0-0ubuntu7, same patch applied.
Minimal patches:
Eucalyptus: http://bazaar.launchpad.net/~eucalyptus-maintainers/eucalyptus/1.6/revision/946
Rampart: debian/patches/rampart-memleak.patch (see comment 18 below)
TEST CASE:
Run a UEC CC/NC setup under load and watch the memory footprint of the associated apache2 processes. Without the patch, the memory used grows, with the patch it should remain stable.
Regression potential: The patch affects memory management of Rampart structures and therefore has some potential for regression. However it was tested and accepted upstream (comment 7) and tested on real setups at Eucalyptus Systems. The only package in archive that uses rampart is eucalyptus. The regression tests are therefore quite limited.
|
|
| 2009-12-14 08:33:20 |
Thierry Carrez |
description |
It looks like the rampart_context structure is not freed after processing (in rampart_in_handler.c), and in the rampart_context_free function, the section for freeing the receiver_cert is commented out (in rampart_token_processor.c). In our application (eucalyptus), this is causing the back-end components (axis2c/rampartc web services) to leak memory on every connection, which adds up quickly under load (30-50MB/day). I've attached a patch for review, but since the free section was commented out, it may be that there are other rampart configurations that will fail using this patch (this problem could certainly use some upstream guidance!)
== SRU Report ==
Impact: A small amount of memory is not freed for every connection to an Eucalyptus web service. Under load, this can add up to 50Mb of RAM per day.
Fix in development branch: This needs to be fixed in two places: Eucalyptus and Rampart. The Eucalyptus patch is applied to 1.6.1 in Lucid. The Rampart fix will be shipped asap as 1.3.0-0ubuntu7, same patch applied.
Minimal patches:
Eucalyptus: http://bazaar.launchpad.net/~eucalyptus-maintainers/eucalyptus/1.6/revision/946
Rampart: debian/patches/rampart-memleak.patch (see comment 18 below)
TEST CASE:
Run a UEC CC/NC setup under load and watch the memory footprint of the associated apache2 processes. Without the patch, the memory used grows, with the patch it should remain stable.
Regression potential: The patch affects memory management of Rampart structures and therefore has some potential for regression. However it was tested and accepted upstream (comment 7) and tested on real setups at Eucalyptus Systems. The only package in archive that uses rampart is eucalyptus. The regression tests are therefore quite limited.
|
It looks like the rampart_context structure is not freed after processing (in rampart_in_handler.c), and in the rampart_context_free function, the section for freeing the receiver_cert is commented out (in rampart_token_processor.c). In our application (eucalyptus), this is causing the back-end components (axis2c/rampartc web services) to leak memory on every connection, which adds up quickly under load (30-50MB/day). I've attached a patch for review, but since the free section was commented out, it may be that there are other rampart configurations that will fail using this patch (this problem could certainly use some upstream guidance!)
== SRU Report ==
Impact: A small amount of memory is not freed for every connection to an Eucalyptus web service. Under load, this can add up to 50Mb of RAM per day.
Fix in development branch: This needs to be fixed in two places: Eucalyptus and Rampart. The Eucalyptus patch is applied to 1.6.1 in Lucid. The Rampart fix has been shipped as 1.3.0-0ubuntu7, same patch applied.
Minimal patches:
Eucalyptus: http://bazaar.launchpad.net/~eucalyptus-maintainers/eucalyptus/1.6/revision/946
Rampart: debian/patches/rampart-memleak.patch (see comment 18 below)
TEST CASE:
Run a UEC CC/NC setup under load and watch the memory footprint of the associated apache2 processes. Without the patch, the memory used grows, with the patch it should remain stable.
Regression potential: The patch affects memory management of Rampart structures and therefore has some potential for regression. However it was tested and accepted upstream (comment 7) and tested on real setups at Eucalyptus Systems. The only package in archive that uses rampart is eucalyptus. The regression tests are therefore quite limited.
|
|
| 2009-12-14 08:35:32 |
Launchpad Janitor |
rampart (Ubuntu): status |
In Progress |
Fix Released |
|
| 2009-12-14 09:17:09 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/rampart |
|
| 2009-12-15 08:03:08 |
Martin Pitt |
rampart (Ubuntu Karmic): status |
In Progress |
Fix Committed |
|
| 2009-12-16 18:15:16 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/karmic-proposed/rampart |
|
| 2009-12-18 19:39:37 |
Thierry Carrez |
tags |
eucalyptus uec verification-needed |
eucalyptus uec verification-done |
|
| 2009-12-21 16:00:43 |
Launchpad Janitor |
eucalyptus (Ubuntu Karmic): status |
Fix Committed |
Fix Released |
|
| 2009-12-21 16:06:13 |
Launchpad Janitor |
rampart (Ubuntu Karmic): status |
Fix Committed |
Fix Released |
|
| 2011-10-28 20:17:25 |
graziano obertelli |
eucalyptus: status |
Fix Committed |
Fix Released |
|
