ResourceWarning: unclosed file "BufferedRandom" appear randomly

[JonathanHuot]

Hi, I'm running latest bottle version from github (today) with default engine and python 3.4.1. Sometime, I got this weird message (memory leak?) on console output :

.../dev/lib/python3.4/site-packages/bottle.py:1661: ResourceWarning: unclosed file <_io.BufferedRandom name=6>
  def fset(_, value): ls.var = value

Let me know if you need anything else. Thanks

[defnull]

I don't know how to fix it in a backwards compatible way. The BufferedRandom object is the request body cached in environ['bottle.request.body'] and dereferenced as soon as the next request arrives. Bottle cannot close it because the application might hold a reference to it. Any ideas?

[mcr-ksh]

same issue here. Just reported

[x-yuri]

See here.

I don't know how to fix it in a backwards compatible way.

@defnull You can at least update the documentation. I wonder what is the backwards incompatible way though.

[defnull]

I wonder what is the backwards incompatible way though.

Bottle could close the body file handle after each request, but that would break applications that pass the body to a separate thread or want to do something with it after the request ends.

[defnull]

The current behaviour (close it once it is no longer referenced) is exactly what you would want. It's only the warning that is annoying.

[defnull]

Turns out using NamedTemporaryFile instead of TemporaryFile fixes the ResourceWarning in most cases because NamedTemporaryFile (indirectly) implements __del__ to explicitly close (and remove) the file. This is not needed for TemporaryFile because these are unlinked immediately, which is why these are still technically 'open' when the garbage collector collects the file, which in turn triggers the warning.

Only downside is that on a hard crash, a temporary file may remain on disk, so this is not an ideal solution. Deprecating a request.body that lives longer than the request and switching back to TemporaryFile might be the cleaner option. Until then, I'll consider this fixed (in master). I'll keep this issue open for now, because I'm still not really happy.