http://bugs.winehq.org/show_bug.cgi?id=11268
Summary: Civilization I for Windows (16-bt) incorrectly displays
some dialogues
Product: Wine
Version: 0.9.53.
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: gdi32
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: neptunia(a)mail.ru
Some dialogue windows in the game have non-rendered areas near window border
which display garbage/previous windows existed in this place.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
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=48167
Bug ID: 48167
Summary: 1000 Mots V4.0.2 freeze when 3 words are pronounced -
Underrun of data
Product: Wine
Version: 4.20
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: quartz
Assignee: wine-bugs(a)winehq.org
Reporter: sevmek(a)free.fr
Distribution: ---
Created attachment 65798
--> https://bugs.winehq.org/attachment.cgi?id=65798
wine 4.20 staging output
The software used is "1000 mots pour apprendre à lire" a french software
(shareware) for educational purpose (the title translate as "1000 words to
learn how to read").
One can download the software here:
https://app.educampa.fr/mil4_setup.exe
Version is 4.0.2
SHA1:
3213166282a8dc0fad236952f2dcb0650db199b3 mil4_setup.exe
It was tested against wine 4.20 (staging) on Fedora 31 and tested against wine
3.0 on ubuntu 18.04.
To install it require winetricks and gstreamer1-plugins-good.i686 (in fedora)
or gstreamer1.0-plugins-good:i386 (in ubuntu)
To install this software I use (in a clean and fresh ~/.wine directory):
$ env WINEARCH=win32 winetricks vb6run
$ wget https://app.educampa.fr/mil4_setup.exe
$ wine mil4_setup.exe
then I run using:
$ wine "c:\\educampa\\1000Mots_V4\\1000Mots_V4.exe"
Installation is OK.
when I use the software there is one activity that repeatedly freeze the
software whith an error like this:
00db:fixme:quartz:DSoundRender_UpdatePositions Underrun of data occurred!
(see attachment for full log)
In this activity, the software pronunce 3 following words. I suspect the issue
is there.
--
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=49944
Bug ID: 49944
Summary: Tom Clancy's Splinter Cell: Conviction fails to detect
audio device
Product: Wine
Version: 5.18
Hardware: x86-64
OS: Linux
Status: NEW
Severity: minor
Priority: P2
Component: wmi&wbemprox
Assignee: wine-bugs(a)winehq.org
Reporter: andrey.goosev(a)gmail.com
Distribution: ---
Created attachment 68335
--> https://bugs.winehq.org/attachment.cgi?id=68335
wbemprox
Stops launching with 'No audio device detected' message.
Workaround is rename systemdetection.dll in 'src/system' or disable wbemprox.
wine-5.18-161-gcce4f36e21
--
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=55662
Bug ID: 55662
Summary: Different behaviour of "set" command
Product: Wine
Version: 8.0.2
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: cmd
Assignee: wine-bugs(a)winehq.org
Reporter: ch.panel(a)free.fr
Distribution: ---
behavior of these commands are different in wine and windows in a batch file
set test=A
set /P test="type A or B (%test%) :"
echo "%test%"
pause
if the user type nothing the result is :
"A" on windows
"" on 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.
http://bugs.winehq.org/show_bug.cgi?id=32679
Bug #: 32679
Summary: cmd.exe Add support for || and &&
Product: Wine
Version: 1.5.21
Platform: x86
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: cmd
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: us(a)edmeades.me.uk
Classification: Unclassified
Add support to cmd.exe for the && and || functionality - They are currently
parsed and handled ok, but not correctly processed
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
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=55798
Bug ID: 55798
Summary: Unreal Engine 5.2: Wine minidumps take hours to load
into a debugger
Product: Wine
Version: 8.14
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: dbghelp
Assignee: wine-bugs(a)winehq.org
Reporter: aiden.deloryn(a)tensorworks.com.au
Distribution: ---
=== Overview ===
When attempting to load a Wine generated minidump from an Unreal Engine
application using a debugger (such as Visual Studio or VS Code), it takes a
number of hours for the file to load. If left uninterrupted during this time,
the process does eventually complete and all of the expected debug data becomes
visible within the IDE. This behaviour has only been observed for minidumps of
type MiniDumpNormal. When working with a Wine generated minidump of type
MiniDumpWithFullMemory, the debugger is able to load the file within a few
seconds.
=== Steps to Reproduce ===
1. Build this minimal sample application
https://github.com/TensorWorks/BuggyFirstPersonDemo.git on a Windows machine
with Unreal Engine 5.2.1 using the following command:
C:\<UE_INSTALL_DIR>\Engine\Build\BatchFiles\RunUAT.bat BuildCookRun -utf8output
-clientconfig=DebugGame
-project="C:\<PATH_TO_PROJECT_DIR>\BuggyFirstPersonDemo.uproject" -noP4 -cook
-build -stage -prereqs -pak -archive
-archivedirectory="C:\<PATH_TO_PROJECT_DIR>\GameBuilds" -platform=Win64
2. Copy the build directory (C:\<PATH_TO_PROJECT_DIR>\GameBuilds) to a Linux
machine and run the application using Wine (DXVK required):
wine
./GameBuilds/Windows/BuggyFirstPersonDemo/Binaries/Win64/BuggyFirstPersonDemo-Win64-DebugGame.exe
-windowed -ResX=800 -ResY=600
3. Trigger a crash by picking up the gun and shooting the large white cube.
Note: hold down the right mouse button to aim/look, and press the left mouse
button to shoot.
4. Copy the crash dump from
./GameBuilds/Windows/BuggyFirstPersonDemo/Saved/Crashes/<CRASH_ID>/UEMinidump.dmp
to a Windows machine and attempt to load it using Visual Studio or VS Code (for
VS Code you will need the C/C++ extension from Microsoft installed).
=== Actual Results ===
The minidump takes hours to load into Visual Studio and VS Code.
MemoryListStream contains over 950,000 memory ranges (see additional
information below).
=== Expected Results ===
The minidump takes less than a minute to load into Visual Studio and VS Code,
which is true for full memory minidumps generated under Wine and any minidump
generated under Windows.
=== Build Date & Hardware ===
wine-8.14 on Ubuntu 22.04.3 LTS x86-64
=== Additional Builds and Platforms ===
Also reproducible on wine-8.17 and wine-8.0.2
=== Additional Information ===
When analysing and comparing minidumps generated under Wine versus those
generated under Windows using the Microsoft Crash Dump File Checker tool
“DumpChk”
(https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/dumpchk),
a significant discrepancy can be observed in the normal minidump generated
under Wine. In particular, the number of memory ranges in MemoryListStream is
substantially higher, as can be seen in the excerpts below. Note that full
memory minidumps have also been included from both Windows and Wine for
additional context and comparison.
Windows - MiniDumpNormal:
Stream 3: type MemoryListStream (5), size 00000804, RVA 0006FF09
128 memory ranges
[OMITTED]
Total memory: 463cc
Wine - MiniDumpNormal:
Stream 4: type MemoryListStream (5), size 00EA0FF4, RVA 0002986B
958719 memory ranges
[OMITTED]
Total memory: 15bd62e
Windows - MiniDumpWithFullMemory:
Stream 5: type Memory64ListStream (9), size 0000EAC0, RVA 000C8D45
3755 memory ranges
[OMITTED]
Total memory: a74c1000
Wine - MiniDumpWithFullMemory:
Stream 7: type Memory64ListStream (9), size 0000E260, RVA 0006ADFB
3621 memory ranges
[OMITTED]
Total memory: 7ab14000
Note: You can generate a full memory minidump using the provided sample
application by specifying the -fullcrashdumpalways flag. For example:
wine
./GameBuilds/Windows/BuggyFirstPersonDemo/Binaries/Win64/BuggyFirstPersonDemo-Win64-DebugGame.exe
-windowed -ResX=800 -ResY=600 -fullcrashdumpalways
--
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=48525
Bug ID: 48525
Summary: 0009:err:gdi:alloc_gdi_handle out of GDI object
handles, expect a crash
Product: Wine
Version: 4.0.2
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gdiplus
Assignee: wine-bugs(a)winehq.org
Reporter: cagnulein(a)gmail.com
Distribution: ---
On a commercial application written on .NET 2.0 i have a crash that occurs
randomly every few days.
I put the +seh debug here. I have 2 questions:
1) my +seh log file is full of
0048:trace:seh:__regs_RtlUnwind handler at 0x7bc82da0 returned 1
0048:trace:seh:raise_exception code=40010006 flags=0 addr=0x7b43e223
ip=7b43e223 tid=0048
0048:trace:seh:raise_exception info[0]=00000041
0048:trace:seh:raise_exception info[1]=0d061dd8
0048:trace:seh:raise_exception eax=7b42a5c1 ebx=00000004 ecx=0733ef20
edx=0733efd0 esi=00000041 edi=40010006
0048:trace:seh:raise_exception ebp=0733ef78 esp=0733eef4 cs=300023 ds=002b
es=f7d7002b fs=006b gs=73c0063 flags=00000212
0048:trace:seh:call_stack_handlers calling handler at 0x7b48ad80 code=40010006
flags=0
0048:trace:seh:__regs_RtlUnwind code=40010006 flags=2
0048:trace:seh:__regs_RtlUnwind eax=00000000 ebx=7b48ace0 ecx=0733ef0c
edx=0733efd8 esi=0733efd8 edi=7b48ace0
0048:trace:seh:__regs_RtlUnwind ebp=0733eac8 esp=0733eaa8 eip=7b48ad3d cs=0023
ds=002b fs=006b gs=0063 flags=00000202
0048:trace:seh:__regs_RtlUnwind calling handler at 0x7bc82da0 code=40010006
flags=2
it's a problem of my application? Of wine gdiplus implementation?
2) In the meanwhile i'm trying with "winetricks gdiplus": what you think about
this +seh trace?
0048:trace:seh:call_stack_handlers calling handler at 0x7b48ad80 code=40010006
flags=0
0048:trace:seh:__regs_RtlUnwind code=40010006 flags=2
0048:trace:seh:__regs_RtlUnwind eax=00000000 ebx=7b48ace0 ecx=0733ef0c
edx=0733efd8 esi=0733efd8 edi=7b48ace0
0048:trace:seh:__regs_RtlUnwind ebp=0733eac8 esp=0733eaa8 eip=7b48ad3d cs=0023
ds=002b fs=006b gs=0063 flags=00000202
0048:trace:seh:__regs_RtlUnwind calling handler at 0x7bc82da0 code=40010006
flags=2
0048:trace:seh:__regs_RtlUnwind handler at 0x7bc82da0 returned 1
0048:trace:seh:raise_exception code=40010006 flags=0 addr=0x7b43e223
ip=7b43e223 tid=0048
0048:trace:seh:raise_exception info[0]=00000041
0048:trace:seh:raise_exception info[1]=0d061dd8
0048:trace:seh:raise_exception eax=7b42a5c1 ebx=00000004 ecx=0733ef20
edx=0733efd0 esi=00000041 edi=40010006
0048:trace:seh:raise_exception ebp=0733ef78 esp=0733eef4 cs=300023 ds=002b
es=f7d7002b fs=006b gs=73c0063 flags=00000212
0048:trace:seh:call_stack_handlers calling handler at 0x7b48ad80 code=40010006
flags=0
0048:trace:seh:__regs_RtlUnwind code=40010006 flags=2
0048:trace:seh:__regs_RtlUnwind eax=00000000 ebx=7b48ace0 ecx=0733ef0c
edx=0733efd8 esi=0733efd8 edi=7b48ace0
0048:trace:seh:__regs_RtlUnwind ebp=0733eac8 esp=0733eaa8 eip=7b48ad3d cs=0023
ds=002b fs=006b gs=0063 flags=00000202
0048:trace:seh:__regs_RtlUnwind calling handler at 0x7bc82da0 code=40010006
flags=2
0048:trace:seh:__regs_RtlUnwind handler at 0x7bc82da0 returned 1
0048:trace:seh:raise_exception code=40010006 flags=0 addr=0x7b43e223
ip=7b43e223 tid=0048
0048:trace:seh:raise_exception info[0]=0000003e
0048:trace:seh:raise_exception info[1]=0d0719e8
0048:trace:seh:raise_exception eax=7b42a5c1 ebx=00000004 ecx=0733ef50
edx=0733f000 esi=0000003e edi=40010006
0048:trace:seh:raise_exception ebp=0733efa8 esp=0733ef24 cs=0023 ds=34002b
es=733002b fs=7dd9006b gs=7330063 flags=00000216
0048:trace:seh:call_stack_handlers calling handler at 0x7b48ad80 code=40010006
flags=0
0048:trace:seh:__regs_RtlUnwind code=40010006 flags=2
0048:trace:seh:__regs_RtlUnwind eax=00000000 ebx=7b48ace0 ecx=0733ef3c
edx=0733f008 esi=0733f008 edi=7b48ace0
0048:trace:seh:__regs_RtlUnwind ebp=0733eaf8 esp=0733ead8 eip=7b48ad3d cs=0023
ds=002b fs=006b gs=0063 flags=00000202
0048:trace:seh:__regs_RtlUnwind calling handler at 0x7bc82da0 code=40010006
flags=2
0048:trace:seh:__regs_RtlUnwind handler at 0x7bc82da0 returned 1
0009:trace:seh:raise_exception code=40010006 flags=0 addr=0x7b43e223
ip=7b43e223 tid=0009
0009:trace:seh:raise_exception info[0]=00000046
0009:trace:seh:raise_exception info[1]=0d068440
0009:trace:seh:raise_exception eax=7b42a5c1 ebx=00000004 ecx=0032e720
edx=0032e7d0 esi=00000046 edi=40010006
0009:trace:seh:raise_exception ebp=0032e778 esp=0032e6f4 cs=0023 ds=34002b
es=002b fs=006b gs=0063 flags=00000212
0009:trace:seh:call_stack_handlers calling handler at 0x7b48ad80 code=40010006
flags=0
0009:trace:seh:__regs_RtlUnwind code=40010006 flags=2
0009:trace:seh:__regs_RtlUnwind eax=00000000 ebx=7b48ace0 ecx=0032e70c
edx=0032e7d8 esi=0032e7d8 edi=7b48ace0
0009:trace:seh:__regs_RtlUnwind ebp=0032e2c8 esp=0032e2a8 eip=7b48ad3d cs=0023
ds=002b fs=006b gs=0063 flags=00000202
0009:trace:seh:__regs_RtlUnwind calling handler at 0x7bc82da0 code=40010006
flags=2
0009:trace:seh:__regs_RtlUnwind handler at 0x7bc82da0 returned 1
0009:err:gdi:alloc_gdi_handle out of GDI object handles, expect a crash
Fatal,Program[1:MainThread]: System.Runtime.InteropServices.SEHException:
External component has thrown an exception.
at System.Drawing.SafeNativeMethods.SelectObject(HandleRef hdc, HandleRef
obj)
at System.Drawing.BufferedGraphicsContext.DisposeDC()
at System.Drawing.BufferedGraphicsContext.ReleaseBuffer(BufferedGraphics
buffer)
at System.Drawing.BufferedGraphics.Dispose(Boolean disposing)
at System.Drawing.BufferedGraphics.Dispose()
at System.Windows.Forms.Control.WmPaint(Message& m)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.Label.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr
wparam, IntPtr lparam)
I can't share the application because it's not free, but if you need more
information i will try to get them.
Thanks in advance
--
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=55818
Bug ID: 55818
Summary: 32-bit game Dark Age of Camelot slow memory leak leads
to crash since WINE 7.4
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: d3d
Assignee: wine-bugs(a)winehq.org
Reporter: tmwine(a)pertho.net
Distribution: ---
I've bisected a bug relating to a possible memory leak in wined3d. I've been
playing an old game (Dark Age of Camelot) for years now on free servers, but I
noticed there is a slow memory leak as it runs. I ran 'top' and watched the RES
memory creep up to 1.0 GB and then hit about 1.2-1.3 GB before the game
crashes.
On WINE 8 this issue seems to persist as well. So I went back and bisected the
bug and it occurs between WINE 7.3 and 7.4. In 7.3, I don't get the memory leak
and the game plays for hours, but in 7.4 I get the memory leak.
I've narrowed it down to this commit:
https://gitlab.winehq.org/wine/wine/-/commit/ee12556960e30fc22f276d2de2833e…
It might have to do with the code change in the function
wined3d_context_gl_destroy_bo that introduced this.
Happy to try any patches to test with against latest WINE 8.x tree.
Thanks,
Tom
--
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=56269
Bug ID: 56269
Summary: Systray icons do not scale based on Cinnamon settings
Product: Wine
Version: 9.0-rc1
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: bq74stlxvkpb(a)opayq.com
Distribution: ---
Created attachment 75987
--> https://bugs.winehq.org/attachment.cgi?id=75987
Systray icons do not scale based on Cinnamon settings
As the summary says. Open the attachment and guess which two systray icons do
not scale with the taskbar height.
By the way, the scaling size for all elements is set at 100% (so this isn't
about DPI scaling and such).
I do realize that .ico files are used, and those have several predefined sizes
inside, but a nearest neighbour scaling to the size of other icons would help a
lot and it would look a lot less silly.
NAME="Linux Mint"
VERSION="21.3 (Virginia)"
ID=linuxmint
ID_LIKE="ubuntu debian"
PRETTY_NAME="Linux Mint 21.3"
VERSION_ID="21.3"
HOME_URL="https://www.linuxmint.com/"
SUPPORT_URL="https://forums.linuxmint.com/"
BUG_REPORT_URL="http://linuxmint-troubleshooting-guide.readthedocs.io/en/latest/"
PRIVACY_POLICY_URL="https://www.linuxmint.com/"
VERSION_CODENAME=virginia
UBUNTU_CODENAME=jammy
--
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.