https://bugs.winehq.org/show_bug.cgi?id=2636
gastra1er <gastra1er(a)mail.ru> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |gastra1er(a)mail.ru
--
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=3058
gastra1er <gastra1er(a)mail.ru> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |gastra1er(a)mail.ru
--
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=55953
Bug ID: 55953
Summary: page fault in cmxcomm64 when changing UI page of a
Crestron Xpanel64 Regression 8.16 staging
Product: Wine
Version: 8.16
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: dtimms(a)iinet.net.au
Distribution: ---
An AV manufacturer provides a program which generates a touchpanel UI design
which can run on a windows PC using Xpanel. There are a pair off apps (32 and
64 bit) exes, and associated dlls. These load a UI design from a .vtx file. The
design shows pages and buttons, and a simple example can swap between pages via
a button. The application will connect to an IP address/number in the
configuration menu, of the AV manufacturer controller. It will then send and
receive the state of buttons and other controls.
OS: Fedora 38 and 39. x86_64
alternatives set wine as wine64.
Startup:
- In nemo: right click Xpanel64.exe and click Wine, or
- Terminal: wine64 Xpanel64.exe
Normal Operation: (Fedora packages)
Wine 8.15 with staging
Wine up to 8.16 without staging.
Wine up to 8.16 with staging -W eventfd_synchronization.all
Fault occurs: (Fedora packages built locally using mock).
Wine 8.16 with staging
Wine 8.17 with or without staging
Wine 8.19 with or without staging
Wine 8.21 with or without staging (WineHQ Fedora repo).
Fault: Xpanel64.exe runs and shows the initial page UI. Crash occurs when
clicking a button which would normal change UI pages within the application.
Wine Debugger shows, and a second Program Error Details is 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=55946
Bug ID: 55946
Summary: cloudmusic: crash when open cloudmusic.exe
Product: Wine
Version: 8.21
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: li_hai_qiang(a)outlook.com
Distribution: ---
Created attachment 75527
--> https://bugs.winehq.org/attachment.cgi?id=75527
crash when open cloudmusic.exe
cloudmusic: crash when open cloudmusic.exe
--
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=55910
Bug ID: 55910
Summary: Calibre 7 Portable doesn't work
Product: Wine
Version: 8.20
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: bilbiliblus(a)gmail.com
Distribution: ---
Created attachment 75458
--> https://bugs.winehq.org/attachment.cgi?id=75458
Error in Calibre 7 Portable
I installed calibre 7 Portable in Ubuntu 22.04.3 and, when I try to run I get
the error in the attachment.
It doesn't work.
I worked fine with Calibre 6.29
--
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=55907
Bug ID: 55907
Summary: Wine Noodle setup 2.9.2 : crashes on start
Product: Wine
Version: 8.0.2
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: blocker
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: m600(a)free.fr
Distribution: ---
Created attachment 75444
--> https://bugs.winehq.org/attachment.cgi?id=75444
unimplemented function KERNEL32.dll.DiscardVirtualMemory called in 64-bit code
tried to install "Noodl Setup 2.9.2.exe" (see www.noodl.net/)
then got crashe starting with this :
Unhandled exception: unimplemented function KERNEL32.dll.DiscardVirtualMemory
called in 64-bit code (0x0000017002d3a8).
--
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=53556
Bug ID: 53556
Summary: winealsa.drv segfaults on process exit
Product: Wine
Version: 7.15
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ntdll
Assignee: wine-bugs(a)winehq.org
Reporter: brendan(a)redmandi.com
Distribution: ---
Created attachment 72919
--> https://bugs.winehq.org/attachment.cgi?id=72919
Adds test to kernelbase_test.exe sync
I get a segfault on process exit whenever the winealsa.drv is loaded.
I can recreate this by running the winmm_test.exe midi test for example.
I've also attached a patch that adds a test to kernelbase_test.exe (under the
'sync' tests) that recreates this issue. It's recreated in this patch without
the process exit (thread termination is enough).
Here's the stacktrace for the winealsa.drv thread at the beginning of
signal_exit_thread (not long after SIGQUIT is signaled):
#0 0x00007ffff7cee3ce in signal_exit_thread ()
#1 0x00007ffff7d0d25b in abort_thread (status=status@entry=0) at
../../include/winnt.h:2246
#2 0x00007ffff7cf12e8 in quit_handler (signal=<optimised out>,
siginfo=<optimised out>, ucontext=<optimised out>) at
../../dlls/ntdll/unix/signal_x86_64.c:2861
#3 <signal handler called>
#4 0x00007ffff7e0a195 in __futex_abstimed_wait_common64 (private=0,
cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x7ffff5aa2528
<notify_read_cond+40>) at ./nptl/futex-internal.c:57
#5 __futex_abstimed_wait_common (cancel=true, private=0, abstime=0x0,
clockid=0, expected=0, futex_word=0x7ffff5aa2528 <notify_read_cond+40>) at
./nptl/futex-internal.c:87
#6 __GI___futex_abstimed_wait_cancelable64
(futex_word=futex_word@entry=0x7ffff5aa2528 <notify_read_cond+40>,
expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0,
private=private@entry=0) at ./nptl/futex-internal.c:139
#7 0x00007ffff7e0cac1 in __pthread_cond_wait_common (abstime=0x0, clockid=0,
mutex=0x7ffff5aa2540 <notify_mutex>, cond=0x7ffff5aa2500 <notify_read_cond>) at
./nptl/pthread_cond_wait.c:503
#8 ___pthread_cond_wait (cond=cond@entry=0x7ffff5aa2500 <notify_read_cond>,
mutex=mutex@entry=0x7ffff5aa2540 <notify_mutex>) at
./nptl/pthread_cond_wait.c:627
#9 0x00007ffff5a99a67 in midi_notify_wait (args=0x23cfdd0) at
../../dlls/winealsa.drv/alsamidi.c:1512
#10 0x00007ffff7cd7f13 in __wine_unix_call (handle=<optimised out>,
code=<optimised out>, args=0x7ffff5aa2528 <notify_read_cond+40>) at
../../dlls/ntdll/unix/loader.c:1362
#11 0x00007ffff7cee565 in __wine_syscall_dispatcher ()
#12 0x00000000024cf640 in ?? ()
#13 0x0000000000000019 in ?? ()
#14 0x00007ffff7e0d850 in ?? () at ./nptl/pthread_create.c:321
#15 0x00007ffff7cee3cc in signal_start_thread ()
#16 0x0000000000000000 in ?? ()
Before the call to __GI___futex_abstimed_wait_cancelable64 (made from frame 7),
the following line of code is executed:
https://sourceware.org/git/?p=glibc.git;a=blob;f=nptl/pthread_cond_wait.c;h…
__pthread_cleanup_push (&buffer, __condvar_cleanup_waiting, &cbuffer);
This appears to push some cleanup code on to a cleanup stack that glibc later
attempts to use during thread termination. However, the buffer and cbuffer
structs are allocated on the threads stack. Exploring frame 7, we can get the
memory address for the buffer struct (0x24ce870):
(gdb) f 7
#7 0x00007ffff7e0cac1 in __pthread_cond_wait_common (abstime=0x0, clockid=0,
mutex=0x7ffff5aa2540 <notify_mutex>, cond=0x7ffff5aa2500 <notify_read_cond>) at
./nptl/pthread_cond_wait.c:503
warning: Source file is more recent than executable.
503 err = __futex_abstimed_wait_cancelable64 (
(gdb) p &buffer
$1 = (struct _pthread_cleanup_buffer *) 0x24ce870
I then step forward 4 instructions:
(gdb) si
0x00007ffff7cee3d5 in signal_exit_thread ()
1: x/i $rip
=> 0x7ffff7cee3d5 <signal_exit_thread+9>: test %rcx,%rcx
(gdb)
0x00007ffff7cee3d8 in signal_exit_thread ()
1: x/i $rip
=> 0x7ffff7cee3d8 <signal_exit_thread+12>: jne 0x7ffff7cee3dc
<signal_exit_thread+16>
(gdb)
0x00007ffff7cee3dc in signal_exit_thread ()
1: x/i $rip
=> 0x7ffff7cee3dc <signal_exit_thread+16>: mov %rcx,%rsp
(gdb)
0x00007ffff7cee3df in signal_exit_thread ()
1: x/i $rip
=> 0x7ffff7cee3df <signal_exit_thread+19>: call *%rsi
(gdb) bt
#0 0x00007ffff7cee3df in signal_exit_thread ()
#1 0x00007ffff7d0a1f0 in start_thread (teb=0x67fd0000) at
../../dlls/ntdll/unix/thread.c:1070
#2 0x00007ffff7e0db43 in start_thread (arg=<optimised out>) at
./nptl/pthread_create.c:442
#3 0x00007ffff7e9fa00 in clone3 () at
../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
(gdb) p $rsp
$2 = (void *) 0x24cee00
And now the $rsp register is updated (to 0x24cee00), but it's to the right of
the buffer struct. 0x24cee00 - 0x24ce870 = 0x590 (1424 bytes). So once the
stack expands 1424 bytes (to the left), this buffer struct is overwritten.
I add a watch to the buffer structs memory address and continue:
(gdb) watch ((struct _pthread_cleanup_buffer *) 0x24ce870)->__routine
Hardware watchpoint 3: ((struct _pthread_cleanup_buffer *)
0x24ce870)->__routine
(gdb) c
Continuing.
Thread 2 "winmm_test.exe" hit Hardware watchpoint 3: ((struct
_pthread_cleanup_buffer *) 0x24ce870)->__routine
Old value = (void (*)(void *)) 0x7ffff7e0c7a0 <__condvar_cleanup_waiting>
New value = (void (*)(void *)) 0x7ffff7e16330 <unwind_stop>
0x00007ffff7fc2426 in __GI__dl_find_object (pc1=0x7ffff51663e9
<_Unwind_ForcedUnwind+57>, result=0x24ce8d0) at ./elf/dl-find_object.c:363
363 if (__glibc_unlikely (_dlfo_main.map_end == 0))
1: x/i $rip
=> 0x7ffff7fc2426 <__GI__dl_find_object+6>: push %r13
(gdb)
Continuing.
Thread 2 "winmm_test.exe" hit Hardware watchpoint 3: ((struct
_pthread_cleanup_buffer *) 0x24ce870)->__routine
Old value = (void (*)(void *)) 0x7ffff7e16330 <unwind_stop>
New value = (void (*)(void *)) 0x7ffff51663e9 <_Unwind_ForcedUnwind+57>
0x00007ffff5166c91 in get_cie_encoding (cie=0x7ffff516a1b8) at
../../../src/libgcc/unwind-dw2-fde.c:299
299 aug = cie->augmentation;
1: x/i $rip
=> 0x7ffff5166c91 <get_cie_encoding+1>: mov %rdi,%rbp
(gdb)
Continuing.
Thread 2 "winmm_test.exe" hit Hardware watchpoint 3: ((struct
_pthread_cleanup_buffer *) 0x24ce870)->__routine
Old value = (void (*)(void *)) 0x7ffff51663e9 <_Unwind_ForcedUnwind+57>
New value = (void (*)(void *)) 0x24ce890
0x00007ffff516584c in uw_update_context_1 (context=0x24ceb90, fs=0x24ce9d0) at
../../../src/libgcc/unwind-dw2.c:1454
1454 switch (fs->regs.reg[i].how)
1: x/i $rip
=> 0x7ffff516584c <uw_update_context_1+492>: lea 0x4209(%rip),%rbp
# 0x7ffff5169a5c
(gdb) c
Continuing.
It actually gets updated a few times, but the last update is to an invalid
executable address (0x24ce890); which ultimately leads to the segfault:
Thread 2 "winmm_test.exe" received signal SIGSEGV, Segmentation fault.
0x00000000024ce890 in ?? ()
1: x/i $rip
=> 0x24ce890: rex.WXB add %al,(%r8)
1: x/i $rip
=> 0x24ce890: rex.WXB add %al,(%r8)
--
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=54359
Bug ID: 54359
Summary: DaciaMediaNavEvolutionToolbox crashes due to error in
libcef
Product: Wine
Version: 8.0-rc5
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: dani.faugiana(a)gmail.com
Distribution: ---
Created attachment 73931
--> https://bugs.winehq.org/attachment.cgi?id=73931
Backtrace of the crash in libcef.dll
Hello,
I am trying to run DaciaMediaNavEvolutionToolbox to update the car maps.
The application crashes right after starting, I have attached the backtrace.
I have tried running the software in Windows XP and Windows 7 modes.
Same result in both modes.
The error seems to be in libcef.dll, the Chromium Embedded Framework.
Searching other bugs, it seems that it's a bug that re-appears from time to
time as Chromium changes its internals.
Is the fix already ongoing?
Or should I give up (or maybe try to help fixing it?)
Thanks
--
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=55755
Bug ID: 55755
Summary: ntdll:wow64 - The 32-bit test_modules() fails to find
the main module in Wine's new WoW mode
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: ntdll
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
ntdll:wow64 - The 32-bit test_modules() fails to find the main module in Wine's
new WoW mode:
wow64.c:1568: Test failed: main module not found
See https://test.winehq.org/data/patterns.html#ntdll:wow64
In particular one can see this issue on fg-deb64-i386, fgtb-debian11-i386,
fgtb-debian12-i386 and rbernon-*-wow64 which all run the 32-bit tests in the
new Windows-on-Windows Wine mode. This failure does no happen in the 64-bit
test, or when running in a pure 32-bit environment or in the old
Windows-on-Windows mode.
This also happens on macOS when running the 32-bit tests in the new WoW mode
(see mac_rbernon-macos-*-wow64).
A bisect shows that this failure started with the commit below:
commit de81e2ea41b27a14f88177639c5b5d35a210b5bd
Author: Alexandre Julliard <julliard(a)winehq.org>
AuthorDate: Fri Oct 6 15:08:02 2023 +0200
ntdll: Only create the main module on the 32-bit side for wow64.
This means this most likely has the same fix as bug 55744.
--
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=33208
Bug #: 33208
Summary: WWII Battle Tanks: T-34 vs. Tiger selection of the new
company causes to crash
Product: Wine
Version: 1.5.25
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: andrey.goosev(a)gmail.com
CC: andrey.goosev(a)gmail.com
Classification: Unclassified
Created attachment 43931
--> http://bugs.winehq.org/attachment.cgi?id=43931
logout + backtrace
Game runs without any overrides, but has crash when selecting a new company.
--
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.