apatrida opened a new issue, #1439:
URL: https://github.com/apache/arrow-java/issues/1439
### Describe the bug, including details regarding any error messages,
version, and platform.
When a prepared statement parameter fails to bind after earlier parameters
were bound, the Flight SQL JDBC driver keeps the Arrow memory for those earlier
values. Closing the statement does not free it. Repeated failures add up, and
closing the connection throws `Memory was leaked by query`.
The bind failure is fine. The leaked memory is the bug.
Reproduce against a Flight SQL server that marks the parameters as
non-nullable (Spice 2.4.0 does):
```java
for (int i = 0; i < 3; i++) {
try (PreparedStatement p = connection.prepareStatement(
"SELECT CAST($1 AS VARCHAR) AS txt, CAST($2 AS BIGINT) AS n")) {
p.setString(1, "O'Reilly 😀");
p.setNull(2, Types.BIGINT);
try {
p.executeQuery(); // Can't set null on non-nullable parameter
} catch (SQLException expected) {
}
}
}
connection.close();
// SQLException: Memory was leaked by query. Memory leaked: (3168)
```
After each statement closes, the connection's allocator still holds 1,056,
then 2,112, then 3,168 bytes.
A type mismatch in the second parameter leaks the same way (`setString` on a
`BIGINT` parameter: 1,040 bytes). A failure on the first parameter leaks
nothing, and successful executions leave nothing allocated after the statement
closes.
The same leak happens with no server: calling `AvaticaParameterBinder.bind`
against a stub prepared statement whose second parameter is non-nullable leaves
memory allocated after the binder throws.
Version: flight-sql-jdbc-driver 19.0.0. Platform: Linux x86_64, JDK 25.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
