You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Libfuzzer uses LeakSanitizer but it has an interesting heuristic, it will do a LeakSanitizer check (very expensive) iff the test case has unbalanced malloc/free, i.e. it allocated something it did not freed.
This is not possible directly for Go (no free). But maybe it's possible to build something similar. Namely, run GC, capture MemStats, run a batch of tests, run GC, capture MemStats, if we see unbalanced malloc/free counts, try to bisect the batch and confirm leak in a single test (each repeated execution must increase the number of live objects).
The first would probably be to build a prototype outside of go-fuzz that would precisely pinpoint a logical leak.
The text was updated successfully, but these errors were encountered:
Could go-fuzz detect logical memory leaks (DoS)?
Libfuzzer uses LeakSanitizer but it has an interesting heuristic, it will do a LeakSanitizer check (very expensive) iff the test case has unbalanced malloc/free, i.e. it allocated something it did not freed.
This is not possible directly for Go (no free). But maybe it's possible to build something similar. Namely, run GC, capture MemStats, run a batch of tests, run GC, capture MemStats, if we see unbalanced malloc/free counts, try to bisect the batch and confirm leak in a single test (each repeated execution must increase the number of live objects).
The first would probably be to build a prototype outside of go-fuzz that would precisely pinpoint a logical leak.
The text was updated successfully, but these errors were encountered: