zclllyybb commented on issue #65773: URL: https://github.com/apache/doris/issues/65773#issuecomment-5002567600
Breakwater-GitHub-Analysis-Slot: slot_a2c29ec04503 This content is generated by AI for reference only. Initial triage: I checked the reported tag `4.0.7-rc02` / commit `35854e7e92a`. This looks like a real lifetime bug in the async writer path, not enough evidence yet for an MS SQL Server JDBC connector-specific root cause. The crash frame is consistent with the current code order: 1. `AsyncResultWriter::start_writer()` captures raw `RuntimeState* state`, raw `RuntimeProfile* operator_profile`, and a weak task execution context. 2. In the submitted thread-pool callback, it runs `SCOPED_ATTACH_TASK(state)` first. 3. Only after that does it call `task_ctx.lock()` and return if the context has expired. 4. `SCOPED_ATTACH_TASK(state)` enters `AttachTask(RuntimeState*)`, which immediately calls `runtime_state->is_nereids()`. 5. `RuntimeState::is_nereids()` dereferences `_query_ctx`. So if the async writer callback starts after the fragment/task context has already begun teardown, the weak lifetime guard is checked too late. The reported SIGSEGV in `RuntimeState::is_nereids()` at address `@0x1f8` matches that failure mode. I also checked current upstream master: the file has moved to `be/src/exec/sink/writer/async_result_writer.cpp`, but the same callback order is still present there, so I do not see an already-merged public fix for this exact ordering. Impact/scope: - This affects the generic `AsyncWriterSink` / `AsyncResultWriter` path. JDBC table sink is one user of it, and file result, tablet, Hive, and Iceberg writers also use the same base pattern. - Because the crash happens before the concrete writer's `open()` / `write()` implementation appears in the stack, the available stack does not prove the MS SQL Server connector itself is faulty. - If this was a plain `SELECT` from a JDBC external catalog to the client, the exact SQL/profile is needed to identify which concrete sink was active, since the normal result sink path is different from the async writer sink path. Suggested next step for a fix: - In the async writer callback, lock the task execution context before any use of `state`, `operator_profile`, or `this`, especially before `SCOPED_ATTACH_TASK(state)`. - Keep the strong task context lock alive through `process_block()`. - If the lock fails, exit without touching the captured raw pointers, and make sure the writer status / finish dependency cannot leave the pipeline waiting in any still-live close path. - Add a focused regression/unit test or debug-only test where the async writer task is submitted but the task context expires before the queued callback starts; the callback should return without dereferencing `RuntimeState`. Missing information that would help confirm the trigger and choose the safest patch: - Full `be.INFO` / `be.out` around the crash timestamp, especially query id, fragment instance id, cancellation, timeout, and client disconnect logs. - The query profile or profile id for the failed query. - The exact SQL shape, sanitized if needed: plain SELECT, INSERT INTO JDBC table, CTAS, OUTFILE/export, or another sink. - Whether the query was cancelled, timed out, or the client disconnected around the crash time. - If available, the coredump backtrace with local variables for the async writer callback frame, especially the captured `state`, `task_ctx`, and task/fragment context state. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
