[Bug 53217] New: d3d11:d3d11 - test_cube_maps() crashes in Wine
https://bugs.winehq.org/show_bug.cgi?id=53217 Bug ID: 53217 Summary: d3d11:d3d11 - test_cube_maps() crashes in Wine Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- d3d11:d3d11 - test_cube_maps() crashes in Wine: $ WINETEST_REPORT_SUCCESS=1 WINETEST_NO_MT_D3D=1 ./wine dlls/d3d11/tests/d3d11_test.exe d3d11 Unhandled exception: page fault on write access to 0x00000000 in 32-bit code (0x70baff74). [...] 0614:err:d3d:wined3d_debug_callback 00165DA0: "GL_OUT_OF_MEMORY in glMapBufferRange(map failed)". 0614:err:d3d:wined3d_allocator_chunk_gl_map Failed to map chunk memory. 0614:err:d3d:wined3d_bo_gl_map Failed to map chunk. 0614:err:d3d:wined3d_context_gl_map_bo_address Failed to map bo. Unhandled exception: page fault on write access to 0x00000000 in 32-bit code (0x70baff74). [...] Backtrace: =>0 0x70baff74 memset+0x24(dst=0x000000000, c=0, n=0x4b0000) [Z:\home\winetest\tools\testbot\var\wine\dlls\msvcrt\string.c:3150] in ucrtbase (0x020ef908) 1 0x715283e3 wined3d_texture_load_location+0x423(texture=0016C8C0, sub_resource_idx=0, context=0016D920, location=0x8) [Z:\home\winetest\tools\testbot\var\wine\dlls\wined3d\texture.c:853] in wined3d (0x020ef9a8) 2 0x715173ae surface_cpu_blt+0x9ee(dst_texture=0016C8C0, dst_sub_resource_idx=0, dst_box=020EFB38, src_texture=00171550, src_sub_resource_idx=0, src_box=020EFB50, flags=0x20000000, fx=020EFB68, filter=WINED3D_TEXF_POINT) [Z:\home\winetest\tools\testbot\var\wine\dlls\wined3d\surface.c:752] in wined3d (0x020efaf8) 3 0x71518ea2 cpu_blitter_blit+0xc2(blitter=0016E408, op=WINED3D_BLIT_OP_RAW_BLIT, context=0016D920, src_texture=00171550, src_sub_resource_idx=0, src_location=0x10, src_rect=020EFE10, dst_texture=0016C8C0, dst_sub_resource_idx=<is not available>, dst_location=0x8, dst_rect=020EFE20, color_key=00000000, filter=WINED3D_TEXF_POINT, resolve_format=00000000) [Z:\home\winetest\tools\testbot\var\wine\dlls\wined3d\surface.c:1328] in wined3d (0x020efb98) 4 0x715368a2 ffp_blitter_blit+0xa2(blitter=0016E420, op=WINED3D_BLIT_OP_RAW_BLIT, context=0016D920, src_texture=00171550, src_sub_resource_idx=0, src_location=0x10, src_rect=020EFE10, dst_texture=0016C8C0, dst_sub_resource_idx=0, dst_location=0x8, dst_rect=020EFE20, colour_key=00000000, filter=WINED3D_TEXF_POINT, resolve_format=00000000) [Z:\home\winetest\tools\testbot\var\wine\dlls\wined3d\texture.c:6213] in wined3d (0x020efc58) 5 0x714dc91d glsl_blitter_blit+0x1ad(blitter=0016E438, op=WINED3D_BLIT_OP_RAW_BLIT, context=0016D920, src_texture=00171550, src_sub_resource_idx=0, src_location=0x10, src_rect=020EFE10, dst_texture=0016C8C0, dst_sub_resource_idx=0, dst_location=0x8, dst_rect=020EFE20, colour_key=00000000, filter=WINED3D_TEXF_POINT, resolve_format=00000000) [Z:\home\winetest\tools\testbot\var\wine\dlls\wined3d\glsl_shader.c:13270] in wined3d (0x020efd78) 6 0x7151a181 texture2d_blt+0x3c1(dst_texture=0016C8C0, dst_sub_resource_idx=0, dst_box=013EFAC4, src_texture=00171550, src_sub_resource_idx=0, src_box=013EFAE4, flags=0x20000000, fx=013EFB00, filter=WINED3D_TEXF_POINT) [Z:\home\winetest\tools\testbot\var\wine\dlls\wined3d\surface.c:1639] in wined3d (0x020efe48) 7 0x7149b07d wined3d_cs_exec_blt_sub_resource+0xcd(cs=013E0020, data=013EFAB8) [Z:\home\winetest\tools\testbot\var\wine\dlls\wined3d\cs.c:2579] in wined3d (0x020efec8) 8 0x7149cb2b wined3d_cs_command_unlock(queue=<internal error>, cs=<internal error>) [Z:\home\winetest\tools\testbot\var\wine\dlls\wined3d\cs.c:3310] in wined3d (0x020eff28) 9 0x7149cb2b wined3d_cs_execute_next+0x53(queue=<internal error>, cs=<internal error>) [Z:\home\winetest\tools\testbot\var\wine\dlls\wined3d\cs.c:3309] in wined3d (0x020eff28) 10 0x7149cb2b wined3d_cs_run+0x11b(ctx=<internal error>) [Z:\home\winetest\tools\testbot\var\wine\dlls\wined3d\cs.c:3375] in wined3d (0x020eff28) 11 0x7b62a170 in kernel32 (+0x2a170) (0x020eff48) 12 0x7bc5a937 in ntdll (+0x5a937) (0x020eff5c) 13 0x7bc5aff0 RtlCreateUserThread(entry=7149CA10, arg=013E0020) [Z:\home\winetest\tools\testbot\var\wine\dlls\ntdll\thread.c:261] in ntdll (0x020effec) 0x70baff74 memset+0x24 [Z:\home\winetest\tools\testbot\var\wine\dlls\msvcrt\string.c:3150] in ucrtbase: movl %eax,0x0(%ebx) 3150 *(unaligned_ui64 *)(d + 0) = v; https://test.winehq.org/data/patterns.html#d3d11:d3d11 The crash happens with sub_resource_idx = 30. This impacts Debian 11 + QXL (the TestBot VMs), Intel (fg-deb64) and AMD RX460 (cw-rx460)... but only for 32-bit builds. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53217 François Gouget <fgouget(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source, testcase --- Comment #1 from François Gouget <fgouget(a)codeweavers.com> --- Also the crashes started on 2022-04-25 on the Debian 11 VMs, 2022-04-27 for the Debian Testing one, 2022-05-17 on cw-rx460 and 2022-05-18 on fg-deb64. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53217 --- Comment #2 from François Gouget <fgouget(a)codeweavers.com> --- There is a similar crash in d3d10core:d3d10core, presumably in the same location in test_cube_maps(). However it only happens on the TestBot's debian11 VM. Unhandled exception: page fault on write access to 0x00000000 in 32-bit code (0x70baff74). [...] Backtrace: =>0 0x70baff74 memset+0x24(dst=0x000000000, c=0, n=0x27100) [Z:\home\winetest\tools\testbot\var\wine\dlls\msvcrt\string.c:3150] in ucrtbase (0x01fcf908) 1 0x715283e3 wined3d_texture_load_location+0x423(texture=0016A3D8, sub_resource_idx=0, context=00180100, location=0x8) [Z:\home\winetest\tools\testbot\var\wine\dlls\wined3d\texture.c:853] in wined3d (0x01fcf9a8) 2 0x715173ae surface_cpu_blt+0x9ee(dst_texture=0016A3D8, dst_sub_resource_idx=0, dst_box=01FCFB38, src_texture=00183978, src_sub_resource_idx=0, src_box=01FCFB50, flags=0x20000000, fx=01FCFB68, filter=WINED3D_TEXF_POINT) [Z:\home\winetest\tools\testbot\var\wine\dlls\wined3d\surface.c:752] in wined3d (0x01fcfaf8) 3 0x71518ea2 cpu_blitter_blit+0xc2(blitter=0017C188, op=WINED3D_BLIT_OP_RAW_BLIT, context=00180100, src_texture=00183978, src_sub_resource_idx=0, src_location=0x10, src_rect=01FCFE10, dst_texture=0016A3D8, dst_sub_resource_idx=<is not available>, dst_location=0x8, dst_rect=01FCFE20, color_key=00000000, filter=WINED3D_TEXF_POINT, resolve_format=00000000) [Z:\home\winetest\tools\testbot\var\wine\dlls\wined3d\surface.c:1328] in wined3d (0x01fcfb98) 4 0x715368a2 ffp_blitter_blit+0xa2(blitter=00180978, op=WINED3D_BLIT_OP_RAW_BLIT, context=00180100, src_texture=00183978, src_sub_resource_idx=0, src_location=0x10, src_rect=01FCFE10, dst_texture=0016A3D8, dst_sub_resource_idx=0, dst_location=0x8, dst_rect=01FCFE20, colour_key=00000000, filter=WINED3D_TEXF_POINT, resolve_format=00000000) [Z:\home\winetest\tools\testbot\var\wine\dlls\wined3d\texture.c:6213] in wined3d (0x01fcfc58) 5 0x714dc91d glsl_blitter_blit+0x1ad(blitter=00180990, op=WINED3D_BLIT_OP_RAW_BLIT, context=00180100, src_texture=00183978, src_sub_resource_idx=0, src_location=0x10, src_rect=01FCFE10, dst_texture=0016A3D8, dst_sub_resource_idx=0, dst_location=0x8, dst_rect=01FCFE20, colour_key=00000000, filter=WINED3D_TEXF_POINT, resolve_format=00000000) [Z:\home\winetest\tools\testbot\var\wine\dlls\wined3d\glsl_shader.c:13270] in wined3d (0x01fcfd78) 6 0x7151a66f texture2d_blt+0x8af(dst_texture=0016A3D8, dst_sub_resource_idx=0, dst_box=0160B8F8, src_texture=00183978, src_sub_resource_idx=0, src_box=0160B918, flags=0x20000000, fx=0160B934, filter=WINED3D_TEXF_POINT) [Z:\home\winetest\tools\testbot\var\wine\dlls\wined3d\surface.c:1505] in wined3d (0x01fcfe48) 7 0x7149b07d wined3d_cs_exec_blt_sub_resource+0xcd(cs=015C0020, data=0160B8EC) [Z:\home\winetest\tools\testbot\var\wine\dlls\wined3d\cs.c:2579] in wined3d (0x01fcfec8) 8 0x7149cb2b wined3d_cs_command_unlock(queue=<internal error>, cs=<internal error>) [Z:\home\winetest\tools\testbot\var\wine\dlls\wined3d\cs.c:3310] in wined3d (0x01fcff28) 9 0x7149cb2b wined3d_cs_execute_next+0x53(queue=<internal error>, cs=<internal error>) [Z:\home\winetest\tools\testbot\var\wine\dlls\wined3d\cs.c:3309] in wined3d (0x01fcff28) 10 0x7149cb2b wined3d_cs_run+0x11b(ctx=<internal error>) [Z:\home\winetest\tools\testbot\var\wine\dlls\wined3d\cs.c:3375] in wined3d (0x01fcff28) 11 0x7b62a170 in kernel32 (+0x2a170) (0x01fcff48) 12 0x7bc5a937 in ntdll (+0x5a937) (0x01fcff5c) 13 0x7bc5aff0 RtlCreateUserThread(entry=7149CA10, arg=015C0020) [Z:\home\winetest\tools\testbot\var\wine\dlls\ntdll\thread.c:261] in ntdll (0x01fcffec) 0x70baff74 memset+0x24 [Z:\home\winetest\tools\testbot\var\wine\dlls\msvcrt\string.c:3150] in ucrtbase: movl %eax,0x0(%ebx) 3150 *(unaligned_ui64 *)(d + 0) = v; [...] -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53217 François Gouget <fgouget(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|d3d11:d3d11 - |d3d10core:d3d10core & |test_cube_maps() crashes in |d3d11:d3d11 - |Wine |test_cube_maps() crashes in | |Wine -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53217 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Fixed by SHA1| |97b836a938928ce714fd7cf430a | |97d5fbefd7df0 Resolution|--- |FIXED CC| |z.figura12(a)gmail.com --- Comment #3 from Zeb Figura <z.figura12(a)gmail.com> --- Should be addressed by <https://source.winehq.org/git/wine.git/commitdiff/97b836a938928ce714fd7cf430a97d5fbefd7df0>. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53217 François Gouget <fgouget(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED |--- Status|RESOLVED |REOPENED --- Comment #4 from François Gouget <fgouget(a)codeweavers.com> --- This patch did fix the crash in my Debian 11 VM (fgtb-debian11) and also in the GitLab environment (gitlab-debian). However this crash is still present on the TestBot's debian11 VM, and also in the wow32 tests running on the TestBot's debian11b VM. So there is still something going on. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53217 --- Comment #5 from Zeb Figura <z.figura12(a)gmail.com> --- debian11 no longer suffers from this, but gitlab still does. This is strange. The crash location is clearly a matter of out-of-memory, but the test is not exactly memory-hungry. It might be the most memory-hungry of all the d3d tests, but even then, it shouldn't use that much memory. I can VirtualAlloc() 3/8 of the available address space before running and it's still fine here. I'm reminded of bug 55283, which is also about us somewhat surprisingly running into memory limits in the gitlab CI (and nowhere else). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53217 François Gouget <fgouget(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|d3d10core:d3d10core & |d3d10core:d3d10core & |d3d11:d3d11 - |d3d11:d3d11 - |test_cube_maps() crashes in |test_cube_maps() crashes on |Wine |gitlab-debian-32 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53217 --- Comment #6 from Zeb Figura <z.figura12(a)gmail.com> --- (In reply to Zeb Figura from comment #5)
debian11 no longer suffers from this, but gitlab still does.
This is strange. The crash location is clearly a matter of out-of-memory, but the test is not exactly memory-hungry. It might be the most memory-hungry of all the d3d tests, but even then, it shouldn't use that much memory. I can VirtualAlloc() 3/8 of the available address space before running and it's still fine here.
I'm reminded of bug 55283, which is also about us somewhat surprisingly running into memory limits in the gitlab CI (and nowhere else).
I don't think that gitlab is crashing in this function precisely. Actually at least d3d11 seems to be crashing in test_resource_access(), but it may not be consistent. I've been trying to dump /proc/self/maps to see where all the space is being taken up. By analyzing the size of mapped ranges, I notice a lot more areas with mapped sizes of 0x800000, which I believe is the default pthread stack size. These aren't Wine threads; there's only three of those around at the time of the crash. On my local machine there are 25 pthreads; on gitlab there are a whole 65. So what are these pthreads? One thing I notice is that llvmpipe will, by default, spawn $(nproc) threads for rasterization. I have 12 CPUs on this machine; I don't know how many are on gitlab. But that's capped at 32, so that can't explain all of it. Something else in Mesa, perhaps? How many CPUs does the gitlab machine have? Anyone know the answer to that question? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53217 --- Comment #7 from Zeb Figura <z.figura12(a)gmail.com> --- (In reply to Zeb Figura from comment #6)
I've been trying to dump /proc/self/maps to see where all the space is being taken up. By analyzing the size of mapped ranges, I notice a lot more areas with mapped sizes of 0x800000, which I believe is the default pthread stack size. These aren't Wine threads; there's only three of those around at the time of the crash. On my local machine there are 25 pthreads; on gitlab there are a whole 65.
So what are these pthreads? One thing I notice is that llvmpipe will, by default, spawn $(nproc) threads for rasterization. I have 12 CPUs on this machine; I don't know how many are on gitlab. But that's capped at 32, so that can't explain all of it. Something else in Mesa, perhaps?
The other 12 pthreads are lp_cs_tpool_worker, which for some reason doesn't name itself. That number is calculated the same way, so I suspect the gitlab ci machine has at least 32 threads. So: * The upper address space, of course, is all blocked out. * llvmpipe creates 64 threads, each with the default stack size of 8 MB. That adds up to 512 MB. * mesa's threads all call free() first thing which triggers glibc to create a thread-specific heap. I'm not actually sure about how much memory this takes up but I *think* it's 64 MB. * 310 MB of shared libraries. (On my machine it's more). 121 MB of this is libLLVM-15, which, what the hell. The next worst offender is one *fourth* of that: libicudata at 31 MB. * wined3d chunk buffers seem to be taking up about 256 MB, mainly because the test manages to do a lot of memory allocation without hitting any of the points where wined3d would normally free unused memory. * About 230 more MB of anonymous memory that I don't immediately know how to account for. Possibly most of it is PE library .data, (and Unix library .bss?) that doesn't show up in /proc/self/maps. * 493 MB of unallocated address space that Wine has reserved. * Another 240 MB of address space that's free, but too fragmented to allocate another 64 MB wined3d chunk buffer. And there you have it! Out of address space! So here are some things we can do: (1) Limit the number of threads that we are using in CI. This is relatively easy; there's a LP_NUM_THREADS for this. (2) Mesa probably doesn't need 8 MB of stack for its threads. Get a change upstream to use less. (3) Reduce wined3d chunk buffer size for 32-bit programs, probably. (4) Try to submit fences more often so we don't allocate so many chunk buffers. (5) Mark Wine tests as large address aware? (6) Write, implement, and upstream a GL extension to allow controlling mapped buffer placement (which we need anyway, for new wow64). Use it even in old wow64 too, to forcibly allocate buffers into the low 2 GiB. Reserve the entire low 2 GiB, and stop reserving the upper 2 GiB. That'll alleviate some of the memory pressure from Unix libraries. (7) Investigate why the hell libllvm is so enormous. I cannot believe for a second that it needs all of that data loaded. Also, why is libicudata even being *loaded*? In practice, this is for unit tests, so we'll probably just turn down the thread count and call it a day. Or mark the tests as large address aware. One of those two things for sure. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53217 --- Comment #8 from Alexandre Julliard <julliard(a)winehq.org> --- (In reply to Zeb Figura from comment #6)
How many CPUs does the gitlab machine have? Anyone know the answer to that question?
The machine has 32 cores, but the gitlab-runner container should be limited to 16. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53217 --- Comment #9 from Zeb Figura <z.figura12(a)gmail.com> --- (In reply to Alexandre Julliard from comment #8)
(In reply to Zeb Figura from comment #6)
How many CPUs does the gitlab machine have? Anyone know the answer to that question?
The machine has 32 cores, but the gitlab-runner container should be limited to 16.
Is that 16 physical, or 16 logical? Or are all 32 visible to the program, but it's artificially limited to 16 somehow? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53217 --- Comment #10 from Zeb Figura <z.figura12(a)gmail.com> --- (In reply to Zeb Figura from comment #9)
(In reply to Alexandre Julliard from comment #8)
(In reply to Zeb Figura from comment #6)
How many CPUs does the gitlab machine have? Anyone know the answer to that question?
The machine has 32 cores, but the gitlab-runner container should be limited to 16.
Is that 16 physical, or 16 logical? Or are all 32 visible to the program, but it's artificially limited to 16 somehow?
Whatever it is, I checked by dumping thread names—llvmpipe still thinks there are at least 32 cores available. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53217 --- Comment #11 from François Gouget <fgouget(a)codeweavers.com> --- For reference, the TestBot's debian11 and debian11b VMs (where the 32-bit d3d11:d3d11 crashes) haev 16 'processors' (as advertised by /proc/cpuinfo) which are defined as 1 socket x 8 cores x 2 threads in Libvirt. However by the same measure debiant only has 8 'processors', defined as 1 socket x 8 cores x 1 threads in Libvirt and the 32-bit d3d11:d3d11 does not crash there. Finally the gpu1 / gpu2 hosts have 24 'processors', that is 8 performance-cores x 2 threads + 8 efficient-cores x 1 thread (i9-12900K) but I expect this to not leak into the VMs. I don't know how many threads llvmpipe creates in each case. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53217 Stefan Dösinger <stefan(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |stefan(a)codeweavers.com --- Comment #12 from Stefan Dösinger <stefan(a)codeweavers.com> --- d3d9:visual is affected too. To make things pass on Gitlab CI we could also mark the 32 bit builds of the d3d tests large address aware. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53217 --- Comment #13 from Stefan Dösinger <stefan(a)codeweavers.com> --- LAA is weird: https://gitlab.winehq.org/stefan/wine/-/merge_requests/5 Setting large address aware on d3d9_tests.exe does not seem to fix it (pipeline #13974), but patching ntdll to assume LAA is set (#13980) does make d3d9:visual run without crashes. I downloaded the built winetest.exe and extracted d3d9_test.exe from it, and it does have the flag set. It also has the flag set in a local build. Am I missing something? Are the tests somehow running in the address space of winetest.exe? In a first attempt I thought the built d3d9_test.exe did not have the flag set, indicating some build or caching issue, but if you download the artifacts of pipeline 13974 and check you'll see that the flag is properly set. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53217 --- Comment #14 from Zeb Figura <z.figura12(a)gmail.com> --- (In reply to Stefan Dösinger from comment #13)
LAA is weird: https://gitlab.winehq.org/stefan/wine/-/merge_requests/5
Setting large address aware on d3d9_tests.exe does not seem to fix it (pipeline #13974), but patching ntdll to assume LAA is set (#13980) does make d3d9:visual run without crashes. I downloaded the built winetest.exe and extracted d3d9_test.exe from it, and it does have the flag set. It also has the flag set in a local build.
Am I missing something? Are the tests somehow running in the address space of winetest.exe?
In a first attempt I thought the built d3d9_test.exe did not have the flag set, indicating some build or caching issue, but if you download the artifacts of pipeline 13974 and check you'll see that the flag is properly set.
I think that's just a quirk of the way the commits are set up. Modifying Makefile.in won't actually trigger a rebuild. CI will build everything after the first commit (to d3d11), but it won't rebuild d3d9 tests. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53217 --- Comment #15 from Stefan Dösinger <stefan(a)codeweavers.com> --- (In reply to Zeb Figura from comment #14)
I think that's just a quirk of the way the commits are set up. Modifying Makefile.in won't actually trigger a rebuild. CI will build everything after the first commit (to d3d11), but it won't rebuild d3d9 tests.
But the d3d9_test.exe file extracted from the build artifacts is marked large address aware. Or does gitlab somehow run an older version, rebuild and package a newer one? Should we just push the LAA flag in Makefile.in upstream and see what happens? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53217 --- Comment #16 from Zeb Figura <z.figura12(a)gmail.com> --- (In reply to Stefan Dösinger from comment #15)
(In reply to Zeb Figura from comment #14)
I think that's just a quirk of the way the commits are set up. Modifying Makefile.in won't actually trigger a rebuild. CI will build everything after the first commit (to d3d11), but it won't rebuild d3d9 tests.
But the d3d9_test.exe file extracted from the build artifacts is marked large address aware. Or does gitlab somehow run an older version, rebuild and package a newer one?
I'm not sure I can explain that, since the artifacts were culled anyway. Did you look at the 32-bit d3d9_test.exe or the 64-bit one? Did you look at the stripped version embedded in winetest.exe (which is the relevant version)?
Should we just push the LAA flag in Makefile.in upstream and see what happens?
I submitted 4155 upstream which sets it for all tests. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53217 --- Comment #17 from Stefan Dösinger <stefan(a)codeweavers.com> --- I extracted the .exe file from winetest.exe. I believe I looked at the 32 bit file, but I can't rule out that I didn't accidentally look at the 64 bit one. Let's see what your MR does :-) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53217 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Fixed by SHA1|97b836a938928ce714fd7cf430a |d9ad68a1ef1bb9288f5f39199a6 |97d5fbefd7df0 |042f013e6b464 Resolution|--- |FIXED --- Comment #18 from Zeb Figura <z.figura12(a)gmail.com> --- Addressed for now by <https://source.winehq.org/git/wine.git/commitdiff/d9ad68a1ef1bb9288f5f39199a6042f013e6b464>. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53217 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #19 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 8.20. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla