SIGBUS in ddbc_bindings.Connection on 1.7.1 (macOS arm64) when authenticating with SQL_COPT_SS_ACCESS_TOKEN against Fabric DW

[sdebruyn]

Describe the bug

On mssql-python 1.7.1 (macOS 26.3.1 arm64, Python 3.13.7), calling mssql_python.connect() with an Azure access token supplied via attrs_before / SQL_COPT_SS_ACCESS_TOKEN (1256) against a real Microsoft Fabric Data Warehouse crashes the host Python interpreter with SIGBUS (Bus error: 10). No Python exception is raised, no traceback is emitted — the process is terminated by the kernel after the TCP/TLS handshake completes and the access-token authentication exchange begins.

The same script works correctly on 1.4.0, 1.5.0, and 1.6.0 from the same machine against the same warehouse.

faulthandler pins the fault to the native ddbc_bindings.Connection(...) call:

Fatal Python error: Bus error

Current thread 0x00000001ef8eb100 (most recent call first):
  File ".../mssql_python/connection.py", line 374 in __init__
  File ".../mssql_python/db_connection.py", line 55 in connect
  File ".../repro_mssql_python_bus_error.py", line 65 in main

Extension modules: _cffi_backend (total: 1)

connection.py:374 is the self._conn = ddbc_bindings.Connection(self.connection_str, self._pooling, self._attrs_before) call.

Scope (bisect)

Tested against the same Fabric DW endpoint, same Python, same machine:

Variant	1.4.0	1.5.0	1.6.0	1.7.1
connect() + attrs_before (SQL_COPT_SS_ACCESS_TOKEN) + real Fabric DW	✅ Connected, SELECT 1 round-trips	✅	✅	❌ SIGBUS
connect() without attrs_before + fake server	n/a	n/a	✅ raises RuntimeError	✅ raises OperationalError
connect() with attrs_before (bogus token bytes) + fake server	n/a	n/a	✅ raises RuntimeError	✅ raises OperationalError

So the crash requires all of: 1.7.1, a real server that completes the TLS handshake, and attrs_before carrying SQL_COPT_SS_ACCESS_TOKEN. It is not triggered by argument-parsing of attrs_before alone, and it is not triggered without attrs_before even when the server is real. Smells like the bug lives in the token-auth handshake path in the native ddbc layer.

1.7.0 was not testable on macOS arm64 / Python 3.13.7 because no wheel was published for that platform (see #588). I cannot confirm whether 1.7.0 has the same fault.

To reproduce

Prereqs: a Microsoft Fabric workspace with a Data Warehouse, and az login against the right tenant.

"""Reproducer for SIGBUS in mssql-python 1.7.1 on macOS arm64.

Usage:
    pip install mssql-python==1.7.1 azure-identity
    az login
    export FABRIC_HOST='<workspace>-<id>.datawarehouse.fabric.microsoft.com'
    export FABRIC_DB='<warehouse name>'
    python repro_mssql_python_bus_error.py
"""
from __future__ import annotations

import faulthandler
import os
import struct
import sys
from itertools import chain, repeat

faulthandler.enable()

import mssql_python
from azure.identity import AzureCliCredential

SQL_COPT_SS_ACCESS_TOKEN = 1256
SQL_SCOPE = "https://database.windows.net/.default"


def main() -> int:
    host = os.environ["FABRIC_HOST"]
    database = os.environ["FABRIC_DB"]

    print(f"mssql-python version: {mssql_python.__version__}", flush=True)
    print(f"Python: {sys.version}", flush=True)

    token = AzureCliCredential().get_token(SQL_SCOPE).token
    token_bytes = bytes(token, "utf-8")
    encoded = bytes(chain.from_iterable(zip(token_bytes, repeat(0))))
    attrs_before = {SQL_COPT_SS_ACCESS_TOKEN: struct.pack("<i", len(encoded)) + encoded}

    conn_str = ";".join([
        f"Server={host}",
        f"Database={database}",
        "Encrypt=Yes",
        "TrustServerCertificate=No",
    ])
    print("Calling mssql_python.connect() ...", flush=True)

    handle = mssql_python.connect(
        conn_str, attrs_before=attrs_before, autocommit=True, timeout=60,
    )
    print("Connected.", flush=True)

    cur = handle.cursor()
    cur.execute("SELECT 1")
    print(f"Round-trip select returned: {cur.fetchone()}", flush=True)

    cur.close()
    handle.close()
    return 0


if __name__ == "__main__":
    raise SystemExit(main())

Expected on 1.7.1: stops after Calling mssql_python.connect() ..., kernel kills the process with Bus error: 10 and a multiprocessing semaphore leak warning. No Python traceback.

Expected on 1.6.0: prints Connected. and Round-trip select returned: (1,).

Expected behavior

mssql_python.connect() with attrs_before={SQL_COPT_SS_ACCESS_TOKEN: ...} against Fabric DW should either succeed (as on 1.6.0) or raise a Python exception (OperationalError, DatabaseError, etc.). It must not terminate the host process.

Further technical details

• mssql-python version: 1.7.1 (uploaded 2026-05-20T15:23, same day as the bug surfaced downstream)
• Python version: 3.13.7
• SQL Server version: Microsoft Fabric Data Warehouse (SQL endpoint at *.datawarehouse.fabric.microsoft.com)
• Operating system: macOS 26.3.1 arm64 (Apple Silicon)
• Auth: Azure CLI access token via attrs_before / SQL_COPT_SS_ACCESS_TOKEN (1256)
• Installer: uv pip install into a fresh Python 3.13.7 venv

[github-actions]

Hi @sdebruyn, thank you for opening this issue!

Our team will review it shortly. We aim to triage all new issues within 24-48 hours and get back to you.

If you have additional information to share, please feel free to update the issue.

Thank you for your patience!

[saurabh500]

This is likely happening due to the stack local copy of the Access Token. ODBC expects the memory address of the Access Token buffer to be retained for all the connections.
The violation of this requirement from ODBC in the PR #568 is what is causing the problem.

I will own the bug since the culprit regression is due to my changes.

I think during the PR review, I remember that Linux likely has the stacklocal copy and I am wondering why Linux doesn't repro this problem.

@sdebruyn is this repro on Linux or Windows?

@

[sdebruyn]

This is likely happening due to the stack local copy of the Access Token. ODBC expects the memory address of the Access Token buffer to be retained for all the connections. The violation of this requirement from ODBC in the PR #568 is what is causing the problem.

I will own the bug since the culprit regression is due to my changes.

I think during the PR review, I remember that Linux likely has the stacklocal copy and I am wondering why Linux doesn't repro this problem.

@sdebruyn is this repro on Linux or Windows?

@

macOS