fix(bufferedread): avoid nil pointer panic in callback after reader destruction

[vipnydav]

Description

This PR addresses a nil pointer dereference that occurs within the callback function of the BufferedReader when a read request stalls significantly. The issue is triggered when the Destroy method reaches its 10-second timeout waiting for outstanding data references and proceeds to nullify the blockPool as part of its cleanup process. If the stalled request's callback finally executes after the reader has been destroyed, it attempts to release memory blocks to the now-nil pool, leading to a crash. This fix introduces a nil check in the callback to prevent the panic.

By allowing the reader to finish destruction even if some callbacks are still pending, we introduce a potential memory leak because those specific blocks will never be returned to the pool for reuse. However, this is considered a reasonable and necessary tradeoff because the scenario of a read request stalling for more than 10 seconds is highly unexpected and extremely rare in production. Accepting a minor memory leak in such an exceptional case is much safer than allowing the entire application to panic or hang indefinitely.

Link to the issue in case of a bug fix.

b/481243124

Testing details

1. Manual - Verified manually that the panic no longer occurs when the destruction timeout is hit.
2. Unit tests - NA
3. Integration tests - NA

Any backward incompatible change? If so, please explain.

[gemini-code-assist]

Summary of Changes

Hello @vipnydav, I'm Gemini Code Assist¹! 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 nil pointer panic in the BufferedReader's callback mechanism that could occur during the reader's destruction phase. By implementing a defensive nil check and carefully managing resource cleanup, the change significantly enhances the stability of the application, prioritizing robustness over a highly improbable and minor memory leak.

Highlights

• Nil Pointer Dereference Fix: Introduced a nil check for p.blockPool within the callback function of BufferedReader to prevent a nil pointer dereference panic. This occurs when the Destroy method times out and nullifies blockPool before a stalled read request's callback executes.
• Trade-off for Stability: Accepted a potential minor memory leak in extremely rare scenarios where Destroy times out. This is considered a reasonable trade-off to prevent application panics, as the blocks involved would not be returned to the pool.
• Improved Thread Safety: The assignment p.blockPool = nil in the Destroy method is now protected by a mutex, ensuring thread safety during the cleanup process.
• Documentation Update: Added a detailed comment in the Destroy method explaining the rationale behind the 10-second timeout and the acceptable memory leak trade-off.

Changelog

• internal/bufferedread/buffered_reader.go
  • Added a nil check for p.blockPool before calling Release in the callback method to prevent panics.
  • Included a new comment in the Destroy method to clarify the implications of the 10-second timeout, specifically regarding the acceptable memory leak.
  • Wrapped the p.blockPool = nil assignment with p.mu.Lock() and p.mu.Unlock() in the Destroy method to ensure atomic operation and prevent race conditions.

Activity

• The author manually verified that the panic no longer occurs when the destruction timeout is hit.

Using Gemini Code Assist

The 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 /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

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 .gemini/ folder in the base of the repository. Detailed instructions can be found here.

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

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request effectively addresses a potential nil pointer panic in the BufferedReader's callback function that could occur if the reader is destroyed during a stalled read. The solution, which involves adding a nil check in the callback and introducing a mutex lock in the Destroy method to prevent a race condition, is sound. I have one suggestion to improve the robustness of the Destroy method by making it idempotent, which will prevent a panic if it is called multiple times. Overall, this is a solid fix for a tricky concurrency problem.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 83.68%. Comparing base (3abde81) to head (90ab22a).
⚠️ Report is 1 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #4340      +/-   ##
==========================================
- Coverage   83.68%   83.68%   -0.01%     
==========================================
  Files         161      161              
  Lines       19472    19475       +3     
==========================================
+ Hits        16296    16297       +1     
- Misses       2576     2577       +1     
- Partials      600      601       +1     

Flag	Coverage Δ
unittests	83.68% <100.00%> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[github-actions]

Hi @abhishek10004, @raj-prince, your feedback is needed to move this pull request forward. This automated reminder was triggered because there has been no activity for over 24 hours. Please provide your input when you have a moment. Thank you!

[github-actions]

Hi @abhishek10004, @raj-prince, your feedback is needed to move this pull request forward. This automated reminder was triggered because there has been no activity for over 24 hours. Please provide your input when you have a moment. Thank you!