Bug #1693


Memory Leak in stat_cache.c Found

Added by Anonymous almost 15 years ago. Updated over 14 years ago.

Target version:


I use lighttpd to serve an average of about 300mb/s of traffic across 30servers. They all serve images to users, and I have been noticing a serious memory leak while using 1.5.x. After running things in valgrind for a while, I determined that the leaked memory was being allocated from:

line 324 of stat_cache.c:
g_hash_table_insert(sc->files, buffer_init_string(BUF_STR(sc->hash_key)), sce);

The buffer_init_string() call will allocate a new buffer, but in the error conditions below it in lines 373 to 383 can return without freeing the memory allocated on line 324. This memory will not cleaned up in the standard stat_cache_trigger_cleanup() path because in this error case the state of the stat cache entry is never changed from STAT_CACHE_ENTRY_UNSET.

In order to fix this, I had to stash a pointer to this buffer in the stat cache entry itself, and in those error conditions, free the memory, the stat cache entry, and remove the entry from the stat cache's g_hash_table. Valgrind confirms the fix worked.

An easy way to reproduce this is to serve a lot of 404's in order to hit the error conditions described above.

I'm not sure if this is related at all to #1667, but it appears like it could be the issue in #1363.

-- gc3


Related issues 1 (0 open1 closed)

Has duplicate Bug #1363: Memory leak in stat_cache.c on a 64bit serverObsoleteActions
Actions #1

Updated by jrabbit almost 15 years ago

#1363 might still be a different issue: with that bug, I had a steady leak on each and every hit and there was no need for error cases. However, it was only in the alternate code path used when the glib2 package wasn't available - if you have that installed on your system (glib-devel package on RHEL/centos) then this is a different issue.

Actions #2

Updated by peto over 14 years ago

I see this issue with r2294. The error cases should delete the hash entry before returning.

This is a critical issue: it's a memory leak that can trivially be used as a remote denial-of-service attack.

Actions #3

Updated by peto over 14 years ago

Live for a day with no issues. I'm still seeing memory issues in r2294 (file-only server up to 108 megs) that I havn't tracked down, but this one should be fixed.

Alternate patch coming...

Actions #4

Updated by stbuehler over 14 years ago

  • Status changed from Patch Pending to Fixed
  • % Done changed from 0 to 100

Applied in changeset r2356.


Also available in: Atom