https://bugs.winehq.org/show_bug.cgi?id=42570
Bug ID: 42570
Summary: dinput/tests/mouse intermittently fails in Acquire()
and GetDeviceData()
Product: Wine
Version: 2.2
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: directx-dinput
Assignee: wine-bugs(a)winehq.org
Reporter: z.figura12(a)gmail.com
Distribution: ---
Created attachment 57480
--> https://bugs.winehq.org/attachment.cgi?id=57480
log with +dinput
The following lines are sometimes printed:
mouse.c:143: Test failed: Acquire() should have failed: 00000000
mouse.c:147: Test failed: Acquire() failed: 00000001
Less often, 2-4 of the following lines may be printed as well:
mouse.c:152: Test failed: GetDeviceData() failed: 00000000 cnt:0
mouse.c:158: Test failed: GetDeviceData() failed: 00000000 cnt:0
mouse.c:166: Test failed: GetDeviceData() failed: 00000000 cnt:0
mouse.c:177: Test failed: GetDeviceData() failed: 00000000 cnt:0
This affects at least the f25 and hd6800 test machines. If there is any
relevant information I can provide about my machine, please let me know.
--
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=41220
Bug ID: 41220
Summary: Provide fallback implementation of strnlen for OS
versions that don't have it in their Libc (Leopard,
Snow Leopard, et al)
Product: Wine
Version: 1.9.17
Hardware: x86
OS: Mac OS X
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: directx-d3d
Assignee: wine-bugs(a)winehq.org
Reporter: jeremyhu(a)freedesktop.org
wine-1.9.17 is failing to build on Leopard and Snow Leopard due to strnlen not
being available on those OS versions, where d3d10.dll.so and d3d11.dll.so fail
to link with:
Undefined symbols for architecture i386:
"_strnlen", referenced from:
_fx10_get_string in effect.o
Undefined symbols for architecture i386:
"_strnlen", referenced from:
_shader_parse_signature in shader.o
A fallback implementation of strnlen should be provided for such cases.
--
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=43905
Bug ID: 43905
Summary: pCon Planner crashes using builtin msvcp: access
violation reading location 0x60 at
basic_ios_char_widen in module msvcp140.
Product: Wine
Version: 2.18
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: msvcp
Assignee: wine-bugs(a)winehq.org
Reporter: xerox.xerox2000x(a)gmail.com
Distribution: ---
Created attachment 59532
--> https://bugs.winehq.org/attachment.cgi?id=59532
+seh,+tid,+msvcp log, last 20000 lines
Follow up of bug 39955
Prerequisite: winetricks msxml6 (to work around bug 39955)
With native msvcp140 the application starts, with builtin msvcp140 there`s the
crash like in the attached debuglog
wine --version wine-2.18 (Staging)
--
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=43217
Bug ID: 43217
Summary: Wine cannot execute position-independent (PIE) host
executables via CreateProcess()
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: kernel32
Assignee: wine-bugs(a)winehq.org
Reporter: osmanx(a)problemloesungsmaschine.de
Distribution: ---
Created attachment 58504
--> https://bugs.winehq.org/attachment.cgi?id=58504
script.sh: Test script to reproduce the problem; test.c: Windows program;
hello.c: Host/Linux program
The problem arises from the fact that `create_process_impl()` in
`dlls/kernel32/process.c` ultimately calls `MODULE_get_binary_info()` in
`dlls/kernel32/module.c` which detects PIE exectuables as ELF shared objects
and thus sets `info->type = BINARY_UNIX_LIB;` instead of `info->type =
BINARY_UNIX_EXE;`. I do not have enough knowledge about the precise way that
Winelib apps are implemented or supposed to work, but the fact that PIE
executables are in fact ELF shared objects and not ELF executables according to
the ELF header, causes Wine to detect these as Winelib apps and ultimately
invoke the wrong process creation path.
The problem especially manifests on the just released Debian 9 Stretch because
Debian 9 now uses PIE executables throughout the distribution and these cannot
be started any more from within programs running on Wine. Tested with
winehq-devel packages 2.10 as well as Debian 9 packaged Wine 1.8.7 and 2.0.
Looking at Wine git master, the relevant code paths have not changed at all for
quite some time, thus this very likely also applies to all other Wine versions
as well. Non-PIE executables work fine.
Test script (script.sh) to reproduce the problem as well as output of the test
script attached.
--
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=40866
Bug ID: 40866
Summary: DigitalMicrograph: crashes when a new script is added
to the menu
Product: Wine
Version: 1.9.13
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: user32
Assignee: wine-bugs(a)winehq.org
Reporter: niermann(a)physik.tu-berlin.de
Distribution: ---
Created attachment 54885
--> https://bugs.winehq.org/attachment.cgi?id=54885
Wine output during crash
DigitalMicrograph by Gatan crashes when the "Install Script" dialog is closed.
Independently of whether the dialog is opened via the "File->Install Script" or
the "File->Install Script File" command.
To reproduce: Create new script (File->New Script) and try to install it
(File->Install Script). In the "Install script" dialog simply press Enter
without changing anything.
Bug occurs on DigitalMicrograph versions 1.8.3 and 2.3.0 (others not tested)
and with wine 1.6.2 and wine-1.9.13 (others not tested).
>From tracing the outputs and by debugging wine I found the reason for the crash
to be in dlls/user32/edit.c: The application calls EM_GETHANDLE and later
WM_SETFONT on an edit control (without sending EM_SETHANDLE in between). During
processing WM_SETFONT the es->text field is accessed, which at this point
contains NULL due to the inhibited buffer locking after EM_GETHANDLE.
--
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=44168
Bug ID: 44168
Summary: Wizardry 8 hangs when starting a new game or loading a
saved game
Product: Wine
Version: 3.0-rc1
Hardware: x86
URL: https://www.fileplanet.com/81227/80000/fileinfo/Wizard
ry-8-Demo
OS: Linux
Status: NEW
Keywords: download, regression
Severity: normal
Priority: P2
Component: msvcrt
Assignee: wine-bugs(a)winehq.org
Reporter: gyebro69(a)gmail.com
CC: piotr.caban(a)gmail.com
Regression SHA1: ee33d38c5041a8293c64257801572d1c742b0aba
Distribution: ---
Created attachment 59933
--> https://bugs.winehq.org/attachment.cgi?id=59933
terminal output
I tested this bug with the GOG.com version of the game, but it can be
reproduced with the demo version, too.
The demo contains only a sample save game but that will do to reproduce the
bug.
The game becomes unresponsive when I start a new game (after the party
selection and intro video), or when I try to load a previously saved game. The
game executable constantly pegging the CPU at 100% and the game needs to be
closed forcibly.
To reproduce the problem in the demo:
1. Install the demo and start Wiz8.exe. On first launch the game configuration
window will appear (requires mfc42.dll). Just accept the default settings and
get in the game.
2. In the menu select load game and choose the only available save game the
demo offers --> the game hangs for good.
Reverting the following commit fixes the problem for me:
commit ee33d38c5041a8293c64257801572d1c742b0aba
Author: Piotr Caban <piotr(a)codeweavers.com>
Date: Mon Nov 27 20:29:44 2017 +0100
msvcrt: Call cdecl functions with empty FPU stack in _CI* functions.
The FPU stack should be empty on cdecl function call. Failing to do so
breaks GCC 6.4.0 -O2 optimized code.
Using native msvcrt.dll also works around the problem (winetricks vcrun6).
I'm on Arch Linux (64-bit) and gcc version is: gcc version 7.2.1 20171128 (GCC)
I compiled Wine without compiler optimizations '-O0 -g' but that didn't solve
the problem.
wine-3.0-rc1-23-g081eae7ac3
Wiz8NetDemoEB.exe (143M)
md5sum: 728f87e9768102c71017675a1bb06425
--
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=36441
Bug ID: 36441
Summary: joy.cpl crashes when PS4 Gamepad connected via
Bluetooth
Product: Wine
Version: unspecified
Hardware: x86
OS: Mac OS X
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: lp-san(a)lostpoint.ru
Created attachment 48464
--> http://bugs.winehq.org/attachment.cgi?id=48464
crash log available via gui crash message
First of all, I'd like to apologize if I came to the wrong bigtracker, since
I'm a wineskin user, not pure wine user. But I believe the problem is a
wine-specific, not wineskin specific.
I'm using Wineskin 2.6.0 (latest) with Wine Engine WS9Wine1.7.18 (the latest
available via Wineskin).
I'm connecting PS4 Gamepad via Bluetooth, then I start a Wine/Wineskin Command
Line Shell, executing "control joy.cpl" and the control panel applet crashes.
If I disconnect the gamepad, the applet works fine.
I attached the crash log information in a text file. I can provide any debug
information from the wine logs if needed.
--
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=44148
Bug ID: 44148
Summary: DX Library: Multiple PlaySoundMem() calls don't work
when using XAudio2
Product: Wine
Version: 3.0-rc1
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: xaudio2
Assignee: wine-bugs(a)winehq.org
Reporter: kakurasan(a)gmail.com
CC: aeikum(a)codeweavers.com
Regression SHA1: e2c73fc394bace00c4463b6fcb6dfe9dc64084bc
Distribution: ---
Created attachment 59902
--> https://bugs.winehq.org/attachment.cgi?id=59902
Testcase
When using XAudio2, multiple PlaySoundMem() calls don't play the same audio
repeatedly.
"git bisect" says e2c73fc394bace00c4463b6fcb6dfe9dc64084bc is the first bad
commit.
--
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=43000
Bug ID: 43000
Summary: wine can't be compiled by gcc-2.95.4
(dsound/dsound_convert.c, C99 ~ lrintf)
Product: Wine
Version: 2.7
Hardware: x86
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: directx-dsound
Assignee: wine-bugs(a)winehq.org
Reporter: wylda(a)volny.cz
Distribution: ---
wine-2.7 @ gcc-2.95.4: compilation fails:
/dlls/dsound/dsound_convert.c: In function `f_to_8':
/dlls/dsound/dsound_convert.c:123: warning: implicit declaration of function
`lrintf'
/dlls/dsound/dsound_convert.c: At top level:
/dlls/dsound/dsound_convert.c:342: Internal compiler error:
/dlls/dsound/dsound_convert.c:342: Internal compiler error in `output_die', at
dwarf2out.c:5433
--
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.