The following code causes memory usage to grow excessively.

'''
import shelve

def func():
    for i in range(1000000):
        sh = shelve.open('blah')
        sh.close()

func()
'''

What happens if you use xrange instead of range?

>>> range(1000000).__sizeof__()
8000056
>>> xrange(1000000).__sizeof__()
56

Put it in the while loop. Same result. Memory usage grows about 1 GiB per minute.

Sorry, I'm not able to reproduce any major memory leak, using a couple of different dbm implementations, and there is not enough information to go on.

To pursue further, you should identify:
- what platform (operating system distribution and version)
- exactly what version of Python you are using and its origins (if not provided by the operating system distribution):
    python2.7 -c 'import sys;print(sys.version)'
- a test case that shows exactly what you run and how you determine that memory is growing
- after running the test (and possibly aborting it) and the database file "blah" has been created:
    python2.7 -c 'import whichdb;print(whichdb.whichdb("blah"))'
That should show which dbm is being used.

I modified the example a little bit to display the RSS memory 10 times. The RSS increases by +176 kB at the beginning and then it is stable.

I tested on Fedora 20 (Linux): anydbm.open('bla', 'c') creates a 'bsddb._DBWithCursor' object. Can you please give us the DBM type returned by:

$ ./python
Python 2.7.8+ (2.7:9b4673d7b046, Oct  1 2014, 00:20:22) 
>>> import anydbm
>>> d=anydbm.open('bla', 'c')
>>> type(d)
<class 'bsddb._DBWithCursor'>
>>> d.close()

The loop of your example can maybe by simplified to:

d=anydbm.open('bla', 'c')
d.close()

instead of

sh = shelve.open('blah')
sh.close()

Thanks for the help. For my linux box, I have no issue. This is Ubuntu 13.10:

    Linux localhost 3.11.0-26-generic #45-Ubuntu SMP Tue Jul 15 04:02:06 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

    2.7.5+ (default, Feb 27 2014, 19:37:08) 
    [GCC 4.8.1]

However, I'm still getting issues with my other box, which is Mac OS. I think I have the relevant info here (let me know if we need additional info):

    [10:55:00] ~$ sw_vers -productVersion
    10.9.2

    [10:55:10] ~$ python -c "import sys; print sys.version"
    2.7.8 (default, Aug 21 2014, 20:13:48) 
    [GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)]

    [10:55:57] ~$ python -c "import anydbm;d = anydbm.open('bla', 'c');print(type(d))"
    <class 'bsddb._DBWithCursor'>

    [10:56:05] ~$ cat leaktest.py
    import anydbm
    while True:
        d = anydbm.open('bla', 'c')
        d.close()

    [10:56:10] ~$ python leaktest.py &
    [1] 99030

    [10:56:18] ~$ ps -o pid,rss,vsz,command -p 99030
      PID    RSS      VSZ COMMAND
    99030 481928  3010600 python leaktest.py

    [10:56:56] ~$ ps -o pid,rss,vsz,command -p 99030
      PID    RSS      VSZ COMMAND
    99030 3985920  6516788 python leaktest.py

    [11:01:10] ~$ # After 5 minutes, "top" shows MEM as 13G

    [11:01:23] ~$ ps -o pid,rss,vsz,command -p 99030
      PID    RSS      VSZ COMMAND
    99030 13891152 16429156 python leaktest.py

Those numbers are stable on my Linux box, and ever growing on Mac.

No issue with 3.4 on the Mac box.

> [10:55:57] ~$ python -c "import anydbm;d = anydbm.open('bla', 'c');print(type(d))"
> <class 'bsddb._DBWithCursor'>

Hum, on Mac OS X, I don't have the bsddb module installed by default. How did you install it?

Thanks for the detailed information.  I'm not able to reproduce on OS X 10.9.5 with the python.org Python 2.7.8 which builds and links with its own copy of Sleepycat DB 4.7.25.  However, I do see the memory leak when using a MacPorts Python 2.7.8 that is linked with a MacPorts copy of Sleepycat DB 4.6.

I should have mentioned that this a Macports environment. So python, bsddb all come from there. Looks like that might be the culprit.

Yeah, and I'm not sure why they have their build pegged to bdb 4.6; they provide newer ports as well.  I think we can close this issue then.  Perhaps you could open a MacPorts issue and ask them to update their python27 port to use at least db47.

For future visitors, here is the MacPorts issue:

    https://trac.macports.org/ticket/45247