--
v3: ntdll: Use HashLinks when searching for a dll using the basename.
kernel32/tests: Add tests for module hash links.
kernel32/tests: Factor out is_old_loader_struct().
https://gitlab.winehq.org/wine/wine/-/merge_requests/6792
--
v2: msvidc32: Use the correct channel order for RGB24.
msvidc32: Convert to RGB24 by simple bit shifts.
msvidc32: Reject incompatible output compression.
msvidc32/tests: Add MS Video-1 decoder tests.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6798
References held by contained stream objects must use an internal refcount, otherwise they prevent release of the media source if Start() and Shutdown() are not called.
--
v4: winegstreamer: Release stream references to the media source in Shutdown().
winegstreamer: Do not create MF stream objects until the media source is started.
mfplat/tests: Test video stream release after media source release.
mfplat/tests: Add more media source refcount checks.
mfplat/tests: Always free media events sent to the callback.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6783
A llvm-mingw built winver.exe with ASan enabled shows below error
when exiting the application.
This seems to be caused by libc++ using register_onexit_function
before ASan has all function hooks in place, therefore allocates
memory with plain calloc function.
On process exit ASan uses in asan_allocator.cpp/Deallocate the
function HeapValidate, which fails if msvcrt does not use the heap
returned by GetProcessHeap().
```
wine64 winver_asan.exe
=================================================================
==292==ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0x7ffffea05a10 in thread T0
0130:fixme:file:server_get_file_info Unsupported info class e
#0 0x6ffffa809fe1 in free .../llvm-mingw/llvm-project/compiler-rt\lib/asan/asan_malloc_win.cpp:71:3
#1 0x6ffffeb048c5 in execute_onexit_table /home/bernhard/wine/dlls/msvcrt\exit.c:141:5
#2 0x6ffffbfb109e in _CRT_INIT .../llvm-mingw/mingw-w64/mingw-w64-crt/build-x86_64\../crt\crtdll.c:130:11
#3 0x6ffffbfb1316 in __DllMainCRTStartup .../llvm-mingw/mingw-w64/mingw-w64-crt/build-x86_64\../crt\crtdll.c:196:6
#4 0x6fffffc6d223 in call_dll_entry_point (C:\windows\system32\ntdll.dll+0x17002d223)
#5 0x6fffffc71fdd in MODULE_InitDLL /home/bernhard/wine/dlls/ntdll\loader.c:1720:16
#6 0x6fffffc72601 in process_detach /home/bernhard/wine/dlls/ntdll\loader.c:1866:13
#7 0x6fffffc726f5 in RtlExitUserProcess /home/bernhard/wine/dlls/ntdll\loader.c:3893:5
#8 0x6fffffa8b899 in ExitProcess /home/bernhard/wine/dlls/kernel32\process.c:207:5
#9 0x6ffffeb054a7 in exit /home/bernhard/wine/dlls/msvcrt\exit.c:383:3
#10 0x000140001338 in mainCRTStartup /home/bernhard/wine/dlls/msvcrt\crt_main.c:60:5
#11 0x6fffffa98d58 in BaseThreadInitThunk /home/bernhard/wine/dlls/kernel32\thread.c:61:5
#12 0x6fffffc95afa in RtlUserThreadStart (C:\windows\system32\ntdll.dll+0x170055afa)
Address 0x7ffffea05a10 is a wild pointer inside of access range of size 0x000000000001.
SUMMARY: AddressSanitizer: bad-free /home/bernhard/wine/dlls/msvcrt\exit.c:141:5 in execute_onexit_table
==292==ABORTING
```
Please provide some guidance if this needs to be separated commits per msvcrt version, and if they are all needed (or more)?
--
v2: msvcrt: Do not create in newer msvcrt versions a separate heap.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6791
This stops GCC from optimizing out a `for` loop inside the `dump_cv_sst_src_module()` function, when tools/winedump is compiled with optimization settings -O1 or higher.
Because the `baseSrcLn` field of the `struct OMFSourceFile` was declared as an array of one element **and it is an interior member** of the structure:
```c
typedef struct OMFSourceFile
{
unsigned short cSeg;
unsigned short reserved;
unsigned int baseSrcLn[1];
unsigned short cFName;
char Name;
} OMFSourceFile;
```
The compiler/optimizer assumes that the `baseSrcLn` array may have only zero or one element. And generates the corresponding code.
The following shows code that GCC 14.2.1 generates before and after this patch.
Before patch:
```
524f: e8 0c ef ff ff call 4160 <printf@plt> # this printf(3)'s "File table: ..."
# r15 stores sourceFile->cSeg; assigned above.
5254: 66 41 83 3c 24 00 cmpw $0x0,(%r12) # r12 is sourceFile
525a: 74 22 je 527e <dump_codeview+0x70e>
525c: 4b 8d 44 bc 04 lea 0x4(%r12,%r15,4),%rax #rax is seg_info_dw
5261: 45 8b 44 24 04 mov 0x4(%r12),%r8d # sourceFile->baseSrcLn[0]
5266: be 01 00 00 00 mov $0x1,%esi
526b: 48 8d 3d fe 02 04 00 lea 0x402fe(%rip),%rdi # 45570
5272: 8b 48 04 mov 0x4(%rax),%ecx
5275: 8b 10 mov (%rax),%edx
5277: 31 c0 xor %eax,%eax
5279: e8 e2 ee ff ff call 4160 <printf@plt>
527e: 41 0f b6 06 movzbl (%r14),%eax # eax = sourceModule + ofs
```
The code checks if the `sourceFile->cSeg` is zero or not, and if not it `printf(3)`s information about the first element in the `baseSrcLn` and first offset pair.
There is no `for` loop there, only its first iteration.
After patch:
```
525c: e8 ff ee ff ff call 4160 <printf@plt> # this printf(3)'s "File table: ..."
# r12 is seg_info_dw and r15 stores integer 1; both assigned above.
# r15 is `i' -- the loop counter.
5261: 66 41 83 3e 00 cmpw $0x0,(%r14) # r14 is sourceFile
5266: 74 37 je 529f <dump_codeview+0x72f>
5268: 0f 1f 84 00 00 00 00 nopl 0x0(%rax,%rax,1)
526f: 00
5270: 43 8b 54 fc f8 mov -0x8(%r12,%r15,8),%edx
5275: 43 8b 4c fc fc mov -0x4(%r12,%r15,8),%ecx
527a: 44 89 fe mov %r15d,%esi
527d: 31 c0 xor %eax,%eax
527f: 47 8b 04 be mov (%r14,%r15,4),%r8d # sourceFile->baseSrcLn[i]
5283: 48 8d 3d e6 02 04 00 lea 0x402e6(%rip),%rdi # 45570
528a: 49 83 c7 01 add $0x1,%r15
528e: e8 cd ee ff ff call 4160 <printf@plt>
5293: 41 0f b7 06 movzwl (%r14),%eax
5297: 41 8d 57 ff lea -0x1(%r15),%edx
529b: 39 c2 cmp %eax,%edx
529d: 7c d1 jl 5270 <dump_codeview+0x700>
529f: 48 8b 44 24 18 mov 0x18(%rsp),%rax # rax = sourceModule + ofs
```
The `for` loop now is where it should be.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6780
This fixes https://bugs.winehq.org/show_bug.cgi?id=52094.
--
v6: ntdll: Properly track refcount with forwarded exports.
ntdll: Don't re-add a module dependency if it already exists.
ntdll: Remove some NULL checks for current_importer.
ntdll: Set export forwarder DLL as the dynamic importer in LdrGetProcedureAddress().
ntdll: Wrap current_modref variable in a new structure.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7
A llvm-mingw built winver.exe with ASan enabled shows below error
when exiting the application.
This seems to be caused by libc++ using register_onexit_function
before ASan has all function hooks in place, therefore allocates
memory with plain calloc function.
On process exit ASan uses in asan_allocator.cpp/Deallocate the
function HeapValidate, which fails if msvcrt does not use the heap
returned by GetProcessHeap().
```
wine64 winver_asan.exe
=================================================================
==292==ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0x7ffffea05a10 in thread T0
0130:fixme:file:server_get_file_info Unsupported info class e
#0 0x6ffffa809fe1 in free .../llvm-mingw/llvm-project/compiler-rt\lib/asan/asan_malloc_win.cpp:71:3
#1 0x6ffffeb048c5 in execute_onexit_table /home/bernhard/wine/dlls/msvcrt\exit.c:141:5
#2 0x6ffffbfb109e in _CRT_INIT .../llvm-mingw/mingw-w64/mingw-w64-crt/build-x86_64\../crt\crtdll.c:130:11
#3 0x6ffffbfb1316 in __DllMainCRTStartup .../llvm-mingw/mingw-w64/mingw-w64-crt/build-x86_64\../crt\crtdll.c:196:6
#4 0x6fffffc6d223 in call_dll_entry_point (C:\windows\system32\ntdll.dll+0x17002d223)
#5 0x6fffffc71fdd in MODULE_InitDLL /home/bernhard/wine/dlls/ntdll\loader.c:1720:16
#6 0x6fffffc72601 in process_detach /home/bernhard/wine/dlls/ntdll\loader.c:1866:13
#7 0x6fffffc726f5 in RtlExitUserProcess /home/bernhard/wine/dlls/ntdll\loader.c:3893:5
#8 0x6fffffa8b899 in ExitProcess /home/bernhard/wine/dlls/kernel32\process.c:207:5
#9 0x6ffffeb054a7 in exit /home/bernhard/wine/dlls/msvcrt\exit.c:383:3
#10 0x000140001338 in mainCRTStartup /home/bernhard/wine/dlls/msvcrt\crt_main.c:60:5
#11 0x6fffffa98d58 in BaseThreadInitThunk /home/bernhard/wine/dlls/kernel32\thread.c:61:5
#12 0x6fffffc95afa in RtlUserThreadStart (C:\windows\system32\ntdll.dll+0x170055afa)
Address 0x7ffffea05a10 is a wild pointer inside of access range of size 0x000000000001.
SUMMARY: AddressSanitizer: bad-free /home/bernhard/wine/dlls/msvcrt\exit.c:141:5 in execute_onexit_table
==292==ABORTING
```
Please provide some guidance if this needs to be separated commits per msvcrt version, and if they are all needed (or more)?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6791
This fixes https://bugs.winehq.org/show_bug.cgi?id=52094.
--
v5: ntdll: Properly track refcount with forwarded exports.
ntdll: Don't re-add a module dependency if it already exists.
ntdll: Remove some NULL checks for current_importer.
ntdll: Update current importer in LdrGetProcedureAddress().
ntdll: Wrap current_modref variable in a new structure.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7
structuredquery is required to support AQS filters in Windows.Devices.Enumeration's `FindAllAsync` methods, and this stubs adds a basic set of stubs to get the ball rolling.
--
v7: dlls/structuredquery: Add stubs for IQueryParserManager.
dlls/structuredquery/tests: Add basic conformance tests for IQueryParserManager.
include/structuredquery.idl: Add IQueryParserManager.
dlls/structuredquery: Add stubs for QueryParser.
dlls/structuredquery/tests: Add basic conformance tests for QueryParser.
dlls/structuredquery: Add stub.
include: Add structuredquery.idl.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6788
> I'm not enthusiastic anymore about championing my patches, knowing I can always maintain a local patchset or submit them to Proton
It's no use sending them to Proton because the same people who maintain Wine and Wine Staging also maintain Proton. You could try to get the patches accepted in another Wine derivative, but I think a bigger problem may be that the infinite-sleep workaround kind of only works by accident, so even though it works for the current version of MS Office, I expect that it will break in a future version. I hate to say it, but your time and energy, which I greatly appreciate, would probably be better spent on other Wine bugs.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5522#note_86895
References held by contained stream objects must use an internal refcount, otherwise they prevent release of the media source if Start() and Shutdown() are not called.
--
v3: winegstreamer: Introduce an internal refcount in media source objects.
mfplat/tests: Test the refcount before the media source is released.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6783
On Thu Nov 7 23:04:24 2024 +0000, Elizabeth Figura wrote:
> > > Proton hack won't be acceptable upstream
> >
> > I learned that Wine and wine-staging doesn't like app-specific code.
> However, Proton has [a lot of app-specific
> workarounds](https://github.com/ValveSoftware/Proton/blob/1a73b04e6cdf29297….
> Since Microsoft
> [famously](https://arstechnica.com/gadgets/2022/10/windows-95-went-the-extra…
> has app-specific workarounds (which Wine needs to emulate for full
> conformance), our own workaround for Microsoft Office wouldn't be much
> different on the technical side. On the social side, Wine wouldn't
> accept stuff like that, but Proton has a history of this.
> Proton already has a hack for this issue.
That hack is game specific, not enabled by default (as currently considered too dangerous and not that often needed). It is not enabled by MS Office of course. Maybe it can be, provided it works with Proton with the hack.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2378#note_86875
On Wed Nov 6 07:01:56 2024 +0000, Aida Jonikienė wrote:
> You should add a person to the reviewers list instead (but that requires
> developer access; you can request it with a button like "Request Access"
> in the Wine repository)
i cannot. No permission. Can you help me? thank you
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6770#note_86872
structuredquery is required to support AQS filters in Windows.Devices.Enumeration's `FindAllAsync` methods, and this stubs adds a basic set of stubs to get the ball rolling.
--
v6: dlls/structuredquery: Add stubs for QueryParser.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6788
> Proton hack won't be acceptable upstream
I learned that Wine and wine-staging doesn't like app-specific code. However, Proton has [a lot of app-specific workarounds](https://github.com/ValveSoftware/Proton/blob/1a73b04e6cdf29297…. Since Microsoft [famously](https://arstechnica.com/gadgets/2022/10/windows-95-went-the-extra… has app-specific workarounds (which Wine needs to emulate for full conformance), our own workaround for Microsoft Office wouldn't be much different on the technical side. On the social side, Wine wouldn't accept stuff like that, but Proton has a history of this.
> may ... behalf
In simpler words: It might take a long time before I finally get back to looking into this. This is because I don't need to use Microsoft Office right now. I need to dig up the folder I put all the files related to this work. I also need to call someone to make sure I'm still allowed to use the Microsoft Office license from my university. If the better solution from someone else becomes ready before I can look into this, then awesome! Otherwise, other people can pick up my work, build off of it, and send it somewhere where it would be accepted.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2378#note_86867
structuredquery is required to support AQS filters in Windows.Devices.Enumeration's `FindAllAsync` methods, and this stubs adds a basic set of stubs to get the ball rolling.
--
v4: dlls/structuredquery: Add stubs for QueryParser.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6788
structuredquery is required to support AQS filters in Windows.Devices.Enumeration's `FindAllAsync` methods, and this stubs adds a basic set of stubs to get the ball rolling.
--
v5: dlls/structuredquery: Add stubs for QueryParser.
dlls/structuredquery/tests: Add basic conformance tests for QueryParser.
dlls/structuredquery: Add stub.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6788
> I agree, so let's do s/wine-staging/Proton/g. I may greatly tarry before getting to it, so others should feel free to send the patch on my behalf.
I'm not exactly sure what you're trying to say here, but the Proton hack won't be acceptable upstream either.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2378#note_86858
structuredquery is required to support AQS filters in Windows.Devices.Enumeration's `FindAllAsync` methods, and this stubs adds a basic set of stubs to get the ball rolling.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6788
> app-specific
> wine-staging
I agree, so let's do s/wine-staging/Proton/g. I may greatly tarry before getting to it, so others should feel free to send the patch on my behalf.
> worked on by someone else
> you should
I welcome them superseding this patch with a proper fix, so I'm closing this MR. Interesting new IOCTL! As mentioned in https://gitlab.winehq.org/wine/wine/-/merge_requests/5522#note_86850 , my team obviated Office thus this patch the month after its submission.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2378#note_86854
> Adding a stub that doesn't actually help anything is basically just extra noise, and more code in the tree. In cases where someone is actively working on a proper implementation, it also often gets in their way. It may not be a big deal, but it's not exactly like there are zero disadvantages either.
Do you think the Waterfall development model could actually work better than Agile, especially in open source?
> author has probably given up on collaborating with the Wine project
Yeah, it was frustrating. But the reason was unrelated, being my team switching to Notion from Office. I also missed the email notifications. I'm not enthusiastic anymore about championing my patches, knowing I can always maintain a local patchset or submit them to Proton
> circumvention
Please don't accuse me of illegal behavior. I intentionally wrote `Sleep` not `TerminateThread`, which makes it a gray area, not necessarily illegal. The `Sleep` simulates a very inefficient algorithm (that Linux doesn't finish scheduling before heat death) on a busy computer, and I can replace it with a Collatz Conjecture verifier if you want. It's Microsoft's design decision that Office is "run until licensing fails" not "run after licensing succeeds" (which they chose if they cared), and Microsoft's code to change the title proves it's intentional
> patch-set fixing `v8jsi.dll`
That's my !2378 but I heard someone's working on a proper fix
> a private key ... cannot legally redistribute
No company publishes their [private key](https://en.wikipedia.org/w/index.php?title=Private_key)s. If we don't redistribute, we can adopt Switch emulators' key self-dumping requirement, and still be somewhat safe from their lawsuit's argument because Wine isn't mainly used for piracy
> where the license data is stored
I speculate it's in the registry like other licensing data
> first time contributors don't miss them.
Most other first time contributors can't read. It's better to be prepared to accept but fix their code
> licenses are encrypted
I didn't investigate how they are stored or if ciphertext can be directly returned. I don't want to be forced to investigate. My patch took an hour or two, and I'd hate to have to spend a week. This "proper implementation" requirement is going to make implementation cost months. The majority of potential contributors (like me) are only capable of small, incremental fixes
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5522#note_86850
On Tue Nov 5 06:18:28 2024 +0000, Zhiyi Zhang wrote:
> For Unicode notification conversions, you might want to take a look at
> 76f8ea75 and d7dcfe03.
<div><a target="_blank" href="https://gitlab.winehq.org/wine/wine/-/blob/6db2812411d45ca4b4d15dea9a00577e…"><code>pager.c</code>:<pre><code lang="c">static BOOL PAGER_AdjustBuffer(PAGER_INFO *infoPtr, INT size) { if (!infoPtr->pwszBuffer) infoPtr->pwszBuffer = Alloc(size); else if (infoPtr->nBufferSize < size) infoPtr->pwszBuffer = ReAlloc(infoPtr->pwszBuffer, size); if (!infoPtr->pwszBuffer) return FALSE; if (infoPtr->nBufferSize < size) infoPtr->nBufferSize = size; return TRUE; }</code></pre></a>Why is this function designed to leak old <code>infoPtr->pwszBuffer</code> when <code>ReAlloc(infoPtr->pwszBuffer, size)</code> returns <code>NULL</code>?</div>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6737#note_86848
The pointer in tmplocale gets freed in the second setlocale call.
Therefore ASan triggers when trying to restore the locale
the the already freed pointer in tmplocale in the third call to setlocale.
This appeared with a notepad.exe built with (a yet patched) llvm-mingw with ASan enabled,
when opening the Printer Setup dialog.
The stack traces seem to have utilized an in the wineprefix installed LLVM/llvm-symbolizer.exe.
```
wine64 notepad_asan.exe
=================================================================
==300==ERROR: AddressSanitizer: heap-use-after-free on address 0x7eeab5c60290 at pc 0x6ffffa80279f bp 0x7ffffe1fb570 sp 0x7ffffe1fb5b0
READ of size 2 at 0x7eeab5c60290 thread T0
0130:fixme:dbghelp:elf_search_auxv can't find symbol in module
#0 0x6ffffa80279e in strchr+0x28e (C:\x86_64\libclang_rt.asan_dynamic-x86_64.dll+0x18004279e)
#1 0x6ffffeb1666c in locale_to_sname Z:\home\bernhard\wine\dlls\msvcrt\locale.c:351
#2 0x6ffffeb16ce5 in create_locinfo Z:\home\bernhard\wine\dlls\msvcrt\locale.c:1357
#3 0x6ffffeb1a170 in setlocale Z:\home\bernhard\wine\dlls\msvcrt\locale.c:2054
#4 0x6ffffa1bf8c9 in PSDRV_ParsePPD Z:\home\bernhard\wine\dlls\wineps.drv\ppd.c:890
#5 0x6ffffa1bc0b7 in PSDRV_FindPrinterInfo Z:\home\bernhard\wine\dlls\wineps.drv\init.c:575
#6 0x6ffffa1b66b1 in DrvDocumentPropertySheets Z:\home\bernhard\wine\dlls\wineps.drv\driver.c:491
#7 0x6ffffc60b314 in DocumentPropertiesW Z:\home\bernhard\wine\dlls\winspool.drv\info.c:1854
#8 0x6ffffc611f97 in OpenPrinter2W Z:\home\bernhard\wine\dlls\winspool.drv\info.c:2057
#9 0x6ffffd666153 in PRINTDLG_ChangePrinterW Z:\home\bernhard\wine\dlls\comdlg32\printdlg.c:1298
#10 0x6ffffd66786d in PRINTDLG_WMInitDialogW Z:\home\bernhard\wine\dlls\comdlg32\printdlg.c:1660
#11 0x6ffffd667987 in PrintDlgProcW Z:\home\bernhard\wine\dlls\comdlg32\printdlg.c:2126
#12 0x6ffffdc08d48 in call_dialog_proc Z:\home\bernhard\wine\dlls\user32\winproc.c:129
#13 0x6ffffdc0b13b in WINPROC_CallDlgProcW Z:\home\bernhard\wine\dlls\user32\winproc.c:948
#14 0x6ffffdbcf528 in USER_DefDlgProc Z:\home\bernhard\wine\dlls\user32\defdlg.c:372
#15 0x6ffffdbcf7b4 in DefDlgProcW Z:\home\bernhard\wine\dlls\user32\defdlg.c:438
#16 0x6ffffdc08c2a in call_window_proc Z:\home\bernhard\wine\dlls\user32\winproc.c:108
#17 0x6ffffdc0ac43 in dispatch_win_proc_params Z:\home\bernhard\wine\dlls\user32\winproc.c:725
#18 0x6ffffdbf179c in dispatch_send_message Z:\home\bernhard\wine\dlls\user32\message.c:580
#19 0x6ffffdbf32ee in SendMessageW Z:\home\bernhard\wine\dlls\user32\message.c:599
#20 0x6ffffdbd2d1a in DIALOG_CreateIndirect Z:\home\bernhard\wine\dlls\user32\dialog.c:676
#21 0x6ffffdbd4d1c in DialogBoxIndirectParamW Z:\home\bernhard\wine\dlls\user32\dialog.c:899
#22 0x6ffffd6692a7 in PrintDlgW Z:\home\bernhard\wine\dlls\comdlg32\printdlg.c:2546
#23 0x000140007f9b in DIALOG_FilePrinterSetup Z:\home\bernhard\wine\programs\notepad\dialog.c:1019
#24 0x00014000e118 in NOTEPAD_WndProc Z:\home\bernhard\wine\programs\notepad\main.c:640
#25 0x6ffffdc08c2a in call_window_proc Z:\home\bernhard\wine\dlls\user32\winproc.c:108
#26 0x6ffffdc0ac43 in dispatch_win_proc_params Z:\home\bernhard\wine\dlls\user32\winproc.c:725
#27 0x6ffffdbf1850 in dispatch_message Z:\home\bernhard\wine\dlls\user32\message.c:854
#28 0x6ffffdbf3afc in DispatchMessageW Z:\home\bernhard\wine\dlls\user32\message.c:940
#29 0x00014000c4ef in WinMain Z:\home\bernhard\wine\programs\notepad\main.c:888
#30 0x00014000ea3e in main+0x20e (C:\x86_64\notepad.exe_asan.exe+0x14000ea3e)
#31 0x00014000e75a in mainCRTStartup Z:\home\bernhard\wine\dlls\msvcrt\crt_main.c:58
#32 0x6fffffa98d58 in BaseThreadInitThunk Z:\home\bernhard\wine\dlls\kernel32\thread.c:61
#33 0x6fffffc95afa (C:\windows\system32\ntdll.dll+0x170055afa)
0x7eeab5c60290 is located 0 bytes inside of 2-byte region [0x7eeab5c60290,0x7eeab5c60292)
freed by thread T0 here:
#0 0x6ffffa809ff1 in free+0x81 (C:\x86_64\libclang_rt.asan_dynamic-x86_64.dll+0x180049ff1)
#1 0x6ffffeb1563c in free_locinfo Z:\home\bernhard\wine\dlls\msvcrt\locale.c:1071
#2 0x6ffffeb1591a in update_thread_locale Z:\home\bernhard\wine\dlls\msvcrt\locale.c:611
#3 0x6ffffeb1a301 in setlocale Z:\home\bernhard\wine\dlls\msvcrt\locale.c:2085
#4 0x6ffffa1bf890 in PSDRV_ParsePPD Z:\home\bernhard\wine\dlls\wineps.drv\ppd.c:887
#5 0x6ffffa1bc0b7 in PSDRV_FindPrinterInfo Z:\home\bernhard\wine\dlls\wineps.drv\init.c:575
#6 0x6ffffa1b66b1 in DrvDocumentPropertySheets Z:\home\bernhard\wine\dlls\wineps.drv\driver.c:491
#7 0x6ffffc60b314 in DocumentPropertiesW Z:\home\bernhard\wine\dlls\winspool.drv\info.c:1854
#8 0x6ffffc611f97 in OpenPrinter2W Z:\home\bernhard\wine\dlls\winspool.drv\info.c:2057
#9 0x6ffffd666153 in PRINTDLG_ChangePrinterW Z:\home\bernhard\wine\dlls\comdlg32\printdlg.c:1298
#10 0x6ffffd66786d in PRINTDLG_WMInitDialogW Z:\home\bernhard\wine\dlls\comdlg32\printdlg.c:1660
#11 0x6ffffd667987 in PrintDlgProcW Z:\home\bernhard\wine\dlls\comdlg32\printdlg.c:2126
#12 0x6ffffdc08d48 in call_dialog_proc Z:\home\bernhard\wine\dlls\user32\winproc.c:129
#13 0x6ffffdc0b13b in WINPROC_CallDlgProcW Z:\home\bernhard\wine\dlls\user32\winproc.c:948
#14 0x6ffffdbcf528 in USER_DefDlgProc Z:\home\bernhard\wine\dlls\user32\defdlg.c:372
#15 0x6ffffdbcf7b4 in DefDlgProcW Z:\home\bernhard\wine\dlls\user32\defdlg.c:438
#16 0x6ffffdc08c2a in call_window_proc Z:\home\bernhard\wine\dlls\user32\winproc.c:108
#17 0x6ffffdc0ac43 in dispatch_win_proc_params Z:\home\bernhard\wine\dlls\user32\winproc.c:725
#18 0x6ffffdbf179c in dispatch_send_message Z:\home\bernhard\wine\dlls\user32\message.c:580
#19 0x6ffffdbf32ee in SendMessageW Z:\home\bernhard\wine\dlls\user32\message.c:599
#20 0x6ffffdbd2d1a in DIALOG_CreateIndirect Z:\home\bernhard\wine\dlls\user32\dialog.c:676
#21 0x6ffffdbd4d1c in DialogBoxIndirectParamW Z:\home\bernhard\wine\dlls\user32\dialog.c:899
#22 0x6ffffd6692a7 in PrintDlgW Z:\home\bernhard\wine\dlls\comdlg32\printdlg.c:2546
#23 0x000140007f9b in DIALOG_FilePrinterSetup Z:\home\bernhard\wine\programs\notepad\dialog.c:1019
#24 0x00014000e118 in NOTEPAD_WndProc Z:\home\bernhard\wine\programs\notepad\main.c:640
#25 0x6ffffdc08c2a in call_window_proc Z:\home\bernhard\wine\dlls\user32\winproc.c:108
#26 0x6ffffdc0ac43 in dispatch_win_proc_params Z:\home\bernhard\wine\dlls\user32\winproc.c:725
#27 0x6ffffdbf1850 in dispatch_message Z:\home\bernhard\wine\dlls\user32\message.c:854
previously allocated by thread T0 here:
#0 0x6ffffa80a111 in malloc+0x81 (C:\x86_64\libclang_rt.asan_dynamic-x86_64.dll+0x18004a111)
#1 0x6ffffeb154f9 in init_category_name Z:\home\bernhard\wine\dlls\msvcrt\locale.c:474
#2 0x6ffffeb18ad9 in create_locinfo Z:\home\bernhard\wine\dlls\msvcrt\locale.c:1930
#3 0x6ffffeb1a170 in setlocale Z:\home\bernhard\wine\dlls\msvcrt\locale.c:2054
#4 0x6ffffa1bf8c9 in PSDRV_ParsePPD Z:\home\bernhard\wine\dlls\wineps.drv\ppd.c:890
#5 0x6ffffa1bc0b7 in PSDRV_FindPrinterInfo Z:\home\bernhard\wine\dlls\wineps.drv\init.c:575
#6 0x6ffffa1b66b1 in DrvDocumentPropertySheets Z:\home\bernhard\wine\dlls\wineps.drv\driver.c:491
#7 0x6ffffc60b314 in DocumentPropertiesW Z:\home\bernhard\wine\dlls\winspool.drv\info.c:1854
#8 0x6ffffc611f97 in OpenPrinter2W Z:\home\bernhard\wine\dlls\winspool.drv\info.c:2057
#9 0x6ffffd666153 in PRINTDLG_ChangePrinterW Z:\home\bernhard\wine\dlls\comdlg32\printdlg.c:1298
#10 0x6ffffd66786d in PRINTDLG_WMInitDialogW Z:\home\bernhard\wine\dlls\comdlg32\printdlg.c:1660
#11 0x6ffffd667987 in PrintDlgProcW Z:\home\bernhard\wine\dlls\comdlg32\printdlg.c:2126
#12 0x6ffffdc08d48 in call_dialog_proc Z:\home\bernhard\wine\dlls\user32\winproc.c:129
#13 0x6ffffdc0b13b in WINPROC_CallDlgProcW Z:\home\bernhard\wine\dlls\user32\winproc.c:948
#14 0x6ffffdbcf528 in USER_DefDlgProc Z:\home\bernhard\wine\dlls\user32\defdlg.c:372
#15 0x6ffffdbcf7b4 in DefDlgProcW Z:\home\bernhard\wine\dlls\user32\defdlg.c:438
#16 0x6ffffdc08c2a in call_window_proc Z:\home\bernhard\wine\dlls\user32\winproc.c:108
#17 0x6ffffdc0ac43 in dispatch_win_proc_params Z:\home\bernhard\wine\dlls\user32\winproc.c:725
#18 0x6ffffdbf179c in dispatch_send_message Z:\home\bernhard\wine\dlls\user32\message.c:580
#19 0x6ffffdbf32ee in SendMessageW Z:\home\bernhard\wine\dlls\user32\message.c:599
#20 0x6ffffdbd2d1a in DIALOG_CreateIndirect Z:\home\bernhard\wine\dlls\user32\dialog.c:676
#21 0x6ffffdbd4d1c in DialogBoxIndirectParamW Z:\home\bernhard\wine\dlls\user32\dialog.c:899
#22 0x6ffffd6692a7 in PrintDlgW Z:\home\bernhard\wine\dlls\comdlg32\printdlg.c:2546
#23 0x000140007f9b in DIALOG_FilePrinterSetup Z:\home\bernhard\wine\programs\notepad\dialog.c:1019
#24 0x00014000e118 in NOTEPAD_WndProc Z:\home\bernhard\wine\programs\notepad\main.c:640
#25 0x6ffffdc08c2a in call_window_proc Z:\home\bernhard\wine\dlls\user32\winproc.c:108
#26 0x6ffffdc0ac43 in dispatch_win_proc_params Z:\home\bernhard\wine\dlls\user32\winproc.c:725
#27 0x6ffffdbf1850 in dispatch_message Z:\home\bernhard\wine\dlls\user32\message.c:854
SUMMARY: AddressSanitizer: heap-use-after-free Z:\home\bernhard\wine\dlls\msvcrt\locale.c:351 in locale_to_sname
Shadow bytes around the buggy address:
0x7eeab5c60000: fa fa 00 00 fa fa 00 06 fa fa 00 fa fa fa 00 00
0x7eeab5c60080: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
0x7eeab5c60100: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
0x7eeab5c60180: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
0x7eeab5c60200: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
=>0x7eeab5c60280: fa fa[fd]fa fa fa fd fa fa fa fd fa fa fa fd fa
0x7eeab5c60300: fa fa 02 fa fa fa 04 fa fa fa 02 fa fa fa 04 fa
0x7eeab5c60380: fa fa 02 fa fa fa 04 fa fa fa 02 fa fa fa 04 fa
0x7eeab5c60400: fa fa 02 fa fa fa 04 fa fa fa 00 fa fa fa fd fd
0x7eeab5c60480: fa fa fd fd fa fa fd fd fa fa fd fd fa fa fd fd
0x7eeab5c60500: fa fa fd fd fa fa fd fd fa fa fd fd fa fa fd fd
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==300==ABORTING
```
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6787
References held by contained stream objects must use an internal refcount, otherwise they prevent release of the media source if Start() and Shutdown() are not called.
--
v2: winegstreamer: Introduce an internal refcount in media source objects.
mfplat/tests: Test the refcount before the media source is released.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6783
References held by contained stream objects must use an internal refcount, otherwise they prevent release of the media source if Start() and Shutdown() are not called.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6783
Overwatch 2 verifies that every kernel callback that is run, lives in user32. Introduce a callback in user32 that just forwards to the other modules' callbacks.
--
v19: include: Add a comment explaining why all kernel callbacks must be in user32.
user32: Remove NtUserDriverCallback* kernel callbacks.
winex11.drv: Route kernel callbacks through user32.
winex11.drv: Pass a struct to x11drv_ime_set_result.
winex11.drv: Pass a struct to x11drv_dnd_post_drop.
winemac.drv: Route kernel callbacks through user32.
wineandroid.drv: Route kernel callbacks through user32.
opengl32: Route kernel callbacks through user32.
winevulkan: Route kernel callbacks through user32.
user32: Add NtUserDispatchCallback kernel callback.
user.exe16: Move kernel callbacks to wow_callbacks.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1180
wow64: Add TokenIntegrityLevel surpport to wow64_NtSetInformationToken as NtSetInformationToken does.
Description: synchronize wow64_NtSetInformationToken and
NtSetInformationToken.Avoid crash of some application due
to TokenIntegrityLevel failure in wow64 mode.
Signed-off-by: chenjiangyi <chenjiangyi(a)uniontech.com>
Change-Id: I556ab5cc6531dfab2c404e6769e053f42ada70a7
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5440
On macOS, valid syscall numbers all have a high bit set, leaving the low range "invalid" to be caught by SIGSYS.
On a Mac running macOS 14 or later, the test passes.
macOS 13 and earlier have a kernel bug which prevents SIGSYS from being delivered.
This patch was adapted from Apple's Game Porting Toolkit Wine patch, and from the 'ntdll-Syscall_Emulation' wine-staging patchset.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6777
Some FOURCC values such as 0xdeadbeef will en up being negative when cast to the
enum type, and may cause a random crash later on. This happens randomly in the
ddraw tests, depending on the compiler being used.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6698
Fixes Dark and Darker's Anti-Cheat "TavernWorker"; Original issue thread on Proton's repo [#2016590](https://github.com/ValveSoftware/Proton/issues/8208).
From the issue thread: Glaring issue seems to be the inability to load past the main menu in Dark and Darker without getting a pop-up that says "Tavern is not working! Please restart your game.", resulting in a forced exit.
I've marked this as Draft as I am not entirely sure returning the `NTSTATUS` of `NtWriteVirtualMemory` is the proper solution here (I have not found any other working solutions so-far). Returning the `NTSTATUS` of `NtQueryVirtualMemory` seems to not achieve working results, however I am not an expert by any means.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6761