3.3版本 be core dump,可复现

为了更快的定位您的问题,请提供以下信息,谢谢
【详述】问题详细描述
【背景】做过哪些操作?
【业务影响】
【是否存算分离】存算一体
【StarRocks版本】3.3

*** Aborted at 1750852297 (unix time) try “date -d @1750852297” if you are using GNU date ***
PC: @ 0xc96831b unsigned long starrocks::unaligned_load(void const*)
*** SIGSEGV (@0x7fa7625ff000) received by PID 231117 (TID 0x7fa6dbdf0700) from PID 1650454528; stack trace: ***
@ 0x7fa78385f20b __pthread_once_slow
@ 0x1573d9e0 google::(anonymous namespace)::FailureSignalHandler(int, siginfo_t*, void*)
@ 0x7fa783868630 (/usr/lib64/libpthread-2.17.so+0xf62f)
@ 0xc96831b unsigned long starrocks::unaligned_load(void const*)
@ 0xc965fcc starrocks::crc_hash_64(void const*, int, unsigned long)
@ 0xda1c40e starrocks::SliceHash::operator()(starrocks::Slice const&) const
@ 0xe729373 starrocks::SliceWithHash::SliceWithHash(starrocks::Slice const&)
@ 0xf7c9442 starrocks::DistinctAggregateState<(starrocks::LogicalType)13, (starrocks::LogicalType)13, int>::deserialize_and_merge(starrocks::MemPool*, unsigned char const*, unsigned long)
@ 0xf7a1970 starrocks::TDistinctAggregateFunction<(starrocks::LogicalType)13, (starrocks::LogicalType)13, starrocks::DistinctAggregateStateV2, (starrocks::AggDistinctType)0, starrocks::Slice>::merge(starrocks::FunctionContext*, starrocks::Column const*, unsigned char*^XŦk
@ 0xf5f6dea starrocks::NullableAggregateFunctionUnary<std::shared_ptrstarrocks::AggregateFunction, starrocks::NullableAggregateFunctionState<starrocks::DistinctAggregateStateV2<(starrocks::LogicalType)13, (starrocks::LogicalType)13, int>, false>, false, true, starro^XŦk
@ 0xf5f6fad auto starrocks::ColumnHelper::call_nullable_func<starrocks::NullableAggregateFunctionUnary<std::shared_ptrstarrocks::AggregateFunction, starrocks::NullableAggregateFunctionState<starrocks::DistinctAggregateStateV2<(starrocks::LogicalType)13, (starrocks::^XŦk
@ 0xf5f7095 starrocks::NullableAggregateFunctionUnary<std::shared_ptrstarrocks::AggregateFunction, starrocks::NullableAggregateFunctionState<starrocks::DistinctAggregateStateV2<(starrocks::LogicalType)13, (starrocks::LogicalType)13, int>, false>, false, true, starro^XŦk
@ 0xe1c91ae starrocks::Aggregator::compute_single_agg_state(starrocks::Chunk*, unsigned long)
@ 0xdf861a8 starrocks::pipeline::AggregateBlockingSinkOperator::push_chunk(starrocks::RuntimeState*, std::shared_ptrstarrocks::Chunk const&)
@ 0xdf3f6ec starrocks::pipeline::PipelineDriver::process(starrocks::RuntimeState*, int)
@ 0xe5efe87 starrocks::pipeline::GlobalDriverExecutor::_worker_thread()
@ 0xe5ef5ab starrocks::pipeline::GlobalDriverExecutor::initialize(int)::{lambda()#1}::operator()() const

建表
CREATE TABLE test_tbl (
date_time datetime NULL COMMENT “”,
track_type varchar(128) NULL COMMENT “”,
user_key varchar(64) NULL COMMENT “”,
department varchar(128) NULL COMMENT “”,
group_name varchar(128) NULL COMMENT “”
) ENGINE=OLAP
DUPLICATE KEY(date_time, track_type, user_key)
DISTRIBUTED BY HASH(user_key) BUCKETS 4
PROPERTIES (
“compression” = “LZ4”,
“fast_schema_evolution” = “true”,
“replicated_storage” = “true”,
“replication_num” = “1”
);

插入数据
INSERT INTO test_tbl
(date_time, track_type, user_key, department, group_name)
VALUES
(‘2025-06-16 11:00:00’, ‘B’, ‘user2’, ‘部门A’, ‘组1’),
(‘2025-06-16 15:00:00’, ‘A’, NULL, ‘部门A’, ‘组2’),
(‘2025-06-16 10:00:00’, ‘A’, ‘user1’, ‘部门A’, ‘组2’),
(‘2025-06-16 12:00:00’, ‘-’, ‘user3’, ‘部门A’, ‘组3’),
(‘2025-06-16 14:00:00’, NULL, ‘user5’, ‘部门A’, ‘组4’),
(‘2025-06-16 13:00:00’, ‘C’, ‘user4’, ‘部门B’, ‘组5’);

SELECT
multi_distinct_count(track_type) AS distinct_count_track_type,
multi_distinct_count(user_key) AS distinct_count_user_key,
count(DISTINCT CASE
WHEN (department = ‘部门A’ AND group_name <> ‘组1’) THEN user_key
ELSE NULL
END) AS t1
FROM test_tbl
WHERE date_time BETWEEN ‘2025-06-16 00:00:00’ AND ‘2025-06-16 23:59:59’
AND track_type NOT IN (’-’)
ORDER BY distinct_count_track_type DESC
LIMIT 1000;

有时候第一次查询无法复现,第二次查询稳定复现
@trueeyu

看起来是这个优化有问题,可以设置
set global low_cardinality_optimize_v2=false;

我report下

把multi_distinct_count换成COUNT(DISTINCT expr)没问题,也能临时规避

set global low_cardinality_optimize_v2=false;
大佬,设置这个对整体性能影响大么

影响应该还好,因为有v1 还可以兜底

closed by https://github.com/StarRocks/starrocks/pull/60664/files

打了这个patch之后,在3.4.4版本,还是会有crash情况

*** Aborted at 1752544906 (unix time) try “date -d @1752544906” if you are using GNU date ***
PC: @ 0x82452a8 starrocks::AdaptiveSliceHashSet::emplace(starrocks::MemPool*, starrocks::Slice)
*** SIGSEGV (@0xfff344da0000) received by PID 30 (TID 0xfffe9b0e00c0) from PID 1155137536; stack trace: ***
@ 0xffff8de625c4 (/usr/lib/aarch64-linux-gnu/libc.so.6+0x825c3)
@ 0xe33ce58 google::(anonymous namespace)::FailureSignalHandler(int, siginfo_t*, void*)
@ 0xffff8f2b2850 ([vdso]+0x84f)
@ 0x82452a8 starrocks::AdaptiveSliceHashSet::emplace(starrocks::MemPool*, starrocks::Slice)
@ 0x88b4a14 starrocks::TDistinctAggregateFunction<(starrocks::LogicalType)13, (starrocks::LogicalType)13, starrocks::DistinctAggregateStateV2, (starrocks::AggDistinctType)0, starrocks::Slice>::merge(starrocks::FunctionContext*, starrocks::Column const*, unsigned char*
@ 0x882a970 starrocks::NullableAggregateFunctionUnary<std::shared_ptrstarrocks::AggregateFunction, starrocks::NullableAggregateFunctionState<starrocks::DistinctAggregateStateV2<(starrocks::LogicalType)13, (starrocks::LogicalType)13, int>, false>, false, true, starro
@ 0x9e79868 starrocks::Aggregator::compute_batch_agg_states(starrocks::Chunk*, unsigned long)
@ 0x9fe08cc starrocks::pipeline::AggregateBlockingSinkOperator::push_chunk(starrocks::RuntimeState*, std::shared_ptrstarrocks::Chunk const&)
@ 0x780d020 starrocks::pipeline::PipelineDriver::process(starrocks::RuntimeState*, int)
@ 0xa727de0 starrocks::pipeline::GlobalDriverExecutor::_worker_thread()
@ 0xab4b934 starrocks::ThreadPool::dispatch_thread()
@ 0xab42c1c starrocks::thread::supervise_thread(void*)
@ 0xffff8de5d5b8 (/usr/lib/aarch64-linux-gnu/libc.so.6+0x7d5b7)
@ 0xffff8dec5edc (/usr/lib/aarch64-linux-gnu/libc.so.6+0xe5edb)

打了patch之后,crash sql还是上面的那个?

另外一个sql哈,数据量大的时候会crash,还没办法简单复现出来

@许秀不许秀 大佬这个 crash异常有空看一下么