[DONOTMERGE] Fix crash in monitor_GR_thread_HG due to stale DEBUG connection tracking (issue #5256)#5362
[DONOTMERGE] Fix crash in monitor_GR_thread_HG due to stale DEBUG connection tracking (issue #5256)#5362renecannao wants to merge 1 commit intov3.0from
Conversation
…ing (issue #5256) PROBLEM: -------- When a stale connection was detected in get_connection(), it was queued for closure via MON_CLOSE_CONNECTION work item. However, the connection was never removed from the DEBUG 'conns' array. This caused a race condition: 1. Connection X retrieved from pool, added to DEBUG 'conns' array 2. Connection X returned to pool, removed from DEBUG 'conns' array 3. Connection X retrieved again, added to DEBUG 'conns' array again 4. Connection X found stale, queued for closure 5. Connection X closed (via destructor) but STILL in DEBUG 'conns' array 6. create_new_connection() returns MYSQL* with same address as X 7. conn_register() finds this pointer in 'conns' and asserts: assert(my!=my1) ROOT CAUSE: ----------- The stale connection was added to 'conns' when retrieved from the pool, but was never removed from 'conns' when found stale and queued for closure. FIX: ---- Before queuing a stale connection for closure, remove it from the DEBUG 'conns' array. This ensures the connection pointer is properly unregistered before being closed and potentially reused by malloc. This fix only affects DEBUG builds as the 'conns' array is DEBUG-only.
Summary of ChangesHello @renecannao, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request addresses a critical crash occurring in DEBUG builds of the MySQL monitor, specifically within the Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
📝 WalkthroughWalkthroughA DEBUG-only safeguard added to MySQL_Monitor.cpp removes stale MySQL connection pointers from the global DEBUG registry before queuing them for asynchronous closure, preventing duplicate registration attempts that triggered an assertion failure. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Suggested labels
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
There was a problem hiding this comment.
Code Review
This pull request addresses a crash in DEBUG builds caused by a race condition in stale connection tracking. The problem occurs when a stale connection is closed but its pointer is not removed from the debug tracking array, leading to a potential assertion failure if the memory address is reused. The proposed fix correctly removes the stale connection from the debug array before it's queued for closure, which effectively resolves the issue. The change is appropriately isolated within an #ifdef DEBUG block in MySQL_Monitor_Connection_Pool::get_connection(). The code is clear, and the detailed comments explaining the bug and the fix are excellent for maintainability. The implementation is sound, and I have no further recommendations.



Please review all changes carefully before merging. The AI agent has performed analysis and implemented a fix based on code review, but human verification is essential.
Summary
Fixes #5256 - Crash in
monitor_GR_thread_HGwith assertion failure:Problem Description
When a stale connection was detected in
get_connection(), it was queued for closure via aMON_CLOSE_CONNECTIONwork item. However, the connection was never removed from the DEBUGconnstracking array. This caused a race condition that could lead to a crash:Crash Scenario:
connsarrayconnsarrayconnsarray againMON_CLOSE_CONNECTIONconnsarray!create_new_connection()returns MYSQL* with same address (malloc reuse)conn_register()finds this pointer inconns→ assertion failsWhy It's Hard to Reproduce:
connsarray only exists in DEBUG builds)mallocto reuse the exact same pointer address)Root Cause
The stale connection was added to
connswhen retrieved from the pool, but was never removed fromconnswhen found stale and queued for closure.Solution
Before queuing a stale connection for closure, remove it from the DEBUG
connsarray. This ensures the connection pointer is properly unregistered before being closed and potentially reused by malloc.Code Changes
File:
lib/MySQL_Monitor.cppFunction:
MySQL_Monitor_Connection_Pool::get_connection()Added DEBUG-only code to remove stale connections from the tracking array before queuing for closure.
Testing
Additional Notes
#ifdef DEBUGsince theconnsarray is DEBUG-onlypurge_some_connections()because those connections are from the idle pool (already removed fromconnswhen returned)Reviewed by: @sysown (please review)
Summary by CodeRabbit