PR #65, in an attempt to reduce allocations, actually wrecks this module and makes the output insane in some cases, and introduces a humongous memory leak.
The problem is that the returned gin.HandlerFunc closes over l the logger variable. Therefore, requests stomp over each other, modifying the same context buffers inside the logger, as a nice data race for good measure, and overall resulting in the data from every request ever issued being captured, leaking memory and making a mess of the output.
The tests didn't notice this because they all use a ConsoleWriter, which obscures this duplication.
I think the fix is simple: create an event at that line instead of mutating the logger. Submitted #69 with a fix for this, and a test which demonstrates the issue.
PR #65, in an attempt to reduce allocations, actually wrecks this module and makes the output insane in some cases, and introduces a humongous memory leak.
The problem is that the returned
gin.HandlerFunccloses overlthe logger variable. Therefore, requests stomp over each other, modifying the same context buffers inside the logger, as a nice data race for good measure, and overall resulting in the data from every request ever issued being captured, leaking memory and making a mess of the output.https://github.com/gin-contrib/logger/blob/7cff53ef985497b0fa890e08235fffdcc1e900d0/logger.go#L107-L113
The tests didn't notice this because they all use a
ConsoleWriter, which obscures this duplication.I think the fix is simple: create an event at that line instead of mutating the logger. Submitted #69 with a fix for this, and a test which demonstrates the issue.