I have been trying to explore this problem further by attempting to launch star citizen in both 3.18-staging and 3.19-staging with the following WINEDEBUG settings:
Code: Select all
fixme+all,trace+all,trace-heap,+relay
I'll put my relay excludes at the bottom of this post.
Under wine 3.19 staging, a thread that is started and later hangs produces this log snippet:
Code: Select all
1242.417:008a:0091:Call ntdll.RtlWakeAddressAll(4a5b6010) ret=1442ac33b
0091: select( flags=2, cookie=67c8f7cc, timeout=0, prev_apc=0000, result={}, data={KEYED_EVENT_RELEASE,handle=0014,key=4a5b6010} )
0091: select() = 0 { timeout=1d4708c1630f852 (+0.0000000), call={APC_NONE}, apc_handle=0000 }
0091: select( flags=2, cookie=67c8f7cc, timeout=0, prev_apc=0000, result={}, data={KEYED_EVENT_RELEASE,handle=0014,key=4a5b6010} )
0091: select() = TIMEOUT { timeout=1d4708c1630fc8a (+0.0000000), call={APC_NONE}, apc_handle=0000 }
1242.418:008a:0091:Ret ntdll.RtlWakeAddressAll() retval=00000102 ret=1442ac33b
Where as under wine 3.18 staging (which works), the same thread, in the same place produces this log snippet:
Code: Select all
5559.096:00b0:00b3:Call ntdll.RtlWakeAllConditionVariable(4a579030) ret=1442d4322
00b3: select( flags=2, cookie=4aa7f7cc, timeout=infinite, prev_apc=0000, result={}, data={KEYED_EVENT_RELEASE,handle=0014,key=4a579030} )
00b3: select() = 0 { timeout=infinite, call={APC_NONE}, apc_handle=0000 }
5559.096:00b0:00b3:Ret ntdll.RtlWakeAllConditionVariable() retval=00000000 ret=1442d4322
I can not figure out why the 2 versions use different functions. I expected to see a "stub" log in the older version!
While I've been programming primarily in C and also Java, for the last 20+ years, I am new to wine debugging, and have only spent about 1 year of that in Win32 programming.
Ideally, I'm trying to explore the possibility of using the old RtlWakeAllConditionVariable (and friends) instead of the newly implemented counter parts - or at least understand why one works and the other does not.
If someone could point me in the right direction here, I would really appreciate it.
I identified the threads by tracing CreateThread calls after the "StarCitizen.exe" sub process is spawned. I should also admit that I am identifying the location in the thread by the surrounding activity ... an exception, followed by a bunch of SRWLock activity, some Virtual Memory activity the calls logged above followed by a SetThreadPriorityBoost. They also occur at the same function point in the thread relative to the thread start. I think that is a pretty good method, but understand that it is not "bullet-proof"
For those who are interested, here are my RelayExcludes:
ntdll.RtlEnterCriticalSection;ntdll.RtlTryEnterCriticalSection;ntdll.RtlLeaveCriticalSection;kernel32.48;kernel32.49;kernel32.94;kernel32.95;kernel32.96;kernel32.97;kernel32.98;kernel32.TlsGetValue;kernel32.TlsSetValue;kernel32.FlsGetValue;
kernel32.FlsSetValue;kernel32.SetLastError;KERNEL32.GetWindowsDirectoryW;KERNEL32.SetCurrentDirectoryW;advapi32.RegSetValueExW;advapi32.RegCreateKeyExW;advapi32.RegCloseKey;ucrtbase.memcmp;ucrtbase.malloc;ucrtbase.free;
ntdll.RtlAllocateHeap;ntdll.RtlFreeHeap;KERNEL32.lstrcmpA;KERNEL32.LocalAlloc;ntdll.RtlReAllocateHeap;ucrtbase.memcpy;ucrtbase.memmove;ucrtbase.isspace;ucrtbase.memchr;ucrtbase._dtest;ucrtbase.memset;ucrtbase.realloc;
ucrtbase.memset;KERNEL32.GetLocaleInfoA;KERNEL32.GetLocaleInfoW;ntdll.RtlReleaseSRWLockExclusive;ntdll.RtlAcquireSRWLockExclusive;ntdll.RtlReleaseSRWLockShared;ntdll.RtlAcquireSRWLockShared;ucrtbase.floorf;
user32.GetKeyState;ucrtbase.ceilf;ucrtbase._lrotl;ucrtbase.round;ucrtbase._lrotr