[Bug] BE UT coredump: Bad cast from IdentityWrapperExpr* to VSlotRef* due to uninitialized _node_type

[heguanhui]

Search before asking

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

Version

master (trunk)

What's Wrong?

BE unit test RuntimeFilterPartitionPrunerTest.ProjectedBoundariesPreserveOpenRangeBounds coredumps with:

F20260607 15:48:06.595517 53695 status.h:472] Bad cast from type:doris::IdentityWrapperExpr* to doris::VSlotRef*
*** Check failure stack trace: ***
    @     0x560338957138  doris::Status::FatalError<>()
    @     0x56033a2b421e  assert_cast<>()
    @     0x56033f7942ab  doris::ParsedPartitionBoundaries::get_or_compute_projected_boundaries()
    @     0x56033a19cd1d  doris::RuntimeFilterPartitionPrunerTest_ProjectedBoundariesPreserveOpenRangeBounds_Test::TestBody()

What You Expected?

UT should pass without coredump.

How to Reproduce?

1. Build BE with -DCMAKE_BUILD_TYPE=DEBUG on x86
2. Run bash run-be-ut.sh
3. Observe coredump at RuntimeFilterPartitionPrunerTest.ProjectedBoundariesPreserveOpenRangeBounds

Root Cause

VExpr::VExpr(DataTypePtr, bool) constructor does not initialize _node_type member variable when is_slotref=false:

VExpr::VExpr(DataTypePtr type, bool is_slotref)
        : _opcode(TExprOpcode::INVALID_OPCODE),
          _data_type(get_data_type_with_default_argument(type)) {
    if (is_slotref) {
        _node_type = TExprNodeType::SLOT_REF;
    }
    // is_slotref=false: _node_type is UNINITIALIZED!
}

_node_type has no in-class default initializer (vexpr.h:429):

TExprNodeType::type _node_type;  // no default value

When is_slotref=false, _node_type contains an uninitialized stack residual value. If this residual value happens to equal TExprNodeType::SLOT_REF, is_slot_ref() incorrectly returns true, causing assert_cast<VSlotRef*> to fail.

This is undefined behavior (UB) and is non-deterministic across build types, compiler versions, and call paths. It is more likely to manifest under DEBUG (-O0) due to raw stack layout.

Fix

Initialize _node_type in the constructor initializer list:

VExpr::VExpr(DataTypePtr type, bool is_slotref)
        : _node_type(is_slotref ? TExprNodeType::SLOT_REF : TExprNodeType::INVALID_OPCODE),
          _opcode(TExprOpcode::INVALID_OPCODE),
          _data_type(get_data_type_with_default_argument(type)) {}

Are you willing to submit PR?

• Yes I am willing to submit a PR!

[zclllyybb]

Breakwater-GitHub-Analysis-Slot: slot_b8bdf6bb8446

I rechecked the current upstream origin/master code, and this looks like a real BE bug rather than only a test artifact.

Evidence:

• VExpr::VExpr(DataTypePtr, bool) initializes _opcode and _data_type, but only assigns _node_type when is_slotref is true.
• _node_type has no in-class default initializer, while is_slot_ref() directly checks _node_type == TExprNodeType::SLOT_REF.
• The false branch is reachable in current code: for example VirtualSlotRef(const SlotDescriptor*) calls VExpr(desc->type(), false), and several BE tests also construct non-slot expressions through this constructor.

So the reported crash chain is consistent: a non-VSlotRef expression can be misclassified as a slot ref if the uninitialized value happens to equal SLOT_REF, and a later assert_cast<VSlotRef*> then fails.

There is already an in-flight fix PR, #64180. One review caveat: the current patch uses TExprNodeType::INVALID_OPCODE as the fallback node type, but current gensrc/thrift/Exprs.thrift does not define that enum value. INVALID_OPCODE belongs to TExprOpcode, not TExprNodeType, so that part likely needs adjustment before the patch can compile.

Suggested next step:

• Initialize _node_type on all constructor paths using a valid TExprNodeType value, or refactor this constructor to receive the actual expression node type instead of only a boolean.
• For descriptor-backed VirtualSlotRef, preserving TExprNodeType::VIRTUAL_SLOT_REF would be more semantically precise than using an arbitrary non-slot placeholder.
• Keep/add a regression test that constructs a non-slot VExpr(type, false) and verifies it is not treated as a slot ref.

No extra runtime logs are needed to confirm the root cause. The only useful missing context is the exact source branch or PR containing RuntimeFilterPartitionPrunerTest.ProjectedBoundariesPreserveOpenRangeBounds, since that test symbol is not present in the current fetched origin/master tree.