EXCEPTION_ACCESS_VIOLATION error in ma_stmt_execute_generate_simple_request

[martinkjlarsson]

The following code results in Julia crashing due to an error in libmariadb.dll. The database is a MySQL database accessed through an SSH tunnel. Setting n=32 works with no issues, but n=33 crashes. Is that a limit on the number of parameters in a prepared statement?

using MySQL, DataFrames

n = 33
str = join(repeat('?', n), ',')
query = "SELECT id FROM myTable WHERE id IN ($str)"

parameters = rand(UInt64, n)

host = "127.0.0.1"
user = "user"
passwd = "password"
port = 3307
database = "database"

conn = DBInterface.connect(MySQL.Connection, host, user, passwd; db=database, port=port)

statement = DBInterface.prepare(conn, query)
cursor = DBInterface.execute(statement, parameters)
df = DataFrame(cursor)

DBInterface.close!(statement)
DBInterface.close!(conn)

The execution reaches DBInterface.execute (line 18) and then crashes with the following printout:

Please submit a bug report with steps to reproduce this fault, and any error messages that follow (in their entirety). Thanks.
Exception: EXCEPTION_ACCESS_VIOLATION at 0x693d966a -- ma_stmt_execute_generate_simple_request at C:\Users\Martin\.julia\artifacts\f82e31e2e89705335e2f2f07bd10b675704f036c\bin\libmariadb.dll (unknown line)
in expression starting at C:\Users\Martin\Documents\Repos\MariaDBError\test_min.jl:18
ma_stmt_execute_generate_simple_request at C:\Users\Martin\.julia\artifacts\f82e31e2e89705335e2f2f07bd10b675704f036c\bin\libmariadb.dll (unknown line)
mysql_stmt_execute at C:\Users\Martin\.julia\artifacts\f82e31e2e89705335e2f2f07bd10b675704f036c\bin\libmariadb.dll (unknown line)
mysql_stmt_execute at C:\Users\Martin\.julia\packages\MySQL\JGiss\src\api\ccalls.jl:4 [inlined]
execute at C:\Users\Martin\.julia\packages\MySQL\JGiss\src\api\papi.jl:3
#execute#48 at C:\Users\Martin\.julia\packages\MySQL\JGiss\src\prepare.jl:162
execute at C:\Users\Martin\.julia\packages\MySQL\JGiss\src\prepare.jl:152
unknown function (ip: 00000230ff67cfe0) at (unknown file)
jl_apply at C:/workdir/src\julia.h:2391 [inlined]
do_call at C:/workdir/src\interpreter.c:123
eval_value at C:/workdir/src\interpreter.c:243
eval_stmt_value at C:/workdir/src\interpreter.c:194 [inlined]
eval_body at C:/workdir/src\interpreter.c:707
jl_interpret_toplevel_thunk at C:/workdir/src\interpreter.c:898
jl_toplevel_eval_flex at C:/workdir/src\toplevel.c:1035
jl_toplevel_eval_flex at C:/workdir/src\toplevel.c:975
ijl_toplevel_eval at C:/workdir/src\toplevel.c:1047 [inlined]
ijl_toplevel_eval_in at C:/workdir/src\toplevel.c:1092
eval at .\boot.jl:489
include_string at .\loading.jl:2874
_include at .\loading.jl:2934
include at .\Base.jl:306
exec_options at .\client.jl:317
_start at .\client.jl:550
jfptr__start_33180.1 at C:\Users\Martin\.julia\juliaup\julia-1.12.6+0.x64.w64.mingw32\lib\julia\sys.dll (unknown line)
jl_apply at C:/workdir/src\julia.h:2391 [inlined]
true_main at C:/workdir/src\jlapi.c:971
jl_repl_entrypoint at C:/workdir/src\jlapi.c:1139
mainCRTStartup at C:/workdir/cli\loader_exe.c:58
BaseThreadInitThunk at C:\WINDOWS\System32\KERNEL32.DLL (unknown line)
RtlUserThreadStart at C:\WINDOWS\SYSTEM32\ntdll.dll (unknown line)
Allocations: 2200195 (Pool: 2200112; Big: 83); GC: 3

OS: Windows
Julia version: 1.12.6
MySQL.jl version: v1.5.1

Any help is appreciated.

[quinnj]

Update from the Windows diagnostics: MariaDB_Connector_C_jll v3.4.9+0 is now released, but it still reproduces this crash for Julia users.

Fresh diagnostic run: https://github.com/JuliaDatabases/MySQL.jl/actions/runs/27569689310

Results from that run:

• official-3.4.9 passes on both windows-2022 and windows-2025.
• jll-3.3.9 passes on both windows-2022 and windows-2025.
• jll-default, which now resolves to MariaDB_Connector_C_jll v3.4.9+0, fails on both Windows runners with the same EXCEPTION_ACCESS_VIOLATION in ma_stmt_execute_generate_simple_request at n=33.

So this does not look fixed by the released JLL yet. For now, the workaround is to pin the connector JLL back to the last known-good version:

using Pkg
Pkg.add(PackageSpec(name="MariaDB_Connector_C_jll", version=v"3.3.9+0"))

We should keep this issue open while we sort out whether this needs a JLL build fix and/or a temporary MySQL.jl compat cap to avoid resolving to the affected 3.4.x JLLs on Windows.

[quinnj]

Update from the deeper Windows/JLL investigation: this now looks like a JLL build-codegen issue rather than a MySQL.jl ABI/layout issue.

The diagnostic matrix in #237 showed the split pretty clearly:

• the released MariaDB_Connector_C_jll 3.4.9 artifact crashes on both windows-2022 and windows-2025
• the official MariaDB Connector/C 3.4.9 Windows DLL passes on both images
• the MYSQL_BIND layout matches between the official DLL and the JLL
• a Yggdrasil rebuild with -fno-tree-vectorize passes on both Windows images

The likely mechanism is GCC vectorizing Connector/C's statement request type-info loop into aligned SSE stores (movaps) into a protocol packet buffer that is not guaranteed to be 16-byte aligned. Disabling that tree-vectorization pass for the MinGW build removes that generated code path and passes the reproducer.

I've opened JuliaPackaging/Yggdrasil#13971 to rebuild MariaDB Connector/C 3.4.9 with -fno-tree-vectorize on MinGW. I think we should keep this issue open until that PR is merged and a fixed MariaDB_Connector_C_jll rebuild is released; after that, MySQL.jl should be able to use the fixed JLL without a MySQL.jl source change.