Browse Source
For ports that have a system malloc which is not garbage collected (eg unix, esp32), the stream object for the DB must be retained separately to prevent it from being reclaimed by the MicroPython GC (because the berkeley-db library uses malloc to allocate the DB structure which stores the only reference to the stream). Although in some cases the user code will explicitly retain a reference to the underlying stream because it needs to call close() on it, this is not always the case, eg in cases where the DB is intended to live forever. Fixes issue #5940.pull/5946/head
Damien George
5 years ago
4 changed files with 108 additions and 3 deletions
@ -0,0 +1,23 @@ |
|||
# Test btree interaction with the garbage collector. |
|||
|
|||
try: |
|||
import btree, uio, gc |
|||
except ImportError: |
|||
print("SKIP") |
|||
raise SystemExit |
|||
|
|||
N = 80 |
|||
|
|||
# Create a BytesIO but don't keep a reference to it. |
|||
db = btree.open(uio.BytesIO(), pagesize=512) |
|||
|
|||
# Overwrite lots of the Python stack to make sure no reference to the BytesIO remains. |
|||
x = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] |
|||
|
|||
# Write lots of key/value pairs, which fill up the DB and also allocate temporary heap |
|||
# memory due to the string addition, and do a GC collect to verify that the BytesIO |
|||
# is not collected. |
|||
for i in range(N): |
|||
db[b"thekey" + str(i)] = b"thelongvalue" + str(i) |
|||
print(db[b"thekey" + str(i)]) |
|||
gc.collect() |
@ -0,0 +1,80 @@ |
|||
b'thelongvalue0' |
|||
b'thelongvalue1' |
|||
b'thelongvalue2' |
|||
b'thelongvalue3' |
|||
b'thelongvalue4' |
|||
b'thelongvalue5' |
|||
b'thelongvalue6' |
|||
b'thelongvalue7' |
|||
b'thelongvalue8' |
|||
b'thelongvalue9' |
|||
b'thelongvalue10' |
|||
b'thelongvalue11' |
|||
b'thelongvalue12' |
|||
b'thelongvalue13' |
|||
b'thelongvalue14' |
|||
b'thelongvalue15' |
|||
b'thelongvalue16' |
|||
b'thelongvalue17' |
|||
b'thelongvalue18' |
|||
b'thelongvalue19' |
|||
b'thelongvalue20' |
|||
b'thelongvalue21' |
|||
b'thelongvalue22' |
|||
b'thelongvalue23' |
|||
b'thelongvalue24' |
|||
b'thelongvalue25' |
|||
b'thelongvalue26' |
|||
b'thelongvalue27' |
|||
b'thelongvalue28' |
|||
b'thelongvalue29' |
|||
b'thelongvalue30' |
|||
b'thelongvalue31' |
|||
b'thelongvalue32' |
|||
b'thelongvalue33' |
|||
b'thelongvalue34' |
|||
b'thelongvalue35' |
|||
b'thelongvalue36' |
|||
b'thelongvalue37' |
|||
b'thelongvalue38' |
|||
b'thelongvalue39' |
|||
b'thelongvalue40' |
|||
b'thelongvalue41' |
|||
b'thelongvalue42' |
|||
b'thelongvalue43' |
|||
b'thelongvalue44' |
|||
b'thelongvalue45' |
|||
b'thelongvalue46' |
|||
b'thelongvalue47' |
|||
b'thelongvalue48' |
|||
b'thelongvalue49' |
|||
b'thelongvalue50' |
|||
b'thelongvalue51' |
|||
b'thelongvalue52' |
|||
b'thelongvalue53' |
|||
b'thelongvalue54' |
|||
b'thelongvalue55' |
|||
b'thelongvalue56' |
|||
b'thelongvalue57' |
|||
b'thelongvalue58' |
|||
b'thelongvalue59' |
|||
b'thelongvalue60' |
|||
b'thelongvalue61' |
|||
b'thelongvalue62' |
|||
b'thelongvalue63' |
|||
b'thelongvalue64' |
|||
b'thelongvalue65' |
|||
b'thelongvalue66' |
|||
b'thelongvalue67' |
|||
b'thelongvalue68' |
|||
b'thelongvalue69' |
|||
b'thelongvalue70' |
|||
b'thelongvalue71' |
|||
b'thelongvalue72' |
|||
b'thelongvalue73' |
|||
b'thelongvalue74' |
|||
b'thelongvalue75' |
|||
b'thelongvalue76' |
|||
b'thelongvalue77' |
|||
b'thelongvalue78' |
|||
b'thelongvalue79' |
Loading…
Reference in new issue