SIGSEGV in ha_mcs_impl_write_batch_row_ during INSERT SELECT; suspected stale columnTypes after cancellation

Problem

Two MariaDB Server SIGSEGV incidents were reported on September 8 and 9, 2026, during ColumnStore INSERT ... SELECT ... ORDER BY operations. These
queries had previously run successfully many times.

Both incidents reported the abbreviated frame:

  ha_mcs_impl_write_batch_row_(... cal_connection_info ...)+0x163

Observations

On September 8 at 17:36:08, writeenginesplit logged "Received signal to terminate the process". Two cpimport jobs reported zero rows and SUCCESS,
followed by engine-side bulk rollback. The child-process status does not establish overall SQL success.

Connection 6180152 subsequently executed TRUNCATE statements and retried an INSERT at 17:36:34. This is a related session timeline, not identification
of the crashing thread. Explicit SQL ROLLBACK is not established by the supplied excerpts.

On September 9, connection 888975 encountered earlier MCS2015 sort-memory errors, but also completed a successful INSERT after some of those errors.
Immediately before the reported crash, INSERT starts were logged at 12:06:58 and 12:07:16 without an intervening normal End SQL message in the
excerpt. cpimport started at 12:07:27; the crash was reported at 12:08:09.

Missing End SQL messages alone do not prove cancellation. The termination mechanism and whether both incidents followed the same cancellation path
remain unconfirmed.

Suspected root cause

The official MariaDB 11.4.12 revision b4a80422bfeec93079a430c080fffbda8f6fa574 references ColumnStore submodule
962e861c6a11e375cd95c78a517ab2b5d50e0076. This is the source inspected; correspondence to the installed plugin binary and downstream patches has not
been independently verified.

In dbcon/mysql/ha_mcs_impl.cpp:

• Lines 3122-3127: start_bulk_insert appends metadata to the session-level columnTypes vector without clearing it. reserve() does not remove existing
  entries.
• Lines 3442-3452: the thd->killed > 0 && cpimport_pid > 0 branch terminates and waits for cpimport but does not clear columnTypes or reset
  cpimport_pid.
• Line 3525: columnTypes.clear() is inside the non-killed completion branch, which also handles cpimport failures.
• Common end_bulk_insert cleanup and the rollback callback do not clear columnTypes.

The cancelled completion branch:

  if ((thd->killed > 0) && (ci->cpimport_pid > 0))

  {

      errno = 0;

      kill(ci->cpimport_pid, SIGUSR1);

      fclose(ci->filePtr);

      ci->filePtr = 0;

      ci->fdt[1] = -1;

      int aStatus;

      waitpid(ci->cpimport_pid, &aStatus, 0);

  }

In dbcon/mysql/ha_mcs_dml.cpp:707-753, write_batch_row iterates using columnTypes.size() and accesses table->field[colpos] without checking the actual
field count.

A cancelled bulk INSERT can therefore retain metadata. A later bulk INSERT on the same connection can append new entries, causing incorrect row
interpretation or invalid field access. A NULL-header bounds check can return an error first, so the outcome depends on table layout.

The cleanup omission is confirmed in the inspected source; its causal connection to these crashes remains a hypothesis. The +0x163 offset has not been
mapped to an instruction in the deployed binary. The inspected 25.10.5-1 source tag retains this cleanup behavior. No runtime reproduction on that
version has been performed.

Expected behavior and investigation request

All successful, failed, and cancelled bulk inserts should leave consistent session state. Subsequent statements must not crash MariaDB.

Please investigate metadata initialization and cleanup across cancellation/error paths, child-process lifecycle handling, and field-count validation.

A proposed regression test is to cancel an active cpimport INSERT while preserving the SQL connection, then retry an INSERT on that connection. Test
TRUNCATE and SQL ROLLBACK separately; neither is an established prerequisite. These steps have not yet been validated as a reproducer.

Evidence and limitations

Available attachments are reconstructed configuration copies, incident timelines, and source analysis. Complete raw debug logs, the full original
crash stack, table DDL/data, and a binary core dump are not included. Core availability on the affected server is unknown. No controlled reproducer is
available.

Reconnecting before retrying is a proposed mitigation because connection close deletes cal_connection_info; it has not been validated against these
incidents. DBeaver was the client, but no client-specific defect has been demonstrated.

Source references

https://github.com/mariadb-corporation/mariadb-columnstore-engine/blob/962e861c6a11e375cd95c78a517ab2b5d50e0076/dbcon/mysql/ha_mcs_impl.cpp
https://github.com/mariadb-corporation/mariadb-columnstore-engine/blob/962e861c6a11e375cd95c78a517ab2b5d50e0076/dbcon/mysql/ha_mcs_dml.cpp