Repository navigation
veb: fix two memory leaks - #26236
Conversation
1. The veb web framework had a memory leak where response bodies were being cloned multiple times,
causing unbounded memory growth under load.
2. Additionally, when `veb_livereload` was enabled, the first clone was immediately overwritten
by `response.replace(...)`, leaking the first allocation.
New tests:
- `memory_leak_test.v` - Integration test that verifies large responses work correctly
- `memory_leak_test_server.v` - Test server with endpoints for heap monitoring and GC collection
|
picoev will be replaced by fasthttp. |
Oh I just saw the 0.5.0 realease 😃 |
|
Looks like these changes are specific to veb, not picoev or fasthttp (which would be lower-level protocol handlers). If this PR is approved, there's no reason not to merge it as-is. Yes, you did touch picoev, but just to remove commented out lines... no harm, no foul (and arguably should've been done long ago). |
No, this PR is not affected in any way, since we do not do backports to older versions - once they are done, they are immutable. The fix from this PR, will be merged in the |
|
@spytheman what do you think about the failing Docker CI? |
|
Interesting failure... it appears the memory leak that test is looking for is not there with musl libs. That means it's not a V failure, but a libc failure. Something to be explored... |
|
Add |
|
@JalonSolov without the gc, |
veb_livereloadwas enabled, the first clone was immediately overwritten byresponse.replace(...), leaking the first allocationNew tests:
memory_leak_test.v- Integration test that verifies large responses work correctlymemory_leak_test_server.v- Test server with endpoints for heap monitoring and GC collectionFixes #25423