Opened at 2010-10-24T13:56:37Z
Last modified at 2010-11-03T19:30:20Z
#1229 assigned defect
Memory leak during deep-check
| Reported by: | francois | Owned by: | francois |
|---|---|---|---|
| Priority: | major | Milestone: | soon |
| Component: | code | Version: | 1.8.0 |
| Keywords: | performance reliability memory repair | Cc: | |
| Launchpad Bug: |
Description
Running tahoe deep-check --add-lease --repair on a large directory expose a memory leak. More details to come as soon the cause of #1045 is figured out.
Change History (8)
comment:1 Changed at 2010-10-24T17:03:53Z by davidsarah
comment:2 follow-up: ↓ 3 Changed at 2010-10-29T05:03:28Z by zooko
What's the status of this ticket? Is this still considered a regression or a potentially critical bug in v1.8.0?
comment:3 in reply to: ↑ 2 Changed at 2010-10-29T06:34:53Z by davidsarah
Replying to zooko:
What's the status of this ticket? Is this still considered a regression or a potentially critical bug in v1.8.0?
I believe #1045 and #1229 are the same issue. So it's not a regression, but I'd like to fix it for 1.8.1 anyway (and I think the patch on #1045 should do so, but it needs review and testing).
comment:4 Changed at 2010-10-29T11:46:07Z by francois
- Milestone changed from 1.8.1 to soon
- Owner changed from somebody to francois
- Status changed from new to assigned
comment:5 Changed at 2010-10-29T19:43:13Z by david-sarah@…
In 4061258c85da2960:
(The changeset message doesn't reference this ticket)
comment:6 follow-up: ↓ 7 Changed at 2010-10-31T02:39:31Z by davidsarah
- Keywords news-needed added
francois: please check whether this is fixed on trunk.
comment:7 in reply to: ↑ 6 Changed at 2010-11-03T10:00:39Z by francois
Replying to davidsarah:
francois: please check whether this is fixed on trunk.
Unfortunately, this is not fixed on trunk.
comment:8 Changed at 2010-11-03T19:30:20Z by davidsarah
- Keywords news-needed removed
We don't have a fix to go into 1.8.1, so no NEWS entry needed.
I believe that we avoid the #1045 memory leak for most webapi operations because they hold on to filenode objects only for as long as the operation (i.e. a single HTTP request). SFTP and
tahoe deep-checkthe deep-check webapi operation both hold onto filenode objects for longer, so there is a more noticeable accumulation of entries in the ResponseCache.