Memory leak during deep-check #1229

New Issue

tahoe-lafs · 2010-10-24T13:56:37Z

francois commented

2010-10-24 13:56:37 +00:00

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.

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.

tahoe-lafs added the

labels 2010-10-24 13:56:37 +00:00

tahoe-lafs added this to the 1.8.1 milestone 2010-10-24 13:56:37 +00:00

davidsarah commented

2010-10-24 17:03:53 +00:00

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-check~~ the deep-check webapi operation both hold onto filenode objects for longer, so there is a more noticeable accumulation of entries in the ResponseCache.

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-check`~~ the deep-check webapi operation both hold onto filenode objects for longer, so there is a more noticeable accumulation of entries in the `ResponseCache`.

zooko commented

2010-10-29 05:03:28 +00:00

What's the status of this ticket? Is this still considered a regression or a potentially critical bug in v1.8.0?

davidsarah commented

2010-10-29 06:34:53 +00:00

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).

Replying to [zooko](/tahoe-lafs/trac-2024-07-25/issues/1229#issuecomment-80639): > 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).

francois commented

2010-10-29 11:46:07 +00:00

I'm still unsure whether this bug is actually a duplicate of #1045. So, let's move it away from release v1.8.1 and advise when #1045 is fixed.

tahoe-lafs modified the milestone from 1.8.1 to soon

2010-10-29 11:46:07 +00:00

david-sarah@jacaranda.org commented

2010-10-29 19:43:13 +00:00

In changeset:4061258c85da2960:

make ResponseCache smarter to avoid memory leaks: don't record timestamps, use DataSpans to merge entries, and clear the cache when we see a new seqnum. refs #1045, #1229

In changeset:4061258c85da2960: ``` make ResponseCache smarter to avoid memory leaks: don't record timestamps, use DataSpans to merge entries, and clear the cache when we see a new seqnum. refs #1045, #1229 ```

davidsarah commented

2010-10-31 02:39:31 +00:00

francois: please check whether this is fixed on trunk.

francois commented

2010-11-03 10:00:39 +00:00

Replying to davidsarah:

francois: please check whether this is fixed on trunk.

Unfortunately, this is not fixed on trunk.

Replying to [davidsarah](/tahoe-lafs/trac-2024-07-25/issues/1229#issuecomment-80644): > francois: please check whether this is fixed on trunk. Unfortunately, this is not fixed on trunk.

davidsarah commented

2010-11-03 19:30:20 +00:00

We don't have a fix to go into 1.8.1, so no NEWS entry needed.

Sign in to join this conversation.