Project

General

Profile

Actions

Bug #1663

closed

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

Added by Anonymous almost 16 years ago. Updated almost 16 years ago.

Status:
Fixed
Priority:
High
Category:
core
Target version:
ASK QUESTIONS IN Forums:

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

Actions #1

Updated by hoffie almost 16 years ago

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.

Actions #2

Updated by Anonymous almost 16 years ago

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

Actions #3

Updated by hoffie almost 16 years ago

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.

Actions #4

Updated by admin almost 16 years ago

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?

Actions #5

Updated by stbuehler almost 16 years ago

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

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

Actions

Also available in: Atom