Bug #3623
libsqlfs memory leak
| Status: | New | Start date: | 08/07/2014 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | - | % Done: | 0% | |
| Category: | - | |||
| Target version: | 0.3.1 | |||
| Component: |
Description
There seems to be a memory leak in libsqlfs, but it is hard to characterize. It seems related to transactions more than total data written, e.g. lots of small operations increases the leak faster than few large transactions. For example, `./tests/fsx -W /mnt/testfile8` seems to leak memory faster than `./tests/fsx -c 1 -W -l 80485760 -o 40485760 /mnt/testfile8`.
There is an obvious memory leak in sqlfs_t_init() because it calloc()@s memory for a @sqlfs_t but never @free()@s it. But that is only something like 8 bytes per leak, so my guess it is something else.
In any case, I don't think it is a show stopper, fsx does so many transactions that it is not really like any real world use.
History
#1 Updated by hans over 3 years ago
At this point, I've narrowed it down. There seems to be a memory leak only during writes, not reading reads or truncates. valgrind points to the internals of sqlite as the place where the leak is happening, and the sqlite docs mention that write transactions need to be cleaned up properly. So my guess is that something is not getting properly cleaned up in the write transactions...
#2 Updated by hans over 3 years ago
- Target version set to 0.3
#3 Updated by hans almost 3 years ago
- Target version changed from 0.3 to 0.3.1