pdo_dblib: segfault after a failed query inside a PDO transaction

Description

A query that fails while a transaction started by PDO::beginTransaction() is open leaves the
connection in a state where PHP crashes with SIGSEGV. The script itself runs to completion - the
segfault happens afterwards, during shutdown.

The following code:

<?php
$pdo = new PDO("dblib:host=localhost;port=1433", "user", "password", array(PDO::ATTR_ERRMODE => PDO::ERRMODE_SILENT));

$pdo->query("DROP VIEW IF EXISTS crash_test");
$pdo->query("DROP TABLE IF EXISTS crash_test");
$pdo->query("CREATE TABLE crash_test (id int)");

$pdo->beginTransaction();
$pdo->query("CREATE VIEW crash_test AS SELECT 1 AS x"); // fails: there is already an object named 'crash_test'
$pdo->rollBack();

$pdo->query("DROP TABLE IF EXISTS crash_test");
echo "reached the end of the script\n";

Resulted in this output:

reached the end of the script
Segmentation fault (core dumped)

But I expected this output instead:

reached the end of the script

The exit code is 139. It reproduced on 5 runs out of 5, and with USE_ZEND_ALLOC=0 as well.

What the crash needs

Changing one thing at a time in the script above, 3 runs each:

Variant	Result
as above	crashes 3/3
BEGIN TRANSACTION as a query instead of PDO::beginTransaction()	no crash
no transaction at all	no crash
the failing CREATE VIEW removed	no crash
commit() instead of rollBack()	crashes 3/3
neither commit() nor rollBack()	crashes 3/3
the trailing DROP TABLE removed	no crash

So it takes a transaction opened through the PDO API (not through SQL), a query that fails inside
it, and at least one further query afterwards. Whether the transaction is then rolled back,
committed or left open makes no difference.

Which statement fails does not seem to matter by itself - in a longer script I saw the same crash
after a failing SELECT, INSERT, ALTER TABLE, DROP TABLE, EXEC and RAISERROR. But in
scripts shorter than the one above the very same ingredients sometimes do not crash, which looks
like the visible fault depending on when the affected memory is reused rather than on the
statement.

I have no backtrace: there is no gdb or valgrind on the machine where this reproduces.

Where I hit it

Browsing a database in Adminer with pdo_dblib: altering a stored procedure to a name already
taken by a table killed the php -S server outright, because the failing CREATE PROCEDURE runs
inside a transaction Adminer opens through PDO::beginTransaction().

PHP Version

PHP 8.4.25 (cli), php8.4-sybase 8.4.25-1+ubuntu24.04.1+deb.sury.org+1

Operating System

Ubuntu 24.04.4 LTS (WSL2), FreeTDS 1.3.17 (libsybdb5 1.3.17+ds-2build3), TDS protocol 7.4,
against Microsoft SQL Server 2025 (RTM-GDR) 17.0.1135.8.

PHP Version

PHP 8.4.25 (cli) (built: Aug 28 2026 06:55:33) (NTS)
Copyright (c) The PHP Group
Built by Ubuntu
Zend Engine v4.4.25, Copyright (c) Zend Technologies
    with Zend OPcache v8.4.25, Copyright (c), by Zend Technologies

Operating System

Ubuntu 24.04.4 LTS