October 2022 - Wine-Devel - list.winehq.org

Re: Winelib stack overflow

by David Kahurani

On Sun, Oct 9, 2022 at 12:03 PM Vitor Ramos <ramos.v89(a)gmail.com> wrote: > > Hello, > > I am not sure if this is the appropriate channel but here we go. The right channel for bugs is to report them at https://bugs.winehq.org/ ... > > I am trying to port a windows c++ application using winelib and I found an issue while using some c++ STL containers. > > Here is a minimal example: > > # winelib.dll.so > > ```c++ > #include <windows.h> > #include <unordered_map> > #include <string> > > extern "C" > int f1(long z) > { > std::unordered_map<int, std::string> y; > return 10; > } > > spec file > ```c++ > 2 stdcall f1(long) > ``` > > # Building winelib.dll.so > winemaker --console --dll . > winebuild --implib -E winedll.spec -o libwinedll.a > winebuild --fake-module --dll -E winedll.spec -o winedll.dll > make > > cp libwinedll.a winedll.dll.so /usr/local/lib/wine/x86_64-unix > cp winedll.dll /home/$USER/.wine/drive_c/windows/system32 > > win64 app > ```c++ > #include <iostream> > > extern "C"{ > int f1(long z); > } > > int main(){ > int ret = f1(2); > std::cout << ret << std::endl; > } > ``` > > # Building win64 app > winemaker . -iwinedll > make > > # Running > wine64 win64app.exe.so > > # Output > 0110:err:virtual:virtual_setup_exception stack overflow 2128 bytes in thread 0110 addr 0x17008c804 stack 0x207b0 (0x20000-0x21000-0x120000) I see this error every once in a while and most of the time it doesn't seem to affect the working of the program. Does it affect the working of your program in this particular case? > > If I remove the "std::unordered_map<int, std::string> y" from the custom lib it runs normally. > > I suspect that wine uses too much of the stack to construct the object, but it's just a wild guess. > > Does anybody know what the issue could be? > Is it possible to increase the stack size? > > Thanks. > >

Oct. 12, 2022

Re: TestBot News

by Francois Gouget

Since last Wednesday the TestBot has been running the full 32-bit Wine test suite on every patch on Linux. What made this possible are these couple of patches: commit 290f9e17ce7e375ac3dee55d43b4915fa58539fe Author: Francois Gouget <fgouget(a)codeweavers.com> AuthorDate: Tue Oct 30 14:08:39 2018 +0100 testbot: Specify which test units to rerun with the 'test' mission option. If set to 'all', then any non-test patch will cause a full WineTest run. If set to 'module', then only the patched module's tests will be run. If set to 'test' or unset, then the current behavior is preserved so that only patched test units are run. If set to 'build', then only verify that the patch builds. Signed-off-by: Francois Gouget <fgouget(a)codeweavers.com> Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> And the known failure tracking to avoid false positives: commit 1b238d27711cf9b62fb5f304d19610c0472c7b05 Author: Francois Gouget <fgouget(a)codeweavers.com> Date: Wed Jun 15 18:21:35 2022 +0200 testbot: Match the failures with the test logs. This augments the .errors files with information mapping errors to known failures. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=48912 Signed-off-by: Francois Gouget <fgouget(a)codeweavers.com> Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> Getting new hardware also helped limit the performance impact a bit. -- Francois Gouget <fgouget(a)codeweavers.com>

Oct. 10, 2022

Winelib stack overflow

by Vitor Ramos

Hello, I am not sure if this is the appropriate channel but here we go. I am trying to port a windows c++ application using winelib and I found an issue while using some c++ STL containers. Here is a minimal example: # winelib.dll.so ```c++ #include <windows.h> #include <unordered_map> #include <string> extern "C" int f1(long z) { std::unordered_map<int, std::string> y; return 10; } spec file ```c++ 2 stdcall f1(long) ``` # Building winelib.dll.so winemaker --console --dll . winebuild --implib -E winedll.spec -o libwinedll.a winebuild --fake-module --dll -E winedll.spec -o winedll.dll make cp libwinedll.a winedll.dll.so /usr/local/lib/wine/x86_64-unix cp winedll.dll /home/$USER/.wine/drive_c/windows/system32 win64 app ```c++ #include <iostream> extern "C"{ int f1(long z); } int main(){ int ret = f1(2); std::cout << ret << std::endl; } ``` # Building win64 app winemaker . -iwinedll make # Running wine64 win64app.exe.so # Output 0110:err:virtual:virtual_setup_exception stack overflow 2128 bytes in thread 0110 addr 0x17008c804 stack 0x207b0 (0x20000-0x21000-0x120000) If I remove the "std::unordered_map<int, std::string> y" from the custom lib it runs normally. I suspect that wine uses too much of the stack to construct the object, but it's just a wild guess. Does anybody know what the issue could be? Is it possible to increase the stack size? Thanks.

Oct. 9, 2022

TestBot News

by Francois Gouget

* The TestBot has a new Windows 11 VM. It's a new Windows version so it has almost 40 extra failures. To avoid false positives it's only going to be running WineTest until the new failures have been flagged. But you can already select it in the list of available VMs to run tests on it. * There are now two PCI-Passthrough configurations: - w11pro64_amd -> AMD RX6600 GPU - w11pro64_nv -> NVIDIA RTX3050 GPU These have a surprising number of extra failures, about 12, when fgtb-w10pro64-rx550 only has about 2 extra failures. So I will recheck the configuration of the new VMs (on the AMD side it may have the clipboard problem again, but then a number of failures appeared to be in the d3d tests). These are also only running WineTest for now so as to not cause false positives but you can select them in the list of available VMs. -- Francois Gouget <fgouget(a)codeweavers.com>

Oct. 5, 2022

Re: [PATCH 2/2] strmbase: Reset the renderer's state event when flushing.

by Zebediah Figura

On 9/26/22 08:06, Gabriel Ivăncescu wrote: > On 16/11/2020 23:07, Zebediah Figura (she/her) wrote: >> On 11/3/20 6:43 AM, Gabriel Ivăncescu wrote: >>> On 02/11/2020 20:11, Zebediah Figura wrote: >>>> This patch isn't wrong per se, but it's less pretty than it could be, >>>> and exposes some of the still-present problems with renderer locking. >>>> Sorry, I'll need more than a little time to review this. >>>> >>> >>> Understood. Only thing is that I won't be able to send a new version of >>> the media detector patches until then, though, because it depends on it. >>> (that is why I haven't) >>> >> >> For the sake of transparency, the basic problem is that this patch >> treats "filter->sink.flushing" as protected by "csRenderLock", when in >> fact it's not. The lock taken in sink_begin_flush() *does* prevent the >> race you describe, but it does so in a very non-obvious way. I'm >> currently working on restructuring some things so that "flushing" is >> protected by a lock which we can safely take from the streaming thread, >> but it may take a while (and may not make it in by code freeze). >> > > Hi Zeb, > > Sorry if this is already done, but I was going through some of my stuff, > it seems I still need this patch to have those tests work (and > subsequently the other things in qedit). I've no idea how hard this > would be to restructure properly, so maybe it's already in progress or > done in some way, but if not it's probably just a reminder. > > Or if there's a better way now to fix it then please let me know. Hi Gabriel, Sorry for the lack of response. I haven't had time to actually work on this in a long time. I'd like to get back to it but I don't know when that will happen. I don't remember if I even have in-progress patches, but I think most of the difficulty has been in the design. ἔρρωσο, Zeb

Oct. 4, 2022