Closed pepyakin closed 4 years ago
Hmm. I just noticed urkel_tx_inject
probably has a leak: https://github.com/chjj/liburkel/blob/master/src/tree.c#L937
Any chance the fuzzer is calling that?
Another leak fixed in urkel_tx_clear. This is what I get for porting from a GC'd language I guess.
Any chance the fuzzer is calling that?
yup, I think I cover most of the API (excluding those functions that duplicate cursor)
with the latest commit the memory consumption is steady and there are no reports from LeakSanitizer. That is, on linux. On macOS there are also no reports, but for some reason still RSS climbs : ?
@pepyakin very strange that apple produces different results than linux. That makes me think this has something to do with an OS call, but I can't think of anything that would cause this.
Aside from that, the memory could climb (but not leak) for a few reasons I can think of:
Though these same things would be happening on linux if any of them were the case. I'll try to experiment with an apple machine.
ok, nevermind, I think that was some glitch on my side. The growth is there but it is rather negligable. The leak sanitzer doesn't complain at least. Closing.
Oh, you beat me to it.
Actually I don't think that the fuzzed api calls are giant or anything. The value buffers are limited to 1024 and there is rather limited sequence of calls (I would guess that it's less than 100). After each round a new temporary prefix is generated. Moreover, during one round there might be a full flush - i.e. close the db and reopen it.
Assuming that those caches do not live in some thread locals or globals I think it shouldn't affect the RSS anyhow.
During fuzzing I am observing a steady climb of rss up to eventual OOM kill.
The leak looks like this