zclllyybb commented on issue #65773:
URL: https://github.com/apache/doris/issues/65773#issuecomment-5002595705
Breakwater-GitHub-Analysis-Slot: slot_a2c29ec04503
This content is generated by AI for reference only.
Follow-up after the additional log comment:
The newly added JDBC logs change the trigger picture, but not the BE crash
mechanism from the stack.
What the new logs add:
- The Microsoft SQL Server JDBC driver reported repeated TDS parsing
failures between `2026-07-17 10:24:08 UTC` and `2026-07-17 10:24:28 UTC`.
- The BE abort timestamp is `2026-07-17 10:24:49 UTC`, so those JDBC errors
happened immediately before the crash.
- In the Doris 4.0.7 code path, `JdbcScanner::_open_impl()` /
`_get_block_impl()` call `JdbcConnector::query()` / `get_next()`, and JNI/JDBC
exceptions are supposed to be returned as `Status` errors. Such a JDBC-side
failure should fail/cancel the query, not crash the BE process.
Updated interpretation:
- There are likely two related issues in this incident:
1. The query first hit a SQL Server JDBC/TDS protocol/driver-side error
while reading from the external catalog.
2. The BE process then crashed in the async writer cleanup/teardown path
because `AsyncResultWriter::start_writer()` checks the weak task context only
after `SCOPED_ATTACH_TASK(state)` has already dereferenced `RuntimeState`.
- The added signal line `Query id: 0-0` also fits this: the async writer
thread had not successfully attached a task id before the signal. The `is
nereids: 1` line alone should not be overinterpreted, because that thread-local
flag is not reset in `AttachTask::~AttachTask()` in this branch and may be
stale from a reused thread-pool thread.
For the BE crash, I still recommend fixing the async writer lifetime
ordering first:
- Lock the task execution context at the very beginning of the submitted
callback.
- Do not touch `state`, `operator_profile`, or `this` before that lock
succeeds.
- Keep the strong task context lock alive through `process_block()`.
- Make the early-return path also settle writer status / finish dependency
if any still-live close path can wait on it.
For the preceding SQL Server/JDBC trigger, the next useful evidence is:
- The exact SQL shape and whether the plan uses plain JDBC scan, `INSERT
INTO ... SELECT`, CTAS, OUTFILE/file result, or another async writer sink.
- The JDBC catalog properties with secrets removed: `driver_url`,
`driver_class`, SQL Server JDBC driver jar/version, JDBC URL options such as
`encrypt` / `trustServerCertificate`, and whether
`force_sqlserver_jdbc_encrypt_false` is enabled.
- SQL Server version/edition and whether this is Azure SQL or a
proxy/gateway endpoint.
- The query profile or FE audit/query id that maps the JDBC exceptions to
the crashing BE fragment.
If the TDS errors disappear after changing the SQL Server JDBC driver or
connection options, that would explain the trigger, but the BE should still not
crash on that error path; the async writer lifetime fix is still needed.
--
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]
