Description
Describe the bug
It seems the change proposed in #7000 and merged in 53ef5df introduces some problem which produces a crash:
=ERROR REPORT==== 15-Jan-2025::12:06:47.047985 ===
** Generic server <0.88.0> terminating
** Last message in was {#Port<0.7>,{exit_status,2}}
** When Server state == {state,#Port<0.7>,
{<0.9.0>,#Ref<0.1085833572.4179361795.157557>},
<0.9.0>,undefined,on,true,true,on,connected,
undefined,0,
[#Port<0.5>,#Port<0.6>],
#Port<0.8>,#Port<0.9>}
** Reason for termination ==
** {port_exit,memory_allocation_failed}
=CRASH REPORT==== 15-Jan-2025::12:06:47.048161 ===
crasher:
initial call: odbc:init/1
pid: <0.88.0>
registered_name: []
exception exit: {port_exit,memory_allocation_failed}
in function gen_server:handle_common_reply/8 (gen_server.erl, line 1226)
ancestors: [odbc_sup,<0.86.0>]
message_queue_len: 1
messages: [{'EXIT',#Port<0.7>,normal}]
links: [<0.87.0>]
dictionary: []
trap_exit: true
status: running
heap_size: 4185
stack_size: 28
reductions: 12252
neighbours:
To Reproduce
Elements required to trigger the problem:
- Erlang/OTP 26.0-rc3 or higher (affects also 27.2)
- MSSQL (both versions 2019 and 2022)
- Table created with specific contraints
- Select content from that table (table may or may not be empty)
I tried to reduce as much as possible the reproduction steps, but maybe it can be triggered with more simple table definition, or other databases.
How to reproduce the problem using my example:
- Install podman, used to setup the mssql database
- Install the Erlang/OTP version to test
- Download erlang-odbc-reproduce.zip and extract
- Run
test.sh
Test success with Erlang 25.3
$ ./test.sh
...
Version: "Erlang/OTP 25 [erts-13.2] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:1] [jit:ns]\n"
...
Result: {selected,["lastname2"],[{"lastname2"}]}
Test failure with Erlang 27.2
$ ./test.sh
...
Version: "Erlang/OTP 27 [erts-15.2] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:1] [jit:ns]\n"
...
Result: {error,connection_closed}
=ERROR REPORT==== 15-Jan-2025::12:06:47.047985 ===
...
** Reason for termination ==
** {port_exit,memory_allocation_failed}
...
Expected behavior
The msqql server really sends the response, as seen by sniffing the traffic with sudo tcpflow -i lo -Cg port 1433. And that response is similar when using an old and a new Erlang version, so why does odbc crash?
If there's any problem in the SQL query, or in the MSSQL response, erlang should log a clear explanation about the problem.
Affected versions
Erlang/OTP 26.0-rc3 and higher, including 27.2
By reverting that commit into 27.2, the problem disappears.
Additional context
Other reports related to this problem: