Doris-Breakwater commented on issue #69559: URL: https://github.com/apache/doris/issues/69559#issuecomment-6380276258
Breakwater-GitHub-Analysis-Slot: slot_4bd94acacfe9 ### Initial assessment The excerpt establishes a failed **internal column representation cast**: the actual object is `ColumnStr<unsigned int>` (the ordinary string column implementation), while a caller expects a `ColumnConst` wrapper. `terminate called after throwing ... doris::Exception` indicates that the exception reached termination. This warrants BE crash investigation, but the excerpt does **not** identify the caller or establish why BE cannot remain running. The Version field contains log excerpts, not a Doris version; `8924:`, `8925:`, etc. appear to be source-log line numbers. The issue currently has no labels, no reproduction steps, and no follow-up comments. Root cause and affected releases remain unconfirmed. ### Source findings and candidate paths I inspected local source without modifying the repository. For reference only, tag `4.0.8` resolves to `bc8ea1bac6d62d92cdebd2e3ac33cc668961ec36`; this is **not an identification of your installed version**. - In that reference, [`assert_cast.h`](https://github.com/apache/doris/blob/bc8ea1bac6d62d92cdebd2e3ac33cc668961ec36/be/src/vec/common/assert_cast.h#L36-L74) checks the physical C++ type and throws on mismatch, including the nested `assert cast err` text at lines 72–74 shown in this report. This is not, by itself, a SQL `CAST` error or evidence of damaged data files. - One concrete candidate is binary-predicate pushdown: [`OlapScanLocalState::_should_push_down_binary_predicate`](https://github.com/apache/doris/blob/bc8ea1bac6d62d92cdebd2e3ac33cc668961ec36/be/src/pipeline/exec/olap_scan_operator.cpp#L98-L118) calls `get_const_col()` for an expression classified as constant, then unconditionally casts its result to `ColumnConst`. However, [`VExpr::get_const_col()`](https://github.com/apache/doris/blob/bc8ea1bac6d62d92cdebd2e3ac33cc668961ec36/be/src/vec/exprs/vexpr.cpp#L743-L767) evaluates one row and caches the returned column without enforcing that wrapper. A one-row ordinary string result can therefore encounter this exact mismatch. The corresponding FileScan method has the same assumption. **This candidate applies only if the missing caller frames identify that path**; other callers also cast to `ColumnConst`. - Two public changes are relevant to investigate separately: [#63417](https://github.com/apache/doris/pull/63417), merged May 20, 2026, removes an incorrect `PURE` attribute from the throwing `assert_cast` function; it leaves the cast logic unchanged. [#66614](https://github.com/apache/doris/pull/66614) addresses inconsistent cached constant-column representations and updates the scan callers, but is still **open and unmerged** as of this review. Neither establishes a fix for this report without the installed commit and full stack. A specific upgrade recommendation would be premature. ### Information needed Please provide: 1. **Exact BE and FE versions/build commits**, including the BE `--version` output or startup version banner and `Current BE git commitID` from the crash. State whether this is a fresh installation, restart, upgrade, or downgrade, and the previous working version. 2. **One complete, unfiltered crash occurrence** from `be.out`, plus the matching `be.INFO`/`be.WARNING` interval from process launch through termination. Include roughly 100–200 preceding lines, every stack frame after `assert_cast`, timestamps, query ID, signal/abort section, and thread information. The pasted selection skips the frames needed to identify the caller; repeating only the matching error lines loses that evidence. Redact credentials and sensitive data. 3. **Startup timeline and reproduction steps:** exact launch command/service or container setup, relevant configuration changes, whether BE ever becomes alive in `SHOW BACKENDS`, and whether failure happens before readiness or only after queries/load/background tasks resume. Include the service/container restart log if it is looping. 4. If a query or load is identified: its SQL, relevant table DDL and session settings, a minimal reproduction, and `EXPLAIN VERBOSE` if obtainable on a healthy environment. If symbols remain unresolved, a symbolized backtrace from the matching executable/debug symbols is more useful than another truncated excerpt. ### Suggested next step First correlate a single crash with its build, full caller stack, and readiness timeline. If it enters scan predicate normalization, trace the producing constant expression and compare that exact branch with the changes above; reproduce before selecting a fix/backport. If it fails before accepting work, follow the actual initialization/recovery caller instead. Where operationally safe, a controlled restart with incoming workload paused can help distinguish these cases; it is a diagnostic step, not a confirmed workaround. No runtime reproduction was possible from the supplied information, and no Doris code was changed. -- 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]
