Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

pdo_dblib: segfault after a failed query inside a PDO transaction

Fechada
  • Algo errado?
#23,741 0 comentários 0 reações 1 responsável Ver no GitHub

Mantenedores costumam responder em até 1 dia

@iliaal já está trabalhando nisso.

Desde 17/9/2026.

  • #23751 de @iliaal — aberto

Avaliação

Esta issue ainda não foi avaliada.

Descrição

Bug Extension: pdo_dblib Status: Verified
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

Linguagem predominante
C
Estrelas
40.4k
Forks
8.2k
Merge médio
2d 7h
PRs com merge (30d)
153

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de php/php-src

Todas as issues de php/php-src

Issues semelhantes

Mais issues de C

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.