[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: ssh_mutex_lock on windows failing


Since rc should be the original value of the mutex parameter before the swap (and not an error condition), I would assume this is a classic check and modify race condition. At the if condition, mutex is NULL but by the time we get to InterlockedCompareExchangePointer the value has changed.

One solution is to not fail when the exchange “fails”… instead assume that someone else beat us to the initialization and we can just enter the critical section knowing mutex is already set up.

Eg.

if (rc != NULL) {
// Someone else won the race - clean up and use theirs
DeleteCriticalSection(mutex_tmp);
free(mutex_tmp);
}

Hope that helps!
Jeremy.

From: Matthew Allen <fret@xxxxxxxxxxxx>
Sent: Monday, November 10, 2025 2:23 AM
To: libssh@xxxxxxxxxx
Subject: ssh_mutex_lock on windows failing

This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.


Hi all,

I'm seeing a very specific failure in ssh_mutex_lock on windows where the InterlockedCompareExchangePointer call fails and it falls into the DeleteCriticalSection error handler and exiting the process. This of course is quite annoying for the calling application. It's clear that "this should NOT happen".

But here is where it gets a bit weird... this only happens when I first boot windows. Once the app has run once and exited, the second and all further invocations run fine. So it's not super duper bad, but it's annoying enough I'm looking into it.

I'm building using vs2019, using the cmake to create a solution. And from the latest git code here: https://git.libssh.org/projects/libssh.git<https://urldefense.com/v3/__https:/git.libssh.org/projects/libssh.git__;!!GAuxx38R6fLb!PEIhmCa1A7PdtrnhrY_7RVerTP0UIgHOXY4fiox2zl_CABBRhxyitlVclGRMVPjCI6AY-W6bB7aM-64$>

Has anyone else seen this behaviour?

Or have any smart ideas on what could be causing this?


More info, my stack trace looks like this:

ssh.dll!ssh_mutex_lock(_RTL_CRITICAL_SECTION * * mutex) Line 108 C
ssh.dll!is_ssh_initialized() Line 289 C
ssh.dll!ssh_connect(ssh_session_struct * session) Line 532 C
Lvc.exe!LSsh::Open(const char * Host, const char * Username, const char * Password, bool PublicKey, int Port) Line 516 C++
Lvc.exe!SshConnection::GetConsole() Line 88 C++
Lvc.exe!SshConnection::GetStream() Line 82 C++
Lvc.exe!SshConnection::OnEvent(LMessage * Msg) Line 401 C++
Lgi19x64d.dll!LEventTargetThread::Main() Line 381 C++
Lgi19x64d.dll!ThreadEntryPoint(void * i) Line 80 C++

Where 'Lvc.exe' is my application. And the final call is 'exit(ENOMEM);' And yes, this is running in a worker thread. Not the main GUI thread. Not sure if that's important. But it might be relevant.

Regards

Matthew Allen
Memecode

References:
ssh_mutex_lock on windows failing"Matthew Allen" <fret@xxxxxxxxxxxx>
Archive administrator: postmaster@lists.cynapses.org