[Bug](Highest) Be core happened while SELECT __DORIS_STREAM_CHANGE_TYPE_COL__

[MoanasDaddyXu]

Search before asking

• I had searched in the issues and found no similar issues.

Version

49af192

What's Wrong?

sql is SELECT __DORIS_STREAM_CHANGE_TYPE_COL__, l_orderkey, l_quantity, l_comment FROM s_debug_update_type WHERE l_orderkey = 80001

thrift error, reason=No more data to read.*** Query id: 4b19b44376794ab9-8b3f9f5ec27b1393 ***
*** tablet id: 0 ***
*** Aborted at 1783424797 (unix time) try "date -d @1783424797" if you are using GNU date ***
*** Current BE git commitID: 49af19213e7 ***
*** SIGSEGV invalid permissions for mapped object (@0x7feb93d15000) received by PID 21462 (TID 21938 OR 0x7fe9949d3640) from PID 184467440718945525
76; stack trace: ***
 0# doris::signal::(anonymous namespace)::FailureSignalHandler(int, siginfo_t*, void*) at ../src/common/signal_handler.h:417
 1# PosixSignals::chained_handler(int, siginfo*, void*) [clone .part.0] in /usr/lib/jvm/java-17-openjdk-amd64/lib/server/libjvm.so
 2# JVM_handle_linux_signal in /usr/lib/jvm/java-17-openjdk-amd64/lib/server/libjvm.so
 3# 0x00007FEBFBABA520 in /lib/x86_64-linux-gnu/libc.so.6
 4# memcpy at ./be/build_RELEASE/../src/glibc-compatibility/memcpy/memcpy_x86_64.cpp:219
 5# doris::ColumnStr<unsigned int>::insert_from(doris::IColumn const&, unsigned long) at ../src/core/column/column_string.h:187
 6# doris::BlockReader::_min_delta_next_block(doris::Block*, bool*) in /mnt/hdd01/PERFORMANCE_ENV/be/lib/doris_be
 7# doris::BlockReader::next_block_with_aggregation(doris::Block*, bool*) at ./be/build_RELEASE/../src/storage/iterator/block_reader.cpp:72
 8# doris::OlapScanner::_get_block_impl(doris::RuntimeState*, doris::Block*, bool*) at ./be/build_RELEASE/../src/exec/scan/olap_scanner.cpp:817
 9# doris::Scanner::get_block(doris::RuntimeState*, doris::Block*, bool*) in /mnt/hdd01/PERFORMANCE_ENV/be/lib/doris_be
10# doris::Scanner::get_block_after_projects(doris::RuntimeState*, doris::Block*, bool*) at ./be/build_RELEASE/../src/exec/scan/scanner.cpp:95
11# doris::ScannerScheduler::_scanner_scan(std::shared_ptr<doris::ScannerContext>, std::shared_ptr<doris::ScanTask>) in /mnt/hdd01/PERFORMANCE_ENV/be/lib/doris_be
12# std::_Function_handler<bool (), doris::ScannerScheduler::submit(std::shared_ptr<doris::ScannerContext>, std::shared_ptr<doris::ScanTask>)::$_0::operator()() const::{lambda()#1}>::_M_invoke(std::_Any_data const&) at /usr/local/ldb-toolchain-v0.26/bin/../lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15/bits/std_function.h:292
13# doris::ScannerSplitRunner::process_for(std::chrono::duration<long, std::ratio<1l, 1000000000l> >) at ./be/build_RELEASE/../src/exec/scan/scanner_scheduler.cpp:384
14# doris::PrioritizedSplitRunner::process() in /mnt/hdd01/PERFORMANCE_ENV/be/lib/doris_be
15# doris::TimeSharingTaskExecutor::_dispatch_thread() at ./be/build_RELEASE/../src/exec/scan/task_executor/time_sharing/time_sharing_task_executor.cpp:574
16# doris::Thread::supervise_thread(void*) at ./be/build_RELEASE/../src/util/thread.cpp:461
17# start_thread at ./nptl/pthread_create.c:442
18# 0x00007FEBFBB9E8D0 at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:83

What You Expected?

SELECT Command will success

How to Reproduce?

No response

Anything Else?

No response

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[zclllyybb]

Breakwater-GitHub-Analysis-Slot: slot_6fe5c9fb8393
This content is generated by AI for reference only.

Initial assessment:

This should be treated as a real BE crash in the row-binlog/table-stream MIN_DELTA read path at commit 49af19213e7, not as expected SQL behavior. The stack stops in ColumnStr<unsigned int>::insert_from() while BlockReader::_min_delta_next_block() is materializing rows for a stream scan.

The most suspicious code-level mechanism is a source/target nullability mismatch for BEFORE image columns. FE generates row-binlog BEFORE value columns as nullable (Column.generateBeforeValueColumn() sets isAllowNull=true). In BE, the MIN_DELTA UPDATE_BEFORE branch resolves a selected value column to its __BEFORE__... source column and then directly calls target_columns[target_col_idx]->insert_from(*_stored_data_columns[source_idx], 0). If the selected base column is a non-null STRING/VARCHAR column such as l_comment, the target column is ColumnString, while the BEFORE source is ColumnNullable(ColumnString). ColumnStr::insert_from() then casts the source as ColumnStr and copies from invalid string offsets/chars, which is consistent with the reported SIGSEGV in memcpy.

This is also worth checking in the DETAIL path because _append_change_row() uses the same direct insert_from() pattern when it emits UPDATE_BEFORE rows from BEFORE columns.

Missing information needed to confirm the exact trigger:

1. The DDL for s_debug_update_type, especially key type, binlog.enable, binlog.format, binlog.need_historical_value, and the nullability/type of l_comment and l_quantity.
2. The DML sequence for l_orderkey = 80001 before this query.
3. The full BE core backtrace with line numbers, plus be.INFO around query id 4b19b44376794ab9-8b3f9f5ec27b1393.
4. The EXPLAIN/EXPLAIN VERBOSE plan for the query, to verify the scan type is MIN_DELTA and the physical scan includes __DORIS_BINLOG_OP__ plus widened BEFORE columns.
5. Whether the crash disappears if l_comment is not selected, or if l_comment is defined nullable. That would directly validate the nullable-BEFORE to non-null-string copy path.

Suggested next steps for maintainers:

1. Add a regression case for a MIN_DELTA table stream over a unique/MOW row-binlog table with binlog.need_historical_value=true, selecting a non-null VARCHAR value column after an UPDATE that emits UPDATE_BEFORE/UPDATE_AFTER.
2. Fix BE stream materialization to handle nullable BEFORE columns safely when the output column keeps the base column's non-null type. The implementation should not call ColumnString::insert_from() with a ColumnNullable source; it should either align output nullability or explicitly append from nullable sources with the correct null/nested-column handling.
3. Audit both BlockReader::_min_delta_next_block() and BlockReader::_append_change_row() for all direct insert_from() calls that can read from _resolve_source_column_index(..., true).