[branch-4.0][fix](be) Init thread context on AsyncIO worker threads#65271
Conversation
`FILESYSTEM_M` dispatches IO ops from a bthread to an `AsyncIO` worker pthread that is **not bound to any task** and therefore has no `ThreadContext`. When the dispatched `fn()` reads a local file, it goes through `LocalFileReader::read_at_impl` -> `LIMIT_LOCAL_SCAN_IO` -> `thread_context()`, which raises `Status::FatalError` (aborting the BE in debug/ASAN builds) when no `ThreadContext` exists. Observed as a Cloud P0 coredump on the load error-log S3 upload path: ``` RuntimeState::get_error_log_file_path() -> _s3_error_fs->upload() (called from a bthread) -> AsyncIO::run_task() on an AsyncIO worker pthread (no attached task) -> S3FileSystem::upload_impl() -> LocalFileReader::read_at_impl() -> LIMIT_LOCAL_SCAN_IO -> thread_context() -> FatalError -> SIGABRT ``` Initialize an (unattached) `ThreadContext` at the `AsyncIO` worker boundary via `SCOPED_INIT_THREAD_CONTEXT()`, the same pattern used by StorageEngine background threads. This gives every `thread_context()` consumer running on an AsyncIO worker (memory tracking, `LIMIT_*_SCAN_IO`, ...) a valid context, fixing the crash at its root rather than making individual consumers tolerate a missing context.
|
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
There was a problem hiding this comment.
Pull request overview
This PR backports #64846 to ensure AsyncIO’s pthread-based worker threads have a valid ThreadContext before running dispatched filesystem work, preventing fatal failures when worker-side code touches thread_context() (e.g., memory tracking / IO limiting helpers).
Changes:
- Add
runtime/thread_context.hinclude to AsyncIO header. - Initialize an (unattached)
ThreadContextinside AsyncIO thread-pool task execution viaSCOPED_INIT_THREAD_CONTEXT().
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
run buildall |
BE UT Coverage ReportIncrement line coverage Increment coverage report
|
|
PR approved by at least one committer and no changes requested. |
|
PR approved by anyone and no changes requested. |
BE Regression && UT Coverage ReportIncrement line coverage Increment coverage report
|
Pick #64846