https://bugs.winehq.org/show_bug.cgi?id=40574
Bug ID: 40574
Summary: bbtalk.exe wont start
Product: Wine
Version: 1.9.9
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: eore26(a)gmail.com
Distribution: ---
Created attachment 54413
--> https://bugs.winehq.org/attachment.cgi?id=54413
Program error detail
Unhandled Exception
--
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=41919
Bug ID: 41919
Summary: Regression : impossible to finish installation of
Indiana Jones The Original Trilogy
Product: Wine
Version: 1.9.24
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: fevrier.simon(a)gmail.com
Distribution: Ubuntu
Ubuntu 16.10
It seems the regression appear between Wine 1.7.18 and 1.7.29.
Normally, no problem
Regression : a pop up window say "Insert the disk : 1" but the disk is inserted
Nothing different between versions in the poor logs.
The regression page say to test with the latest code. I will try but I don't
think it will be useful. For a "git bisect" method : too expensive for my
computer, but I will try to have a look at the commits' information.
It doesn't work In wine 1.9.24.
--
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=47801
Bug ID: 47801
Summary: Growing build/wine VM disk usage
Product: Wine-Testbot
Version: unspecified
Hardware: x86
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: unknown
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
Created attachment 65291
--> https://bugs.winehq.org/attachment.cgi?id=65291
Evolution of wtbdebian10's revert times
Every time we update and rebuild Wine in these VMs the VM's qcow2 file grows.
The Wine VMs are those where the disk grows fastest, from ~5 GB to 60+ GB in a
matter of weeks. Fortunately it does seem to grow slower after a while.
For instance <6 GB to 32 GB (du) from 2019-09-20 to 2019-09-25 for wtbdebian10.
This may be caused by the way WineRunReconfig handles live snapshots. To
summarize:
* Restore to the current live snapshot.
* Update and rebuild Wine.
* Iff that succeeded, delete the live snapshot and recreate it.
This may cause QEmu to not realize that all the data from the now deleted old
live snapshot can be reclaimed and reused for the next Wine build. But we had
to delete the live snapshot at the last minute because losing it would mean the
VM would be unusable until the TestBot administrator could come and fix it.
However nowadays the TestBot can recreate live snapshots from powered off
snapshots. This means we could delete the live snapshot first, rebuild and
recreate the snapshot at the end. In the unlikely event that something goes
wrong the live snapshot could be recreated from the powered off 'base'...
except in the case of a build error. That case would be unrecoverable unlike in
the current scheme.
A test with this alternative snapshot management should be made to see if it
does actually make a difference in the qcow2 growth (there's really no
guarantee it does).
For these VMs the revert time does seem to degrade a bit with time(*). This may
be related to the qcow2 size and/or accumulation of "phantom snapshots". So the
experiment should be run for a while to see if it makes a difference on this
metric too.
(*) See the Munin graph of wtbdebian10's revert time. The drop in week 38 and
39 correspond to maintenance on the VM where all snapshots were deleted and
virt-sparsify run on its disk.
--
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=48787
Bug ID: 48787
Summary: WineD3D C&C Generals Zero Hour takes a lot time to
load or maximize
Product: vkd3d
Version: 1.1
Hardware: x86-64
OS: Windows
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: vkd3d
Assignee: wine-bugs(a)winehq.org
Reporter: moceap(a)hotmail.com
As you know (C&C Generals Zero Hour) is an old game. And it use DirectX 8.1.
These type of games don't stable in current Windows' versions.
So WineD3D used to valid run them on Windows.
Using: C&C Generals Zero Hour (Last Version 1.04)
Windows 10 (1909)
WineD3D (From Wine 5.4)https://fdossena.com/?p=wined3d/index.frag
Both (Intel and AMD) cards tested
Expected Result: Works fine with high speed.
Actual Result: Very long time on maximize the game after minimize or switch to
another application
Long time on loading the game (Not happen on MS DirectX)
--
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=49666
Bug ID: 49666
Summary: Red Dead Redemption 2 requires HEAP flags offset to
match Windows
Product: Wine
Version: 5.14
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ntdll
Assignee: wine-bugs(a)winehq.org
Reporter: bshanks(a)codeweavers.com
Distribution: ---
Red Dead Redemption 2 gets ProcessHeap from the PEB, and directly accesses the
'flags' and 'force_flags' fields of the HEAP structure.
Those fields need to be at the same offset as they are on WinVista through
current Win10, 0x40/0x70.
Wine currently pads the struct so 'flags' is in the correct place (0xC) vs.
WinNT/2000/XP
https://ctf-wiki.github.io/ctf-wiki/reverse/windows/anti-debug/heap-flags/
--
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=49656
Bug ID: 49656
Summary: SAP GUI - Ws2_32.getaddrinfo crashes with non-standard
service (/etc/services)
Product: Wine
Version: 5.14
Hardware: x86
OS: Mac OS X
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winsock
Assignee: wine-bugs(a)winehq.org
Reporter: guimaeda(a)gmail.com
Created attachment 67890
--> https://bugs.winehq.org/attachment.cgi?id=67890
Terminal output (both success and crash)
Calling getaddrinfo with pNodeName = NULL and a non-standard pServiceName that
is not present in /etc/services causes an Unhandled page fault.
I noticed this issue using SAP GUI, a Windows client for a corporate ERP system
that uses unusual TCP ports for some of its connections to servers.
These port numbers are registered in %WINDIR%\system32\drivers\etc\services
during installation, and after going through some traces I noticed the error
stopped after adding the same entries to the host's (macOS) /etc/services file.
Since SAP GUI is licensed software, I created a little C program that simulates
the same problem.
It simply calls getaddrinfo with a service name "I_dont_exist".
If this entry is not present in /etc/services, the program crashes.
Tested on Wine 5.14 upstream binaries downloaded from PlayOnLinux/Phoenicis
Wine building service.
I also tested in other Wine version I use, namely 5.14-staging, 5.0 (WineHQ
Homebrew), 5.7-staging (WineHQ Homebrew) and CrossOver 19.0.1. All had the same
result.
Sample C program with .exe and source code:
https://abap.ninja/bugreport/wine_getaddrinfo_crash.zip
--
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=46726
Bug ID: 46726
Summary: Dirt Rally 2.0 does not use embedded CA cert
Product: Wine
Version: 4.2
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: crypt32
Assignee: wine-bugs(a)winehq.org
Reporter: andreas(a)heider.io
Distribution: ---
Hi,
Dirt Rally 2.0 requires an online connection to play the single player
campaign, but with Wine 4.2 it can't successfully establish that connection due
to a certificate issue.
It tries to connect to https://prod.egonet.codemasters.com/, but since it does
not trust the certificate the connection fails.
The required CA certificate is embedded in dirtrally2.exe, but Wine does not
seem to pick it up and use it.
It all works perfectly if I manually trust the CA system-wide, by placing
codemasters.pem in /etc/ca-certificates/trust-source/anchors and run
update-ca-trust.
--
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=49488
Bug ID: 49488
Summary: uninitialized bytes in server call from
ntdll/server_write_file
Product: Wine
Version: 5.11
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ntdll
Assignee: wine-bugs(a)winehq.org
Reporter: jeffersoncarpenter2(a)gmail.com
Distribution: ---
Created attachment 67607
--> https://bugs.winehq.org/attachment.cgi?id=67607
Configure output.
Steps to reproduce
* Build wine (currently ec9e556d31). Attached my configure output. See for
configure flags.
* Build 'int main() { return 0; }' under i686-w64-mingw-gcc
* Run under valgrind. Valgrind output attached.
The first valgrind error is:
==1472== Syscall param writev(vector[...]) points to uninitialised byte(s)
==1472== at 0x432C2A3: __writev (writev.c:26)
==1472== by 0x432C2A3: writev (writev.c:24)
==1472== by 0x485A099: send_request (server.c:221)
==1472== by 0x485A1DB: server_call_unlocked (server.c:281)
==1472== by 0x485A236: wine_server_call (server.c:297)
==1472== by 0x484B69E: server_write_file (file.c:4706)
==1472== by 0x484CB30: NtWriteFile (file.c:5272)
==1472== by 0x7BC500A8: NtWriteFile (file.c:176)
==1472== by 0x5E267A7: rpcrt4_conn_np_write (rpc_transport.c:415)
==1472== by 0x5E1BF85: rpcrt4_conn_write (rpc_binding.h:197)
==1472== by 0x5E1DB8C: RPCRT4_SendWithAuth (rpc_message.c:850)
==1472== by 0x5E1E9B7: RPCRT4_Send (rpc_message.c:1249)
--
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.