Access violation writing location in ConnectionHandles::clear() due to racecondition

[gazsi150]

Using msnodesqlv8 v5.1.1 with sqlserver2022

The following line sporadically crashes with error message Unhandled exception at 0x00007FF84E30D7CD (ntdll.dll) in <xxx.exe>.dmp: 0xC0000005: Access violation writing location 0x0000000000000010. because the handle was already freed

node-sqlserver-v8/cpp/src/odbc/connection_handles.cpp

Line 61 in 42539dc

auto cancelResult = SQLCancel(handle->get_handle());

i suspect the following function has already cleared the statement form the collection

node-sqlserver-v8/cpp/src/odbc/connection_handles.cpp

Lines 165 to 178 in 42539dc

	void ConnectionHandles::checkin(long statementId) {
	SQL_LOG_DEBUG_STREAM("ConnectionHandles::checkin - statementId = " << statementId);
	const auto itr = _statementHandles.find(statementId);
	if (itr == _statementHandles.end()) {
	SQL_LOG_ERROR_STREAM(
	"ConnectionHandles::checkin - no handle found for statementId = " << statementId);
	return;
	}
	// Free the handle through SafeHandle
	itr->second->free();
	_statementHandles.erase(statementId);
	}

Because the calling function OdbcConnection::RemoveStatement() doesn't lock the _connectionMutex and OdbcConnection::Close() doesn't lock the _statementMutex

The client application runs a query using the following function chain

sql.open(connectionString, (err, conn) => {
  if (err) {
  ...
  } else {
  var pm = conn.procedureMgr();
  pm.setTimeout(timeout);
  pm.getProc(queryName, (err, procedure) => {
  if(err) {
    conn.close(() => {...});
   } else {
     var query = procedure.call(args);
     query.on('done', () => {
         conn.close(() => {...});
     });
     query.on('error', err => {
         conn.close(() => {...});
     });
     query.on('info', i => {...});
     query.on('meta', meta => {...});
     query.on('column', (index, data) => {...});
     query.on('row', index => {...});
     query.on('free', () => {...});
    }
  }
});

There wasn't any running parallel API calls.

[TimelordUK]

are you able to build the latest master branch to see if this is fixed - i noticed a flag is not being handed through correctly, without more information i cant spend time on this , can you at least turn on log trace and write a program to repeatedly run code

❯ cat simple-logging-config.js
'use strict'

// Handle SIGPIPE gracefully when output is piped
process.on('SIGPIPE', () => {
  process.exit(0)
})

const sql = require('../../lib/sql')

// Example 1: Enable trace logging for debugging
// This will show all JavaScript and C++ debug messages
sql.logger.setLogLevel(sql.LogLevel.TRACE)
sql.logger.setConsoleLogging(true)

// Example 2: Enable logging to a file
// sql.logger.setLogFile('/var/log/myapp/sql-trace.log')

// Example 3: Use pre-configured settings
// sql.logger.configureForDevelopment()  // TRACE level, console enabled
// sql.logger.configureForProduction('/var/log/myapp')  // ERROR level, file only
// sql.logger.configureForTesting()  // SILENT level

// Example 4: Disable all logging (default for production)
// sql.logger.setLogLevel(sql.LogLevel.SILENT)

// Now all SQL operations will use the configured logging

const { TestEnv } = require('../../test/env/test-env')
const env = new TestEnv()
const connectionString = env.connectionString

sql.open(connectionString, (err, conn) => {
  if (err) {
    console.error('Connection failed:', err)
    return
  }

  conn.query('SELECT 1 as test', (err, results) => {
    if (err) {
      console.error('Query failed:', err)
    } else {
      console.log('Query succeeded:', results)
    }
    conn.close()
  })
})%
```

[TimelordUK]

this shoud produce very detailed log trace

❯ tail -10 test.trace.crash.txt
},
"oldState": "STATEMENT_BINDING",
"newState": "STATEMENT_SUBMITTED"
})
[2025-12-17T17:09:01.464Z] [CPP] [132533597435456] [TRACE] >> Entering CancelStatement
[2025-12-17T17:09:01.464Z] [CPP] [132533597435456] [DEBUG] CancelStatement: OdbcConnection::CancelStatement called for ID = 0
[2025-12-17T17:09:01.464Z] [CPP] [132533597435456] [DEBUG] CancelStatement: OdbcConnection::Found statement for ID = 0
[2025-12-17T17:09:01.464Z] [CPP] [132533597435456] [DEBUG] CancelStatement: OdbcConnection::Found statement for ID = 1
[2025-12-17T17:09:01.464Z] [CPP] [132533597435456] [DEBUG] Cancel: OdbcStatementLegacy::Cancel Enter [CID: 0, STMT: 1] cancel 8823782545140577649 0 state STATEMENT_SUBMITTED
[2025-12-17T17:09:01.464Z] [CPP] [132533597435456] [TRACE] SQLCancelHandle: SQLCancelHandle called - HandleType: 3, Handle: 0x7889b80050e0

[gazsi150]

I couldn't reproduce the issue with the simple-logging-config.js so i set up the logging in my client application. It generated 118MB logs so i cut out the part where the crash happened in time.
For this i used the released v5.1.1.

sql-trace_edited2.log

[TimelordUK]

yes it does look like a concurrent access to handles problem, ill add a protective lock

[TimelordUK]

please try latest version we have protected with a lock which should fix this double free