classification
Title: Unbounded memory growth resizing split-table dicts
Type: crash Stage: resolved
Components: Interpreter Core Versions: Python 3.7, Python 3.6, Python 3.5
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: berker.peksag, inada.naoki, jmadden, larry, minrk, ned.deily, python-dev, serhiy.storchaka, vstinner, wenzel, xiang.zhang
Priority: deferred blocker Keywords: patch

Created on 2016-09-14 11:44 by minrk, last changed 2017-03-31 16:36 by dstufft. This issue is now closed.

Files
File name Uploaded Description Edit
test-dict-pop.py minrk, 2016-09-14 11:44 test illustrating dict resize memory leak
0001-Avoid-unbounded-growth-in-dict_resize.patch minrk, 2016-09-14 11:47 patch to fix memory growth with regression test review
fix-28147.patch inada.naoki, 2016-09-14 20:09 review
fix-28147.patch inada.naoki, 2016-09-14 20:19 Add missing file review
fix-28147-py35.patch inada.naoki, 2016-09-16 15:16 review
fix28147-py36.patch inada.naoki, 2016-12-08 08:59 review
fix28147-py36-2.patch inada.naoki, 2016-12-08 09:05 review
fix28147-py36-3.patch inada.naoki, 2016-12-15 09:35 review
fix28147-comment-update.patch inada.naoki, 2016-12-15 11:08
fix-28147-py35-2.patch inada.naoki, 2016-12-19 17:51 review
Pull Requests
URL Status Linked Edit
PR 552 closed dstufft, 2017-03-31 16:36
Messages (51)
msg276418 - (view) Author: Min RK (minrk) * Date: 2016-09-14 11:44
There is a memory leak in the new dictionary resizing in 3.6, which can cause memory exhaustion in just a few iterations.

I don't fully understand the details of the bug, but it happens when resizing a dict with a split table several times.  The only way that I have found to trigger this is by popping items off of an object's `__dict__` repeatedly.

I've attached a script to illustrate the issue. Be careful with it, because it will eat up all your memory if you don't interrupt it.
msg276419 - (view) Author: Min RK (minrk) * Date: 2016-09-14 11:47
This patch fixes the memory leak in split-dict resizing.

Each time dict_resize is called, it gets a new, larger size `> minused`. If this is triggered many times, it will keep growing in size by a factor of two each time, as the previous size is passed as minused for the next call.

Set the lower bound at minused (inclusive), rather than exclusive, so that the size does not continue to increase for repeated calls.

A test is added to test_dict.py based on the earlier test script, but if someone has a simpler way to trigger the split-dict resize events, I'd be happy to see it.
msg276420 - (view) Author: Berker Peksag (berker.peksag) * (Python committer) Date: 2016-09-14 12:15
Can you wrap the test with @support.cpython_only decorator? The patch fixes the memory leak demonstrated in test-dict-pop.py.
msg276425 - (view) Author: Min RK (minrk) * Date: 2016-09-14 12:48
I can add the cpython_only decorator, but I'm not sure it is the right thing to do. I would expect the code in the test to pass on any Python implementation, which would suggest that it should not be cpython_only, right? If you still think so, I'll add it.
msg276428 - (view) Author: Inada Naoki (inada.naoki) * (Python committer) Date: 2016-09-14 12:57
I don't understand the leak yet.

> Each time dict_resize is called, it gets a new, larger size `> minused`. If this is triggered many times, it will keep growing in size by a factor of two each time, as the previous size is passed as minused for the next call.

dictresize() is called for converting split table to combined table.
How is it triggered many times?

In your test code, which loop cause leak? new instance loop or re-use instance loop?
msg276434 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2016-09-14 13:10
The CPython test suite uses a counter on memory allocations. Please add an unit test which triggers the memory leak, but you don't need many iterations. One iteartion should be enough to be catched by the unit test. Try: ./python -m test -R 3:3 test_dict.

The memory allocation counter:
https://docs.python.org/dev/library/sys.html#sys.getallocatedblocks

Note: The tracemalloc module can also be used to track memory leak, but it's harder to use it to write unit tests because Python uses a lot of internal caches and tracemalloc really tracks every single bytes.
msg276437 - (view) Author: Inada Naoki (inada.naoki) * (Python committer) Date: 2016-09-14 13:15
Ah, is the leak happen in 3.6b1?
dict.pop() in 3.6b1 doesn't combine split table.  It was a bug and
fixed in master branch already.

Regardless the leak, I agree that grow dict when popping is bad idea.
I'll improve your patch.
msg276450 - (view) Author: Min RK (minrk) * Date: 2016-09-14 13:47
> dictresize() is called for converting split table to combined table.
> How is it triggered many times?

every `self.__dict__.pop` triggers a resize. According to https://www.python.org/dev/peps/pep-0412/#split-table-dictionaries `obj.__dict__` is always a split-table dict. I do not understand the dict implementation enough to say precisely why, but `pop` forces a recombine via `resize` because split-table dicts don't support deletion. In `dict_resize`, due to a `<=minused` condition, the size is guaranteed to at least double every time `dict_resize` is called. It would appear that after this, `__dict__` is again forced to be a split-table dict, though I'm not sure how or where this happens, but good old-fashioned printf debugging shows that `dict_resize` is called for every `__dict__.pop` because _PyDict_HasSplitTable is true every time pop is called.


> In your test code, which loop cause leak? new instance loop or re-use instance loop?

Both loops cause the leak. If the `pop_attr()` is not in `__init__`, then only the re-used instance has the leak. if `pop_attr` is in `__init__`, then it happens across instances as well. I will try to add more comments in the code to make this clearer.

Does anyone have a handy way to create a split-table dict other than on `obj.__dict__`?


> Please add an unit test which triggers the memory leak

I should not have used the term memory leak, and have updated the title to be more precise. It is not memory allocated without a corresponding free, instead it is unbounded growth of the memory owned by a split-table dict. Cleaning up the object does indeed clean up the memory associated with it. The included test exercises the bug with several iterations. Running the test several times with only one iteration would not exercise the bug.
msg276451 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2016-09-14 13:51
> According to https://www.python.org/dev/peps/pep-0412/#split-table-dictionaries `obj.__dict__` is always a split-table dict.

Hum, this PEP is now probably outdated since Python 3.6 beta 1 :-)
msg276452 - (view) Author: Min RK (minrk) * Date: 2016-09-14 13:59
> Ah, is the leak happen in 3.6b1?

The leak happens in 3.6b1 and master as of an hour ago (git: 3c06edfe9463f1cf81bc34b702f165ad71ff79b8, hg:r103797)
msg276456 - (view) Author: Min RK (minrk) * Date: 2016-09-14 14:15
I pulled just now and saw changes in dictobject.c, and just wanted to confirm the memory growth bug is still in changeset 56294e03ad89 (I think I used the right hash, this time).
msg276477 - (view) Author: Inada Naoki (inada.naoki) * (Python committer) Date: 2016-09-14 19:10
I confirmed and investigated it.  Thanks!
I'll post patch including more test in 24 hours.
msg276481 - (view) Author: Xiang Zhang (xiang.zhang) * (Python committer) Date: 2016-09-14 19:27
> I confirmed and investigated it.  Thanks!
I'll post patch including more test in 24 hours.

Please wait a second.

The cause of this problem is that attribute setting causes a combined table to be splitted (the code path is [0]->[1]->[2]->[3]). So every time you set an attribute and then pop, it will do dictresize(right now it will increase memory usage). So even if you make pop() not increase memory usage, the example Min gives will still do much work not wanted (dictresize and make_keys_shared).

Actually I think memory usage increasing is not a problem if other things are right. popitem() before does the same thing and should never cause a problem.
 
[0] https://hg.python.org/cpython/file/tip/Python/ceval.c#l2248
[1] https://hg.python.org/cpython/file/tip/Objects/object.c#l1119
[2] https://hg.python.org/cpython/file/tip/Objects/object.c#l1125
[3] https://hg.python.org/cpython/file/tip/Objects/object.c#l1172
msg276482 - (view) Author: Xiang Zhang (xiang.zhang) * (Python committer) Date: 2016-09-14 20:03
> popitem() before does the same thing and should never cause a problem.

Ahh, this seems not true. Test it in py3.5 also crash.
msg276483 - (view) Author: Inada Naoki (inada.naoki) * (Python committer) Date: 2016-09-14 20:16
This issue is caused by dictresize() and _PyObjectDict_SetItem()

1. a.__dict__.pop('a') convert the dict to combined table which has double keysize.
2. a.a = 1  converts the dict to split table again if there are no instances sharing key with class.

As I wrote before, pop, popitem, and del should not increase key size.

And _PyObjectDict_SetItem shouldn't convert the dict to split-table when the dict doesn't share keys
with the class before calling PyDict_SetItem.
msg276502 - (view) Author: Inada Naoki (inada.naoki) * (Python committer) Date: 2016-09-15 02:15
xiang is right. Python 3.5 has same issue when using popitem().
I'll make patch for 3.5.  But it will be bit differ from patch for 3.6 and they will conflict.
msg276726 - (view) Author: Inada Naoki (inada.naoki) * (Python committer) Date: 2016-09-16 15:16
This is patch for Python 3.5.
The patch uses more conservative approach.
msg276895 - (view) Author: Xiang Zhang (xiang.zhang) * (Python committer) Date: 2016-09-18 15:01
LGTM. But why this change?

-#define ESTIMATE_SIZE(n)  (((n)*3) >> 1)
+#define ESTIMATE_SIZE(n)  (((n)*3+1) >> 1)
msg276901 - (view) Author: Inada Naoki (inada.naoki) * (Python committer) Date: 2016-09-18 17:44
xiang:
dictresize(d, n) may choose keysize==n (when n == 2**m) with this patch.

If there are any integer a such as ESTIMATE_SIZE(a) == n and n == 2**m and USABLE_FRACTION(n) == a - 1,
a items cannot be inserted into dict after dictresize(d, ESTIMATE_SIZE(a))

This is why ESTIMATE_SIZE should round up fraction.
msg276947 - (view) Author: Xiang Zhang (xiang.zhang) * (Python committer) Date: 2016-09-19 05:22
Ahh, I see.

> If there are any integer a such as ESTIMATE_SIZE(a) == n and n == 2**m and USABLE_FRACTION(n) == a - 1.

There are, such as 11, 43...

> a items cannot be inserted into dict after dictresize(d, ESTIMATE_SIZE(a))

It can but needs another resize in insertdict which breaks the intention of ESTIMATE_SIZE.

Then everything looks fine to me. :)
msg277614 - (view) Author: Inada Naoki (inada.naoki) * (Python committer) Date: 2016-09-28 13:16
haypo, Could you review fix-28147-py35.patch and fix-28147.patch ?

Draft NEWS entry:

- Issue #28147: Fixed split table dict may consume unlimited memory.
msg282635 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2016-12-07 17:17
This issue seems to have slipped through. Should it be a release blocker for 3.6.0 final or can it wait for 3.6.1?
msg282642 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2016-12-07 17:41
Calling pop() for instance's __dict__ is not common operation. I expected that this bug does not affect any real code. But the case in issue28894 looks as a real case. This might be a release blocker.
msg282643 - (view) Author: Inada Naoki (inada.naoki) * (Python committer) Date: 2016-12-07 17:45
> Ned Deily added the comment:
>
> This issue seems to have slipped through. Should it be a release blocker for 3.6.0 final or can it wait for 3.6.1?

On Python 3.5, instance.__dict__.popitem() cause this issue.
On Python 3.6, instance.__dict__.popitem() and instance.__dict__.pop()
cause this issue.

This is not new issue, but there is small regression.

I don't know this should be fixed in 3.6.0.
I'll make patch smaller anyway.
msg282648 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2016-12-07 18:09
In this case, I suggest to wait for 3.6.1 to fix it.
msg282650 - (view) Author: Xiang Zhang (xiang.zhang) * (Python committer) Date: 2016-12-07 18:34
__dict__.pop seems not uncommon. Searching Github could give many practical codes using it. And many of them are acting as generic containers and could be used against massive cases.
msg282672 - (view) Author: Min RK (minrk) * Date: 2016-12-07 22:07
This affects IPython (specifically the traitlets component), which is what prompted the report. We were able to push out a release of traitlets with a workaround for the bug (4.3.1), but earlier versions of IPython / traitlets will still be affected (all IPython >= 4, traitlets 4.0 <= v < 4.3.1). So I hope 3.6.0 will be released with the fix attached here.
msg282682 - (view) Author: Inada Naoki (inada.naoki) * (Python committer) Date: 2016-12-08 03:18
Which revision should I make patch based on? 3.6 branch? or 3.6rc1 tag?

After 3.6rc1 is tagged, I pushed optimization which contains same one line change.

https://hg.python.org/cpython/rev/d03562dcbb82

-#define ESTIMATE_SIZE(n)  (((n)*3) >> 1)
+#define ESTIMATE_SIZE(n)  (((n)*3+1) >> 1)
msg282683 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2016-12-08 03:26
Just follow the normal 3.6 branch which will ensure it gets into 3.6.1.  If we end up deciding to also add it to 3.6.0 final, I will handle the cherrypicking.
msg282699 - (view) Author: Inada Naoki (inada.naoki) * (Python committer) Date: 2016-12-08 08:59
Here is patch for Python 3.6.
msg282702 - (view) Author: Inada Naoki (inada.naoki) * (Python committer) Date: 2016-12-08 09:55
http://bugs.python.org/issue28894 was duplicate of this issue.

Since real world program suffered by this, I'm +1 to fix this by 3.6.0
msg282743 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2016-12-08 23:23
I think these proposed patches need careful review but, even so, given the extent of the fix28147-py36-2.patch changes, I don't think they should go into 3.6.0 at the last minute.  Unless somebody can convince me otherwise, I'm going to let this wait for 3.6.1.
msg283246 - (view) Author: Wenzel Jakob (wenzel) Date: 2016-12-15 06:54
Hi,

pybind11 (https://github.com/pybind/pybind11) dev here.

We're seeing massive memory increases due to this bug, which completely break our test suite (and likely any use of this library, which is commonly used to bind C++ code to Python).

Please look at the following issue ticket:

https://github.com/pybind/pybind11/issues/558

where RSS goes to 43MB to 4.3GB for the basic set of tests. The fancy fancy test suite which also covers NumPy/SciPy can't even be run anymore. All issues disappear when the dict patch listed here is applied.

We're really concerned that this is not slated to be fixed for 3.6.0. Pybind11 is not doing anything particularly special with dicts -- if this is hitting us, others will likely have issues as well.

-Wenzel
msg283259 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2016-12-15 08:41
It appears this issue has stalled again.  Is the most recent patch fix28147-py36-2.patch) ready for review?  If so, can someone please review it?  Then it needs to be pushed to the 3.6 branch for 3.6.1 and exposed to the buildbots.  Only then could we consider cherrypicking for 3.6.0 and a change of the magnitude in the patch would require at least another preview release and delay 3.6.0 final. 3.6.0 is scheduled to be released tomorrow. I am very reluctant to delay now for an issue that has been open now for 3 months throughout the beta phase of the release cycle.  If enough people feel we should delay 3.6.0 to address this, we can.  But without a fix reviewed and committed and without more feedback from other core developers, 3.6.0 is going out without it.  @inada.naoki ? @haypo ? @serhiy.storchaka ?  Others?
msg283264 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2016-12-15 09:23
fix28147-py36-2.patch: test_dict pass with DEBUG_PYDICT defined.
msg283267 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2016-12-15 09:36
I reviewed fix28147-py36-2.patch, I have some requests.
msg283268 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2016-12-15 09:40
Ned: "If so, can someone please review it?"

Done.


Ned: "I am very reluctant to delay now for an issue that has been open now for 3 months throughout the beta phase of the release cycle.  If enough people feel we should delay 3.6.0 to address this, we can."

The bug was seen as minor and I didn't expect that anyone would notice it.

Wenzel Jakob wrote "RSS goes to 43MB to 4.3GB": for me, it's a major regression, and it's not possible to work around it. With such bug, Python 3.6 is unusable on such application (pybind11). I easily imagine that such memory leak is a blocker issue for a server running for days.

I now consider that Python 3.6.0 must not be released with such blocker issue.
msg283270 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2016-12-15 09:42
fix28147-py36-3.patch LGTM: Naoki, please push it right now.

But please see also my comments on fix28147-py36-2.patch: I would still apprecicate that we enhance the comment in dictobject.c. The comment is not a blocker issue for 3.6.0, it can be enhanced later :-D
msg283283 - (view) Author: Inada Naoki (inada.naoki) * (Python committer) Date: 2016-12-15 11:08
This patch updates the comment.
msg283334 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2016-12-15 16:23
New changeset 85be9dcc16a8 by Victor Stinner in branch '3.6':
Fix a memory leak in split-table dictionaries
https://hg.python.org/cpython/rev/85be9dcc16a8
msg283335 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2016-12-15 16:25
I dislike pushing a change written by another core dev, I prefer that he/she directly push it, but we are out of time. Ned asked to first push to Python 3.6 to get a confirmation of buildbots, before being able to ask for a cherry-pick in 3.6.0 final.

Anyway, thanks for the fix Naoki!
msg283337 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2016-12-15 18:04
I think this can be tested without _testcapi. See an example in issue28894.
msg283339 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2016-12-15 18:21
I asked a question about the change in _PyObjectDict_SetItem. It is not clear to me.
msg283374 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2016-12-16 07:44
New changeset b70b2d3f3167 by Victor Stinner in branch '3.6':
Fix a memory leak in split-table dictionaries
https://hg.python.org/cpython/rev/b70b2d3f3167
msg283386 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2016-12-16 07:57
[cherrypicked for 3.6.0rc2]
msg283392 - (view) Author: Inada Naoki (inada.naoki) * (Python committer) Date: 2016-12-16 08:33
Oh, I'm sorry.  It seems I had failed to push the commit yesterday.
msg283395 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2016-12-16 09:24
> Oh, I'm sorry.  It seems I had failed to push the commit yesterday.

No problem. Thanks for your fix! I prefer to not see the bug in Python
3.6.0 final!
msg283468 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2016-12-17 05:15
So now that a fix has been released with 3.6.0rc2, what else needs to be done to close this issue?  Why is 3.5 selected in the applicable versions?
msg283478 - (view) Author: Inada Naoki (inada.naoki) * (Python committer) Date: 2016-12-17 09:26
Before Python 3.6, instance.__dict__.pop(key) didn't trigger this.
But there are many way to trigger this. This bug is live from 3.3.
This script reproduce this issue on Python 3.5.

class C: pass
a = C()
a.a = 1
while True:
    a.__dict__.popitem()  # convert split table into combined table.
    a.a = 1   # convert combined table into split table again.
msg283644 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2016-12-19 18:45
The 3.5 patch LGTM.
msg283659 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2016-12-20 00:54
New changeset cc40470c10f8 by INADA Naoki in branch '3.5':
Issue #28147: Fix a memory leak in split-table dictionaries
https://hg.python.org/cpython/rev/cc40470c10f8
History
Date User Action Args
2017-03-31 16:36:26dstufftsetpull_requests: + pull_request1001
2016-12-20 01:05:08inada.naokisetstatus: open -> closed
resolution: fixed
stage: commit review -> resolved
2016-12-20 00:54:38python-devsetmessages: + msg283659
2016-12-19 18:45:51vstinnersetmessages: + msg283644
2016-12-19 17:51:56inada.naokisetfiles: + fix-28147-py35-2.patch
2016-12-17 09:26:43inada.naokisetmessages: + msg283478
2016-12-17 05:15:22ned.deilysetmessages: + msg283468
2016-12-16 09:24:59vstinnersetmessages: + msg283395
2016-12-16 08:33:55inada.naokisetmessages: + msg283392
2016-12-16 07:57:17ned.deilysetpriority: release blocker -> deferred blocker

messages: + msg283386
2016-12-16 07:44:44python-devsetmessages: + msg283374
2016-12-15 18:21:28serhiy.storchakasetmessages: + msg283339
2016-12-15 18:04:51serhiy.storchakasetmessages: + msg283337
2016-12-15 16:25:16vstinnersetmessages: + msg283335
2016-12-15 16:23:51python-devsetnosy: + python-dev
messages: + msg283334
2016-12-15 11:08:25inada.naokisetfiles: + fix28147-comment-update.patch

messages: + msg283283
2016-12-15 09:42:47vstinnersetmessages: + msg283270
2016-12-15 09:40:18vstinnersetpriority: deferred blocker -> release blocker
nosy: + larry
messages: + msg283268

2016-12-15 09:36:05vstinnersetmessages: + msg283267
2016-12-15 09:35:10inada.naokisetfiles: + fix28147-py36-3.patch
2016-12-15 09:23:56vstinnersetmessages: + msg283264
2016-12-15 09:08:10ned.deilysetpriority: high -> deferred blocker
2016-12-15 08:41:37ned.deilysetmessages: + msg283259
2016-12-15 06:54:12wenzelsetnosy: + wenzel
messages: + msg283246
2016-12-08 23:23:06ned.deilysetmessages: + msg282743
2016-12-08 12:49:36jmaddensetnosy: + jmadden
2016-12-08 09:55:55inada.naokisetmessages: + msg282702
2016-12-08 09:05:52inada.naokisetfiles: + fix28147-py36-2.patch
2016-12-08 08:59:08inada.naokisetfiles: + fix28147-py36.patch

messages: + msg282699
2016-12-08 03:26:44ned.deilysetmessages: + msg282683
2016-12-08 03:18:11inada.naokisetmessages: + msg282682
2016-12-07 22:07:01minrksetmessages: + msg282672
2016-12-07 18:34:55xiang.zhangsetmessages: + msg282650
2016-12-07 18:09:43vstinnersetmessages: + msg282648
2016-12-07 17:45:27inada.naokisetmessages: + msg282643
2016-12-07 17:41:53serhiy.storchakasetmessages: + msg282642
2016-12-07 17:17:01ned.deilysetnosy: + ned.deily
messages: + msg282635
2016-12-07 14:58:58xiang.zhanglinkissue28894 superseder
2016-11-06 15:28:46serhiy.storchakasetnosy: + serhiy.storchaka
2016-10-25 06:11:35inada.naokisetpriority: normal -> high
stage: patch review -> commit review
2016-09-28 13:16:34inada.naokisetmessages: + msg277614
2016-09-26 23:57:16inada.naokisetversions: + Python 3.5
2016-09-19 05:22:30xiang.zhangsetmessages: + msg276947
2016-09-18 17:44:35inada.naokisetmessages: + msg276901
2016-09-18 15:01:36xiang.zhangsetmessages: + msg276895
2016-09-16 15:16:55inada.naokisetfiles: + fix-28147-py35.patch

messages: + msg276726
2016-09-15 02:15:36inada.naokisetmessages: + msg276502
2016-09-14 20:19:44inada.naokisetfiles: + fix-28147.patch
2016-09-14 20:16:59inada.naokisetmessages: + msg276483
2016-09-14 20:09:13inada.naokisetfiles: + fix-28147.patch
2016-09-14 20:03:38xiang.zhangsetmessages: + msg276482
2016-09-14 19:27:50xiang.zhangsetnosy: + xiang.zhang
messages: + msg276481
2016-09-14 19:10:01inada.naokisetmessages: + msg276477
2016-09-14 14:15:07minrksetmessages: + msg276456
2016-09-14 13:59:04minrksetmessages: + msg276452
title: Memory leak in new 3.6 dictionary resize -> Unbounded memory growth resizing split-table dicts
2016-09-14 13:51:38vstinnersetmessages: + msg276451
2016-09-14 13:47:11minrksetmessages: + msg276450
2016-09-14 13:15:28inada.naokisetmessages: + msg276437
2016-09-14 13:10:30vstinnersetmessages: + msg276434
2016-09-14 12:57:15inada.naokisetmessages: + msg276428
2016-09-14 12:48:53minrksetmessages: + msg276425
2016-09-14 12:15:07berker.peksagsetnosy: + berker.peksag, vstinner, inada.naoki

messages: + msg276420
stage: patch review
2016-09-14 11:47:41minrksettitle: Memory leak in dictionary resize -> Memory leak in new 3.6 dictionary resize
2016-09-14 11:47:08minrksetfiles: + 0001-Avoid-unbounded-growth-in-dict_resize.patch
keywords: + patch
messages: + msg276419
2016-09-14 11:44:13minrkcreate