Fedora 32

See also ODBC-291 – possibly the same bug.

Thank you for your report.
Could you please verify it with version 3.1.9 or provide the testcase?
Because I could not repeat the crash right away based on the described steps.

Yes it's still happening in 3.1.9 and I've put together a small test case:

// gcc $(pkg-config --cflags odbc) -g -o odbc289 odbc289.c $(pkg-config --libs odbc)

#include <assert.h>

#include <sqlext.h>

#include <stdio.h>

int main(int argc, char **argv)

{

  SQLHANDLE hdbc;

  SQLHANDLE henv;

  SQLHANDLE hstmt;

  SQLRETURN rc;

  rc = SQLAllocHandle( SQL_HANDLE_ENV, SQL_NULL_HANDLE, &henv );

  assert( rc == SQL_SUCCESS );

  rc = SQLSetEnvAttr( henv, SQL_ATTR_ODBC_VERSION, (SQLPOINTER)SQL_OV_ODBC3, 0 );

  assert( rc == SQL_SUCCESS );

  rc = SQLAllocHandle( SQL_HANDLE_DBC, henv, &hdbc );

  assert( rc == SQL_SUCCESS );

  rc = SQLConnect( hdbc, "x", SQL_NTS, "x", SQL_NTS, "x", SQL_NTS );

  assert( rc == SQL_SUCCESS );

  rc = SQLAllocHandle( SQL_HANDLE_STMT, hdbc, &hstmt );

  assert( rc == SQL_SUCCESS );

  rc = SQLPrepare( hstmt, "SELECT LAST_NAME FROM CUST", SQL_NTS );

  assert( rc == SQL_SUCCESS );

  rc = SQLSetStmtAttr( hstmt, SQL_ATTR_ROW_ARRAY_SIZE, (SQLPOINTER)2, SQL_IS_INTEGER );

  assert( rc == SQL_SUCCESS );

  SQLCHAR value[60];

  SQLLEN length[2];

  rc = SQLBindCol( hstmt, 1, SQL_CHAR, value, 30, length );

  assert( rc == SQL_SUCCESS );

  rc = SQLExecute( hstmt );

  assert( rc == SQL_SUCCESS );

  rc = SQLFetch( hstmt );

  assert( rc == SQL_SUCCESS );

  printf( "fetch: %s\n", value );

  printf( "fetch: %s\n", value + 30 );

  rc = SQLFreeStmt( hstmt, SQL_CLOSE );

  assert( rc == SQL_SUCCESS );

  rc = SQLExecute( hstmt );

  assert( rc == SQL_SUCCESS );

  rc = SQLFetch( hstmt );

  assert( rc == SQL_SUCCESS );

  printf( "fetch: %s\n", value );

  printf( "fetch: %s\n", value + 30 );

  return 0;

}

Obviously you'll need to fill in a DSN and authentication details for the SQLConnect call and update the SQL statement to something appropriate for the database you're using. Run that under valgrind and you should see it complain during the second fetch.

Interesting, for me your testcase doesn't look different from the one I've already pushed, and it passes
Ok, I must try with your test anyway

Possibly it depends on the version of the underlying C library - it wasn't clear to me where the bug actually was after all.

I'm using version 3.1.10 of the C connector.

In our binaries we still link (Conn/C) statically(there is the old plan to link dynamically for platforms other than WIndows). Linux distributions link dynamically. 3.1.9 release linked against C/Cv3.1.9, and on github it already uses C/C 3.1.10, thus travis used that version as well.

Your test does not crash for me either. The thing is that there is very similar bug report, but/and it also against 3.1.7
so, I have to try to figure out something

Just to be clear this won't necessarily crash - it may do but it will be dependent on exactly what happens with the freed memory among other things. What it will do is warn under valgrind, or likely in an ASAN build though I haven't tried that.

As it happens my version with a string field does crash for me at least, while changing it to use a numeric field like your test case stops it crashing while still giving a warning under valgrind.

Commit 22f1255. The testcase has been pushed before.
The warning in valgrind has been cleared.

To be clear – you are saying that this issue is fixed by 3.1.9, or that it will be fixed in a still-to-be-released version?

sabell no, the bug is present in 3.1.9, the fix will be in 3.1.10 release.
and it's gonna be published soon.

Thanks for confirming!