Project

General

Profile

Actions
Copy link

Bug #1931

closed

Lighttpd bloats memory over time, and leaves what looks like physical path strings in malloc'd memory

Added by wormzer about 15 years ago. Updated about 15 years ago.

Status:
Fixed
Priority:
Normal
Category:
-
Target version:
-
ASK QUESTIONS IN Forums:

Description

I have several long-running lighttpd processes and memory has grown > 500mb on some after running 3 months under heavy load.

I've been looking into the memory problems and looked at the /proc/pid/smaps and have found several 2mb anonymous mmap'd regions. I gdb attached to the server for a moment and did a memory dump to file along with grabbing a dump of just one of them.

I found several strings, that look to be physical.path strings throughout the memory dump, and each path was listed not just once, but twice. What's even more strange is one of the two duplicate entries has a "1" appended to the end.

I looked in my access logs and found that some of these files do not even exist on disk and resulted in a 404 error.

The lighttpd configuration I'm using uses mod_rewrite and mod_alias to map the uri directly to a physical path. I am running fcgi backends but best I can tell they are not in play here.

I am not able at this point to change any of the configurations on the operating installation and have not been able to reproduce these leaks with my own separate testing.

Actions
Copy link
 #1

Updated by wormzer about 15 years ago

This is 1.5.0 running from svn change #2000 (somewhat old I know)

Actions
Copy link
 #2

Updated by icy about 15 years ago

  • Status changed from New to Need Feedback

Please update your version, this should have been fix some time ago.

Actions
Copy link
 #3

Updated by wormzer about 15 years ago

  • Status changed from Need Feedback to Patch Pending

icy wrote:

Please update your version, this should have been fix some time ago.

Great! Can you point me to the fix that solves this issue? Or what conditions caused this bug? I have been unable to reproduce this in testing and will need to verify the fix before deploying on the website.

Actions
Copy link
 #4

Updated by icy about 15 years ago

  • Status changed from Patch Pending to Need Feedback

The commit that fixed this should be r2356 if I haven't mixed something up.
You see physical paths in the memory because they are in the stat cache (which had a leak).
You should not only commit that patch but just update to the latest revision. At least I'd recommend that.

Actions
Copy link
 #5

Updated by wormzer about 15 years ago

icy wrote:

The commit that fixed this should be r2356 if I haven't mixed something up.
You see physical paths in the memory because they are in the stat cache (which had a leak).
You should not only commit that patch but just update to the latest revision. At least I'd recommend that.

Ok, I'm going to try to reproduce this. Is there an explanation for the additional physical path leak with a literal "1" appended?

Thanks so much for the help!

Actions
Copy link
 #6

Updated by wormzer about 15 years ago

Did I answer my on question by looking at the stat cache code?

buffer_copy_string_buffer(sc->hash_key, name);
        buffer_append_long(sc->hash_key, con->conf.follow_symlink);

That sure looks like what I'm seeing. I had grep'd for append_long int the code, but had assumed that "hash_key" was a hashed path, not the actual path. Should have looked harder.

Thanks again for the quick help.

Actions
Copy link
 #7

Updated by wormzer about 15 years ago

I've confirmed that this fixes the problem. The key to reproducing this problem is to load endless missing files. For each 404 for a NEW physical path, one stat-cache entry will be leaked.

Actions
Copy link
 #8

Updated by icy about 15 years ago

  • Status changed from Need Feedback to Fixed
Actions
Copy link

Also available in: Atom