Bug #1663

Mem Leak: 1.4.19-0ubuntu3 + torrentflux + php5 + download as zip on Ubuntu 8.04

Added by Anonymous 238 days ago. Updated 232 days ago.

Status:Fixed Start:
Priority:High Due date:
Assigned to:- % Done:

0%

Category:core
Target version:1.5.0
Pending:

No

Resolution:

duplicate


Description

I am running Fresh Ubuntu Linux 8.04 install with the packaged lighttpd version and torrentflux_2.3.tar.gz. I am not 100% sure if I am using fastcgi or normal cgi since both are enabled. I suspect normal CGI ( let me know the easy way to tell if it's important).

Noticed a memory problem on the box after I used the "download as a zip" function in torrentflux. Memory usage of lighttpd increases by roughly the size of the file and doesn't decrease afterwards. Further downloads keep increasing file size.

To duplicate:

Install Ubuntu Server 8.04
Install Torrentflux version above ( using mysql backend but probably important)

Config bits:

server.modules = (
"mod_access",
"mod_alias",
"mod_accesslog",
"mod_compress",
"mod_rewrite",
"mod_redirect",
  1. "mod_status",
  2. "mod_evhost",
  3. "mod_usertrack",
  4. "mod_rrdtool",
  5. "mod_webdav",
  6. "mod_expire",
  7. "mod_flv_streaming",
  8. "mod_evasive"
    )
  1. .php, .pl, .fcgi are most often handled by mod_fastcgi or mod_cgi
    static-file.exclude-extensions = ( ".php", ".pl", ".fcgi" , ".cgi" )
  1. compress module
    compress.cache-dir = "/var/cache/lighttpd/compress/"
    compress.filetype = ("text/plain", "text/html", "application/x-javascript", "text/css")

Modules:

cgi, fastcgi , simple-vhost

In torrentflux:

- Add a user (just the initual one will do)
- Using you shell account create a directory with some largish (megabytes) files in it in the users download directory ( /www//torrentflux/downloads/ )
- Navigate to users home directory in torrentflux
- Use the yellow "download as zip" button in torrentflux on this directory

Watch memory usage as file downloads and afterwards.

I grabbed strace and valgrind memleaks stuff. I'll emailURLs for these to Jan

-- Simon Lyall

History

05/14/2008 11:04 AM - hoffie

It's not a real memory leak as the memory does not get lost (it is re-used later). It's a design problem in 1.4 which cannot be fixed easily, don't expect 1.4 to be ever fixed.

05/14/2008 11:21 AM - Anonymous

Replying to hoffie:

It's not a real memory leak as the memory does not get lost (it is re-used later). It's a design problem in 1.4 which cannot be fixed easily, don't expect 1.4 to be ever fixed.

This afternoon I had lighttpd using 1GB on a machine with just 512MB of RAM :(

-- Simon Lyall

05/14/2008 11:25 AM - hoffie

Well, that happens if you send huge files (or multiple "small" files concurrently) over *cgi. The proper way is to use X-Sendfile, *cgi was never designed to allow for such tasks. And well, lighty just happens to handle this case not as gracefully as other servers might do.

05/20/2008 06:02 PM - admin

Replying to hoffie:

The proper way is to use X-Sendfile,

That only works for files that exist already in the filesystem.

*cgi was never designed to allow for such tasks. And well, lighty just happens to handle this case not as gracefully as other servers might do.

You mean Lighttpd's implementation wasn't designed for cases like this?

05/20/2008 08:05 PM - stbuehler

  • Status changed from New to Fixed
  • Resolution set to duplicate

No real memleak, known problem. And won't fix in 1.4.

Also available in: Atom PDF