Message168066
| Author |
skrah |
| Recipients |
meador.inge, skrah |
| Date |
2012年08月12日.22:36:26 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1344810987.5.0.762502688865.issue15632@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
I'm attaching a test case. You're right, in test_buffer it's
hard to reproduce but I've encountered the "leak" several times
in the past months.
Today I realized that the "leak" always occurred with format code
'c'. There's this passage in test_buffer:
x = randrange(*fmtdict[mode][char])
if char == 'c':
x = bytes(chr(x), 'latin1')
After some head scratching I looked into regrtest.py and found
the warm_char_cache() function. The whole thing makes sense: In
each repetition of the refleak mode new characters can be added
to the unicode_latin1 cache.
So, you should be able to reproduce the issue:
$ ./python -m test -uall -R 2:2 test_pseudo_leak
[1/1] test_pseudo_leak
beginning 4 repetitions
1234
....
test_pseudo_leak leaked [8, 8] references, sum=16
1 test failed:
test_pseudo_leak
[151225 refs] |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2012年08月12日 22:36:27 | skrah | set | recipients:
+ skrah, meador.inge |
| 2012年08月12日 22:36:27 | skrah | set | messageid: <1344810987.5.0.762502688865.issue15632@psf.upfronthosting.co.za> |
| 2012年08月12日 22:36:26 | skrah | link | issue15632 messages |
| 2012年08月12日 22:36:26 | skrah | create |
|