http://bugs.winehq.org/show_bug.cgi?id=34178
Bug #: 34178
Summary: MiKTeX 2.9 (32-bit) fails to install
Product: Wine
Version: 1.6
Platform: x86-64
URL: http://miktex.org/download
OS/Version: Linux
Status: NEW
Keywords: download, Installer, source
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: austinenglish(a)gmail.com
Blocks: 34172
Classification: Unclassified
Noticed this while looking at bug 34172. I tried the 32-bit version, and get a
separate, but potentially related issue.
Download the installer from http://miktex.org/download
Install as normal. Eventually it gives an error during install:
==========
The operation could not be completed for the following reason:
The operation failed for some reason.
Details: C:\Program Files\MiKTeX 2.90\miktex/bin\initexmf.exe
==========
austin@aw25 ~ $ sha1sum basic-miktex-2.9.4813.exe
e8647f57fe866c00119ca8938785cacfaa5ca826 basic-miktex-2.9.4813.exe
austin@aw25 ~ $ du -h basic-miktex-2.9.4813.exe
155M basic-miktex-2.9.4813.exe
wine-1.6-178-g7944ca4
--
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=41647
Bug ID: 41647
Summary: TFM Music Maker controls are not usable
Product: Wine
Version: 1.9.22
Hardware: x86
URL: http://sega4ever.power-heberg.com/Download/tfmmaker152
.rar
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: user32
Assignee: wine-bugs(a)winehq.org
Reporter: notasas(a)gmail.com
Distribution: ---
After starting the program, click "Instruments" tab and try to adjust any of
the knobs. Nothing useful noticed in the terminal output. Just a guess it's an
issue message handling, so selected user32 component.
Tested to be broken on vanilla wine-1.9.22, wine-1.9.22 (Staging) and
wine-1.6.2. Works correctly on real Windows 7 and 8.1.
--
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=33326
Bug #: 33326
Summary: Sound problem with Game Maker 8.0 games
Product: Wine
Version: 1.5.27
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: georgiev_1994(a)abv.bg
Classification: Unclassified
When Im starting a game created from Game Maker 8.0 Po it's sound does not
start. This is happening with every game Im trying to run. This is caused maybe
because of the sound system of Game Maker built games. Here I will give a link
just to one game which runs just perfect with Windows OS but not perfect at all
with Wine.
http://sandbox.yoyogames.com/games/205913/download
--
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=40119
Bug ID: 40119
Summary: Irfanview 4.x: selection cursor is not correctly
aligned
Product: Wine
Version: 1.8
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: Ulf.Zibis(a)gmx.de
Distribution: ---
- select an area in an image
- correct the selection by dragging the left selection border to another
position
--> the double-ended arrow cursor ofen is not correctly aligned with the
selection border
I guess this happens, when the image is zoomed.
--
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=53682
Bug ID: 53682
Summary: wineboot shows "user_check_not_lock BUG: holding USER
lock" on aarch64 since wine-7.14
Product: Wine
Version: 7.14
Hardware: aarch64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ntdll
Assignee: wine-bugs(a)winehq.org
Reporter: PuetzKevinA(a)JohnDeere.com
Distribution: ---
I recently updated our builds to past wine-7.0, and began encountering a
wineboot failure on aarch64
> 0040:err:system:user_check_not_lock BUG: holding USER lock(64)
> s\system32\rundll32.exe: /home/yukondev/workspace/wine/dlls/win32u/sysparams.c:400: user_check_not_lock: Assertion `0' failed.
> 0040:err:seh:call_function_handlers invalid frame 21f410 (0000000000022000-0000000000120000)
> 0040:err:seh:NtRaiseException Exception frame is not in stack limits => unable to dispatch exception.
After some bisecting, I narrowed this down to being a regression between 7.13
and 7.14, and then further narrowed it to
https://source.winehq.org/git/wine.git/commit/d50112b4b6e82782d3924a8dbd443…
Somehow the call to KeUserModeCallback( NtUserLoadSysMenu,... ) at
https://gitlab.winehq.org/wine/wine/-/blob/d50112b4b6e82782d3924a8dbd443f82…
does not properly return.
I think that commit is mostly a false lead though, the translation of syscall
NtUserCreateWindowEx to a syscall just exposed a latent bug in
KeUserModeCallback/__wine_syscall_dispatcher on aarch64, since having
NtUserCreateWindowEx be a syscall means KeUserModeCallback can no longer use
its "if we have no syscall frame, call the callback directly" simple path
https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/ntdll/unix/signal_ar…
What seems to be actually at fault is that, inside of User32LoadSysMenu (the
actual function invoked by KeUserModeCallback), is a call to NtUserCreateMenu -
which is *also* a syscall. This call doesn't crash, and in fact all of
User32LoadSysMenu runs to completion. But when it goes through
__wine_syscall_dispatcher, the stack pointer is restored to be `$sp =
arm64_thread_data()->syscall_frame`
https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/ntdll/unix/signal_ar…
- i.e. it points to &callback_frame, back on the stack of KeUserModeCallback.
And this is *not* the bottom of the stack; there's compiler-generated
prologue/epilogue to restore various non-volatile registers.
0x0000ffffaa0247b4 <KeUserModeCallback+0>: sub sp, sp, #0x450
0x0000ffffaa0247b8 <KeUserModeCallback+4>: stp x29, x30, [sp]
0x0000ffffaa0247bc <KeUserModeCallback+8>: mov x29, sp
0x0000ffffaa0247c0 <KeUserModeCallback+12>: stp x19, x20, [sp, #16]
0x0000ffffaa0247c4 <KeUserModeCallback+16>: stp x21, x22, [sp, #32]
0x0000ffffaa0247c8 <KeUserModeCallback+20>: str w0, [sp, #56]
0x0000ffffaa0247cc <KeUserModeCallback+24>: str x1, [sp, #48]
0x0000ffffaa0247d0 <KeUserModeCallback+28>: str w2, [sp, #60]
0x0000ffffaa0247d4 <KeUserModeCallback+32>: mov x21, x3
0x0000ffffaa0247d8 <KeUserModeCallback+36>: mov x20, x4
0x0000ffffaa0247dc <KeUserModeCallback+40>: add x19, sp, #0x40 //
x19=&callback_frame
So any code that runs inside this syscall that uses the first 0x40 bytes of
stack is trampling these variables in the frame of KeUserModeCallback.
Eventually User32LoadSysMenu returns back into KiUserCallbackDispatcher, which
passes it into NtCallbackReturn, which does a __wine_longjmp back into the
KeUserModeCallback,and we exit from the __wine_setjmp for the second time
(returning 0) and get to `return callback_frame.status`
https://gitlab.winehq.org/wine/wine/-/blob/wine-7.17/dlls/ntdll/unix/signal….
But then the epilogue starts peeling off the stack
=> 0x0000ffffaa024864 <+176>: ldr w0, [sp, #1088]
0x0000ffffaa024868 <+180>: ldp x19, x20, [sp, #16]
0x0000ffffaa02486c <+184>: ldp x21, x22, [sp, #32]
0x0000ffffaa024870 <+188>: ldp x29, x30, [sp]
0x0000ffffaa024874 <+192>: add sp, sp, #0x450
0x0000ffffaa024878 <+196>: ret
and the link register $x30 = (void *) 0xffffaa024984 <NtCallbackReturn+104>,
rather than 0xffffa8f0ccdc <copy_sys_popup+44> as it was when it was pushed in
the prologue.
It's overwritten several times along the way, but I don't think any of these
call sites are at fault; they are just writing to what they think is their own
stack frame, unaware that __wine_syscall_dispatcher adjusted $sp to too-high a
value and they are overwriting space that belongs to KeUserModeCallback.
The specific places that overwrote this entry on the stack were
#0 0x0000ffffa8f37a48 in NtUserCallOneParam (arg=0, code=2) at
/home/yukondev/workspace/wine/dlls/win32u/sysparams.c:5357
#1 0x0000ffffaa022cf0 in __wine_syscall_dispatcher () from
/opt/wine/bin/../lib/wine/aarch64-unix/ntdll.so
which set it to 0xffffaa022cf0 <__wine_syscall_dispatcher+272>
#0 insert_menu_item (ret_pos=0x21f538, flags=1024, id=4294967295,
handle=0x10042) at /home/yukondev/workspace/wine/dlls/win32u/menu.c:438
#1 NtUserThunkedMenuItemInfo (handle=0x10042, pos=4294967295, flags=1024,
method=1, info=0x11f528 <opengl_func_names+680>, str=<optimized out>) at
/home/yukondev/workspace/wine/dlls/win32u/menu.c:1297
#2 0x0000ffffaa022cf0 in __wine_syscall_dispatcher () from
/opt/wine/bin/../lib/wine/aarch64-unix/ntdll.so
which set it to NULL
and
0x0000ffffaa023a0c in NtCurrentTeb () at
/home/yukondev/workspace/wine/dlls/ntdll/unix/signal_arm64.c:1449
1449 {
(gdb) bt
#0 0x0000ffffaa023a0c in NtCurrentTeb () at
/home/yukondev/workspace/wine/dlls/ntdll/unix/signal_arm64.c:1449
#1 0x0000ffffaa02493c in ntdll_get_thread_data () at
/home/yukondev/workspace/wine/dlls/ntdll/unix/unix_private.h:70
#2 arm64_thread_data () at
/home/yukondev/workspace/wine/dlls/ntdll/unix/signal_arm64.c:163
#3 NtCallbackReturn (ret_ptr=0x0, ret_len=0, status=65602) at
/home/yukondev/workspace/wine/dlls/ntdll/unix/signal_arm64.c:784
#4 0x0000ffffaa022cf0 in __wine_syscall_dispatcher () from
/opt/wine/bin/../lib/wine/aarch64-unix/ntdll.so
which set it to 0xffffaa02493c <NtCallbackReturn+32>, and then 0xffffaa024978
<NtCallbackReturn+92>
, then 0xffffaa024984 <NtCallbackReturn+104>
The same sort of thing happens in the x86_64 dispatcher, but there it turns out
to be pretty harmless. The key difference is that the function prologue on
x86_64 used `push` instructions, and did so prior to the `sub` where it
allocated space for locals, so the things popped by the epilogue ended up above
callback_frame, rather than below it, and so are not smashed.
0x00007fd17b6dc1d2 <+0>: push %rbp
0x00007fd17b6dc1d3 <+1>: mov %rsp,%rbp
0x00007fd17b6dc1d6 <+4>: push %r14
0x00007fd17b6dc1d8 <+6>: push %r13
0x00007fd17b6dc1da <+8>: push %r12
0x00007fd17b6dc1dc <+10>: push %rdi
0x00007fd17b6dc1dd <+11>: push %rsi
0x00007fd17b6dc1de <+12>: push %rbx
0x00007fd17b6dc1df <+13>: sub $0xa0,%rsp
0x00007fd17b6dc1e6 <+20>: and $0xffffffffffffffc0,%rsp
0x00007fd17b6dc1ea <+24>: sub $0x560,%rsp
There is still a 32-byte gap between the $rsp of KeUserModeCallback and
¤t_frame that is briefly at risk, but
1. This seems to be the register parameter area of the Windows x64 ABI, which
is actually volatile space that belongs to the callee even though it's
allocated by the caller, so the compiler is not expecting it to survive across
function calls (in this case __wine_syscall_dispatcher_return).
https://docs.microsoft.com/en-us/cpp/build/stack-usage?view=msvc-170 discusses
how this "contains at least 4 entries", i.e. 32 bytes:
https://eli.thegreenplace.net/2011/09/06/stack-frame-layout-on-x86-64
2. It doesn't actually get smashed, because __wine_syscall_dispatcher subtracts
0x20 from the restored $rsp before actually making the syscall
(https://gitlab.winehq.org/wine/wine/-/blob/d50112b4b6e82782d3924a8dbd443f82…).
Which is presumably since the SysV ABI does *not* make any such reservation,
and so __wine_syscall_dispatcher needs to do so to be following the ms_abi.
So together, these mean that on x86_64, it would be OK if
__wine_syscall_dispatcher used these 32 bytes between the correct $rsp of
KeUserModeCallback and frame->syscall_table (though it doesn't seem to). And
the eventual callee gets a $rsp that does *not* overlap with KeUserModeCallback
(even though it would be legal for it to do so). I don't know that we have any
actual guarantee that callback_frame will be at the bottom, but in practice it
seems to be.
But on aarch64, there's important stuff below callback_frame, so this doesn't
work out.
--
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=48811
Bug ID: 48811
Summary: StarCraft II fails to load in staging, crashes after
trying to start a game in stable
Product: Wine
Version: 5.4
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: dbghelp
Assignee: wine-bugs(a)winehq.org
Reporter: wschmrdr(a)gmail.com
Distribution: ---
Created attachment 66725
--> https://bugs.winehq.org/attachment.cgi?id=66725
Output occurring when the application crashes.
Ever since upgrading from 5.3 to 5.4, StarCraft II has ceased working. On
staging, this occurs during the loading screen. I am able to get through the
Battle.net app OK, but cannot get to my login authenticating. I have tried
switching to stable, but when trying to load up a game, I see the same output
issue. Selected the dbghelp component because that's the line that comes up in
the output at the time of the crash.
--
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=53431
Bug ID: 53431
Summary: widl generates enum forward declarations in typedefs
which are not valid in C++
Product: Wine
Version: 7.13
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tools
Assignee: wine-bugs(a)winehq.org
Reporter: gfw.kra(a)gmail.com
Distribution: ---
Hi everyone,
I recently discovered an issue with C++ code in headers compiled from winrt
idl's using widl. It does not compile when included, when tried using mingw g++
v12.1.0.
There’s seems to be issue with how enum typedefs are translated within
namespaces.
Example:
When tried to include windows.media.speechsynthesis.h compiled from
windows.media.speechsynthesis.idl in cpp file, the following output is received
(compiler output shows headers from mingw, but these look the same when
compiled using widl in wine).
```
/usr/x86_64-w64-mingw32/include/windows.foundation.h:90:26: error: use of enum
‘PropertyType’ without previous declaration
90 | typedef enum PropertyType PropertyType;
| ^~~~~~~~~~~~
/usr/x86_64-w64-mingw32/include/windows.foundation.h:164:18: error: using
typedef-name ‘ABI::Windows::Foundation::PropertyType’ after ‘enum’
164 | enum PropertyType {
| ^~~~~~~~~~~~
/usr/x86_64-w64-mingw32/include/windows.foundation.h:90:39: note:
‘ABI::Windows::Foundation::PropertyType’ has a previous declaration here
90 | typedef enum PropertyType PropertyType;
| ^~~~~~~~~~~~
/usr/x86_64-w64-mingw32/include/windows.media.speechsynthesis.h:218:30: error:
use of enum ‘VoiceGender’ without previous declaration
218 | typedef enum VoiceGender VoiceGender;
| ^~~~~~~~~~~
/usr/x86_64-w64-mingw32/include/windows.media.speechsynthesis.h:476:22: error:
using typedef-name ‘ABI::Windows::Media::SpeechSynthesis::VoiceGender’ after
‘enum’
476 | enum VoiceGender {
| ^~~~~~~~~~~
/usr/x86_64-w64-mingw32/include/windows.media.speechsynthesis.h:218:42: note:
‘ABI::Windows::Media::SpeechSynthesis::VoiceGender’ has a previous declaration
here
218 | typedef enum VoiceGender VoiceGender;
| ^~~~~~~~~~~
/usr/x86_64-w64-mingw32/include/windows.media.speechsynthesis.h:822:30: error:
using typedef-name ‘ABI::Windows::Media::SpeechSynthesis::VoiceGender’ after
‘enum’
822 | enum VoiceGender *value) = 0;
| ^~~~~~~~~~~
/usr/x86_64-w64-mingw32/include/windows.media.speechsynthesis.h:218:42: note:
‘ABI::Windows::Media::SpeechSynthesis::VoiceGender’ has a previous declaration
here
218 | typedef enum VoiceGender VoiceGender;
```
windows.media.speechsynthesis.idl has typedef of enum VoiceGender, which is
defined later.
```
namespace Windows {
namespace Foundation {
interface IClosable;
}
namespace Media {
namespace SpeechSynthesis {
typedef enum VoiceGender VoiceGender;
```
This is translated to following:
```
#ifdef __cplusplus
namespace ABI {
namespace Windows {
namespace Media {
namespace SpeechSynthesis {
typedef enum VoiceGender VoiceGender;
}
}
}
}
#else /* __cplusplus */
typedef enum __x_ABI_CWindows_CMedia_CSpeechSynthesis_CVoiceGender
__x_ABI_CWindows_CMedia_CSpeechSynthesis_CVoiceGender;
#endif /* __cplusplus */
```
This typedef is not valid in C++. According to the standard, enum cannot be
forward declared using typedef. This could be replaced with just simple enum
declaration, but it would need to have type specifier (that goes for definition
as well).
Best regards.
--
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=36079
Bug ID: 36079
Summary: loader fails to build with clang -faddress=sanitize
Product: Wine
Version: 1.7.17
Hardware: x86
OS: Linux
Status: NEW
Keywords: download, source
Severity: enhancement
Priority: P2
Component: build-env
Assignee: wine-bugs(a)winehq.org
Reporter: austinenglish(a)gmail.com
Created attachment 48263
--> https://bugs.winehq.org/attachment.cgi?id=48263
make log
I tried building wine with clang's address sanitizer enabled, which mostly
worked, until the loader:
make[1]: Entering directory '/home/austin/wine-gcc49-asan/loader'
clang -fsanitize=address -m32 -o wine-preloader -static -nostartfiles
-nodefaultlibs -Wl,-Ttext=0x7c400000 preloader.o ../libs/port/libwine_port.a
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.8.2/../../../../lib32/libpthread.a(pthread_mutex_lock.o):
In function `__pthread_mutex_lock':
/var/tmp/portage/sys-libs/glibc-2.19/work/glibc-2.19/nptl/../nptl/pthread_mutex_lock.c:80:
undefined reference to `__assert_fail'
/var/tmp/portage/sys-libs/glibc-2.19/work/glibc-2.19/nptl/../nptl/pthread_mutex_lock.c:116:
undefined reference to `__assert_fail'
/var/tmp/portage/sys-libs/glibc-2.19/work/glibc-2.19/nptl/../nptl/pthread_mutex_lock.c:146:
undefined reference to `__assert_fail'
/var/tmp/portage/sys-libs/glibc-2.19/work/glibc-2.19/nptl/../nptl/pthread_mutex_lock.c:151:
undefined reference to `__assert_fail'
..
austin@aw25 ~/wine-gcc49-asan $ clang --version
clang version 3.3 (tags/RELEASE_33/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
austin@aw25 ~/wine-gcc49-asan $ git describe
wine-1.7.17-42-g24c5728
--
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=49797
Bug ID: 49797
Summary: WIDL doesn't tolerate anonymous structs within
interfaces
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tools
Assignee: wine-bugs(a)winehq.org
Reporter: kolan_n(a)mail.ru
Distribution: ---
IDLs in Windows SDKs sometimes contain anonymous structs within interfaces.
WIDL fails to compile such IDLs.
--
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.