histogram() aborts every BE: serialize_to_column CHECK-fails in the partial aggregation stage

Steps to reproduce the behavior (Required)

docker run -p 9030:9030 -p 8030:8030 -p 8040:8040 --name sr-repro \
  -itd starrocks/allin1-ubuntu:4.1.1

1. CREATE TABLE:

CREATE DATABASE sr_histogram_repro;
USE sr_histogram_repro;

CREATE TABLE t (id BIGINT NOT NULL, v INT NULL) ENGINE=OLAP DUPLICATE KEY(id)
DISTRIBUTED BY HASH(id) BUCKETS 4 PROPERTIES ("replication_num" = "1");

2. INSERT INTO:

INSERT INTO t VALUES (1,1),(2,1),(3,2),(4,2),(5,3),(6,3),(7,4),(8,4),(9,5),(10,5);

3. SELECT:

SELECT histogram(v, cast(64 as int), cast(1.0 as double)) FROM t;

Expected behavior (Required)

A histogram string, or a clear error if the aggregate is not intended to be called directly from SQL.

Real behavior (Required)

Every BE running a fragment aborts simultaneously. The client sees a message that names a missing backend rather than the statement that caused it:

ERROR 1064 (HY000): Backend node not found. Check if any backend node is down.
backend: [127.0.0.1 alive: true inBlacklist: true]

be.out shows repeated histogram.h:137] Check failed: false across every worker thread, then:

*** SIGABRT (@0x7bf9) received by PID 31737 ... stack trace: ***
    @  0xe389ef8  starrocks::failure_function()
    @  0xbba191c  starrocks::HistogramAggregationFunction<(starrocks::LogicalType)5, int>
                  ::serialize_to_column(starrocks::FunctionContext*, unsigned char const*,
                  starrocks::Column*) const
    @  0xcf43b54  starrocks::Aggregator::_serialize_to_chunk(...)
    @  0xcfecd4c  starrocks::Aggregator::convert_to_chunk_no_groupby(...)
    @  0xe2f3bd4  starrocks::pipeline::AggregateBlockingSourceOperator::pull_chunk(...)

The BE restarts on its own after roughly 10 seconds.

Cause. HistogramAggregationFunction::serialize_to_column is unimplemented and CHECK-fails unconditionally. A bare SELECT is planned as a two-stage aggregation, so the partial stage reaches it:

1:AGGREGATE (update serialize)   <- calls serialize_to_column -> SIGABRT
2:EXCHANGE
3:AGGREGATE (merge finalize)

The crash seems to be plan-shaped, not data-dependent.

Both of these run clean on the same table, with zero growth in be.out:

USE sr_histogram_repro;

-- 1. The internal statistics path. Builds the aggregate in a single stage,
--    so serialize_to_column is never reached.
ANALYZE TABLE t UPDATE HISTOGRAM ON v;
-- -> status OK

-- 2. The identical crashing query, forced to a single-stage aggregation.
SET new_planner_agg_stage = 1;
SELECT histogram(v, cast(64 as int), cast(1.0 as double)) FROM t;
-- -> [["2","2","1","1"],["3","3","2","1"], ...]  (bucket layout varies between runs)

The only difference between crashing and working is the aggregation stage count.

StarRocks version (Required)

4.1.1-14b7e3f

Reproduced on starrocks/allin1-ubuntu:4.1.1 (aarch64) from a clean container. Also hit on a production cluster running the same release.