Summary
mssql-python 1.10.0 crashes with a SIGSEGV during concurrent multi-threaded fetching on macOS arm64. The process is killed by the signal with no Python traceback (exit 139). The macOS crash report puts the faulting frame inside libmsodbcsql.18.dylib at SQLFetchScroll, reached through the driver's ddbc_bindings (FetchBatchData / FetchMany_wrap).
This looks like the same underlying problem as #668 (TLS stream corruption under concurrent threaded reads on macOS arm64), but here the failure is a hard crash instead of corrupted rows or a link error, so I am reporting it separately with the native stack. More on that connection at the end.
Environment
- macOS 26.5.2 (build 25F84), Apple Silicon (arm64)
- Python 3.12.11
- mssql-python 1.10.0 (bundled
libmsodbcsql.18.dylib, ddbc_bindings.cp312-universal2.so)
- SQLAlchemy 2.1.0b3,
mssql+mssqlpython dialect
- Connection:
Encrypt=yes, TrustServerCertificate=yes, built-in connection pooling on, transaction isolation SNAPSHOT
- Remote SQL Server, reached over a VPN
How it shows up
The workload is a dlt sql_database extract on the pyarrow backend. Eight worker threads read different tables at the same time, each running a SELECT and pulling rows with fetchmany. The crash lands during the fetch phase, early in a schema that has many tables loading concurrently. It is intermittent and happens under sustained concurrent reads, not on one specific row. A short synthetic stress script did not force it, which is in line with what others noted on #668.
Fault
EXC_BAD_ACCESS (SIGSEGV), KERN_INVALID_ADDRESS at 0x0000000000000008 (a dereference through a near-null pointer).- At crash time, 6 of 29 threads were executing inside
libmsodbcsql.18.dylib and 2 were in a fetch call. That points at a race in the driver's read path under concurrency, not at bad input.
Native stack (crashing thread)
The interpreter side is a plain SQLAlchemy result iteration (_manyrow_getter, i.e. fetchmany) calling into the driver:
libmsodbcsql.18.dylib SQLFetchScroll <-- faulting frame
ddbc_bindings.cp312-universal2.so FetchBatchData(...)
ddbc_bindings.cp312-universal2.so FetchMany_wrap(...)
ddbc_bindings.cp312-universal2.so pybind11 dispatcher
libpython3.12.dylib _PyEval_EvalFrameDefault
_result_cy.cpython-312-darwin.so sqlalchemy BaseResultInternal _manyrow_getter
libpython3.12.dylib builtin_next
Full frames from the .ips crash report:
crashing thread, all frames
0 libmsodbcsql.18.dylib + 1127984
1 libmsodbcsql.18.dylib + 1171428
2 libmsodbcsql.18.dylib + 1199848
3 libmsodbcsql.18.dylib + 1140492
4 libmsodbcsql.18.dylib + 943376
5 libmsodbcsql.18.dylib + 859712
6 libmsodbcsql.18.dylib + 867548
7 libmsodbcsql.18.dylib + 905332
8 libmsodbcsql.18.dylib + 164368
9 libmsodbcsql.18.dylib + 450000
10 libmsodbcsql.18.dylib + 462896
11 libmsodbcsql.18.dylib + 463820 SQLFetchScroll
12 ddbc_bindings.cp312-universal2.so + 111852 FetchBatchData(...)
13 ddbc_bindings.cp312-universal2.so + 123228 FetchMany_wrap(...)
14 ddbc_bindings.cp312-universal2.so + 373200 pybind11 argument_loader::call
15 ddbc_bindings.cp312-universal2.so + 186332 pybind11::cpp_function::dispatcher
16 libpython3.12.dylib + 677576 _PyEval_EvalFrameDefault
17 _result_cy.cpython-312-darwin.so + 92288 sqlalchemy BaseResultInternal _manyrow_getter
18 libpython3.12.dylib + 2721008 gen_iternext
19 libpython3.12.dylib + 2918080 builtin_next
20 libpython3.12.dylib + 1906720 thread_run
21 libsystem_pthread.dylib + 27736 _pthread_start
22 libsystem_pthread.dylib + 7196 thread_start
Likely relation to #668
#668 reports concurrent threaded reads on macOS arm64 with Encrypt=yes corrupting the TDS/TLS stream: single-character substitutions in returned strings, Communication link failure, Protocol error in TDS stream, and timeouts. It reproduces with pyodbc plus msodbcsql18 too, so it lives in the ODBC/TLS layer. A commenter there suspects the read path is corrupting adjacent heap memory. A near-null dereference in SQLFetchScroll fits that reading: the same corruption, landing on a pointer rather than a data byte. Same trigger (macOS arm64, mssql-python 1.10.0, Encrypt=yes, concurrent reads), heavier outcome.
Summary
mssql-python 1.10.0 crashes with a SIGSEGV during concurrent multi-threaded fetching on macOS arm64. The process is killed by the signal with no Python traceback (exit 139). The macOS crash report puts the faulting frame inside
libmsodbcsql.18.dylibatSQLFetchScroll, reached through the driver'sddbc_bindings(FetchBatchData/FetchMany_wrap).This looks like the same underlying problem as #668 (TLS stream corruption under concurrent threaded reads on macOS arm64), but here the failure is a hard crash instead of corrupted rows or a link error, so I am reporting it separately with the native stack. More on that connection at the end.
Environment
libmsodbcsql.18.dylib,ddbc_bindings.cp312-universal2.so)mssql+mssqlpythondialectEncrypt=yes,TrustServerCertificate=yes, built-in connection pooling on, transaction isolation SNAPSHOTHow it shows up
The workload is a dlt
sql_databaseextract on the pyarrow backend. Eight worker threads read different tables at the same time, each running aSELECTand pulling rows withfetchmany. The crash lands during the fetch phase, early in a schema that has many tables loading concurrently. It is intermittent and happens under sustained concurrent reads, not on one specific row. A short synthetic stress script did not force it, which is in line with what others noted on #668.Fault
EXC_BAD_ACCESS (SIGSEGV),KERN_INVALID_ADDRESS at 0x0000000000000008(a dereference through a near-null pointer).libmsodbcsql.18.dyliband 2 were in a fetch call. That points at a race in the driver's read path under concurrency, not at bad input.Native stack (crashing thread)
The interpreter side is a plain SQLAlchemy result iteration (
_manyrow_getter, i.e.fetchmany) calling into the driver:Full frames from the
.ipscrash report:crashing thread, all frames
Likely relation to #668
#668 reports concurrent threaded reads on macOS arm64 with
Encrypt=yescorrupting the TDS/TLS stream: single-character substitutions in returned strings,Communication link failure,Protocol error in TDS stream, and timeouts. It reproduces with pyodbc plus msodbcsql18 too, so it lives in the ODBC/TLS layer. A commenter there suspects the read path is corrupting adjacent heap memory. A near-null dereference inSQLFetchScrollfits that reading: the same corruption, landing on a pointer rather than a data byte. Same trigger (macOS arm64, mssql-python 1.10.0,Encrypt=yes, concurrent reads), heavier outcome.