← 返回首页
Fix memory leaks in compress middleware by spaumx · Pull Request #2915 · labstack/echo · GitHub
Skip to content

Navigation Menu

Toggle navigation
Sign in
Appearance settings
Search or jump to...

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Include my email address so I can be contacted

Saved searches

Use saved searches to filter your results more quickly

Appearance settings
Resetting focus

Fix memory leaks in compress middleware#2915

Open
spaumx wants to merge 1 commit into
labstack:v5from
spaumx:fix/compress-memory-leaks
Open

Fix memory leaks in compress middleware#2915
spaumx wants to merge 1 commit into
labstack:v5from
spaumx:fix/compress-memory-leaks

Conversation

spaumx commented Mar 8, 2026

Copy link
Copy Markdown

This commit fixes several critical memory leaks in the gzip compression middleware that could lead to significant memory accumulation under specific usage patterns.

Changes:

  1. Fixed WebSocket/Hijack resource leak (compress.go:213-219)

    • Close gzip writer before hijacking connection
    • Prevents ~32KB leak per WebSocket connection
    • Critical for long-lived WebSocket connections
  2. Fixed Flush() buffer accumulation (compress.go:200-204)

    • Clear buffer after successful write during Flush()
    • Prevents unbounded memory growth in SSE scenarios
    • Important for Server-Sent Events and streaming responses
  3. Improved pool management (compress.go:138-149)

    • Check writer state before returning to pool
    • Prevent corrupted writers from being reused
    • Eliminates potential data corruption issues

Impact:

  • WebSocket connections: no longer leak gzip writers (~32KB each)
  • SSE/streaming: prevents linear buffer growth
  • Pool safety: eliminates race conditions from reused writers

Fixes potential memory leaks affecting:

  • WebSocket applications using compression middleware
  • Server-Sent Events endpoints
  • Long-lived streaming connections
  • High-concurrency scenarios

This commit fixes several critical memory leaks in the gzip compression middleware that could lead to significant memory accumulation under specific usage patterns. Changes: 1. Fixed WebSocket/Hijack resource leak (compress.go:213-219) - Close gzip writer before hijacking connection - Prevents ~32KB leak per WebSocket connection - Critical for long-lived WebSocket connections 2. Fixed Flush() buffer accumulation (compress.go:200-204) - Clear buffer after successful write during Flush() - Prevents unbounded memory growth in SSE scenarios - Important for Server-Sent Events and streaming responses 3. Improved pool management (compress.go:138-149) - Check writer state before returning to pool - Prevent corrupted writers from being reused - Eliminates potential data corruption issues Impact: - WebSocket connections: no longer leak gzip writers (~32KB each) - SSE/streaming: prevents linear buffer growth - Pool safety: eliminates race conditions from reused writers Fixes potential memory leaks affecting: - WebSocket applications using compression middleware - Server-Sent Events endpoints - Long-lived streaming connections - High-concurrency scenarios

aldas commented Mar 8, 2026

Copy link
Copy Markdown
Contributor

please provide proper description of the problem. it takes a little to much effort to understand the real-world situation, and you already have LLM created bullet list here so it should not be a problem.

p.s. tests/poc would be also helpful.

This comment was marked as spam.

This comment was marked as spam.

themavik left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide comment

Skipping pool.Put when gzip.Writer.Close errors avoids handing a broken writer back to the pool. Flush keeps the buffer when Write fails; nit: Hijack still ignores gw.Close() errors like the rest of this wrapper.

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants

Footer

© 2026 GitHub, Inc.