https://bugs.winehq.org/show_bug.cgi?id=51748
Bug ID: 51748
Summary: NIK Dfine2 crashes/hangs (worked before)
Product: Wine
Version: 6.15
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: pit(a)astro.su.se
Distribution: ---
Created attachment 70633
--> https://bugs.winehq.org/attachment.cgi?id=70633
Backtrace of running Dfine2 from within GIMP
I'm using wine to run the (free) NIK collection from Google for image
processing (version 1.2.11, e.g., from here:
https://www.techspot.com/downloads/6809-google-nik-collection.html)
This was working great so far, for many years (at least 3). I run openSUSE
Tumbleweed that regularly upgrades applications. After the last upgrade to
Wine 6.15 this crashes when processing/saving the image. I use gimp and the
plugin ShellOut.py as a wrapper. There, I get an error message from wine
(Unhandled exception: page fault on read access, see attached
backtrace_Dfine2_new.txt)
To check, I renamed my current ~/.wine and did a clean new install of NIK (wine
nikcollection-full-1.2.11.exe). I get the same error (the backlog above is
from this run). Finally I copied the temporary (16bit tif) file gimp saves and
ran Dfine2 from command line, to catch the output. Irritatingly, this did not
crash, but just hang hogging the CPU at 100%....
The console output is attached, too.
--
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=3409
Anastasius Focht <focht(a)gmx.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |focht(a)gmx.net
Fixed by SHA1| |ed8379d1ad0cd13e914dcd011ce
| |be3e7f3a73579
Version|unspecified |0.9-pre
--
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=52190
Bug ID: 52190
Summary: unhandled exception
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: travellouer(a)gmail.com
Distribution: ---
Created attachment 71243
--> https://bugs.winehq.org/attachment.cgi?id=71243
backtrace file from wine
Glyph the game access portal for rift
after installing required update of Glyph wine has:
Unhandled exception:
wine-5.0.3 (Ubuntu 5.0.3-3ubuntu2)
Ubuntu 21.10
kernel: 5.13.0-22-generic
Sorry first time sending bug report just happened a bit ago kids are screaming.
I did search the sites but did not see anything related. I also tried Glyph on
actual win 7 virtual machine it came up fine. Not sure if that is helpful or
not. The backtrace file is attached. If I did something wrong in filing this I
apologize
Everything worked earlier today until threquired update of Glyph
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=52003
Bug ID: 52003
Summary: Stack overflow inside xml2.xmlXPathInit function.
Product: Wine
Version: 6.21
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: besentv(a)gmail.com
Distribution: ---
Created attachment 71003
--> https://bugs.winehq.org/attachment.cgi?id=71003
Thrown exceptions.
The simulator "Zusi 3" uses .htm webpages to show information about its
available content. Some websites have a line of JavaScript that looks something
like this:
<script>var xhr = new window.ActiveXObject( "Microsoft.XMLHTTP" );</script>
which cause the program to crash using Wine.
A +seh trace, provided in the attachments, shows that the program throws a lot
of Division by Zero exceptions before dying in a stack overflow.
Further debugging ended in the result, that the crash occurs inside the
function
"xmlXPathInit" from the xml2 library, which, without a surprise, does divide by
zero. The function call is reached from "msxml3.DllMain" through
DLL_PROCESS_ATTACH and the function "xmlInitParser".
Changing the code to something like
*((long long*) &xmlXPathNAN) = 0x7ff8000000000000;
resolved the issue, though this undefined behavior in C.
(z.f. suggested to use unions instead.)
The only thing that really confuses me, is the big amount of thrown exceptions,
even though the program only executes the division by zero only once. Even on
assembly level. Also, why does this cause a stack overflow?
--
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=51886
Bug ID: 51886
Summary: YouTube Movie Maker: Can't launch after installing
Product: Wine
Version: 5.0.3
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: dungomarkdevlin22(a)gmail.com
Distribution: ---
Created attachment 70828
--> https://bugs.winehq.org/attachment.cgi?id=70828
backtrace
I downloaded YouTube Movie Maker here [https://www.makeyoutubevideo.com/] and
installed it successfully. It is even in the Desktop and Application List menu.
When I open the shortcut, it will show me three buttons to make, upload, or
manage my videos. After clicking on one of them, the loading screen will show,
and a little blue rectangle on the top left of the screen will show and the
wine "Program Error" window. [https://photos.app.goo.gl/65W9zwFzndbMjQjo6]
--
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=51049
Bug ID: 51049
Summary: Sea of Thieves crash when entering a lobby
Product: Wine
Version: 6.7
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: secur32
Assignee: wine-bugs(a)winehq.org
Reporter: leslie_alistair(a)hotmail.com
Distribution: ---
After you set Sail in "Sea of Thieves", it crash due to a secur32 error.
Prior to to commit f93284dfa44b060436c6a0617b51280abb3f24fc, it worked as
expected.
The crash occurs in function schan_InitializeSecurityContextW. The scenario is
that it create a SCHAN_HANDLE_CTX handle, then later frees it. Then attempts
to create another SCHAN_HANDLE_CTX, however passes the same parameters through
except pInput (which is NULL).
Previous, this would return SEC_E_INCOMPLETE_MESSAGE, since the pInput was
NULL, however however now, it jumps through to
else if (!is_dtls_context(ctx)) return SEC_E_INCOMPLETE_MESSAGE;
However the ctx has already been freed in this case and then crashes.
--
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=47865
Bug ID: 47865
Summary: comctl32:propsheet: Different button order for some
RTL locales in Windows 1809?
Product: Wine
Version: 4.17
Hardware: x86
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: comctl32
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
comctl32:propsheet fails on the new Windows 1809 Arabic VM (ww1064v1809_ar):
propsheet.c:1202: RTL locale detected
propsheet.c:511: Test failed: Cancel button should be to the left of OK button
propsheet.c:520: Test failed: Apply button should be to the left of Cancel
button
propsheet.c:529: Test failed: Help button should be to the left of Apply button
propsheet.c:821: Test failed: property sheet with custom window proc: the msg
0x0046 was expected, but got msg 0x0210 instead
https://test.winehq.org/data/tests/comctl32:propsheet.html
However that test still succeeds for the Hebrew locale of the same Windows 1809
VM (w1064v1809_he), and of course on the Hebrew Vista VM (wvistau64_he).
So either the button order is different in Arabic and Hebrew despite both being
RTL locales (maybe it depends on something else?), or something prevents the
test from correctly recognizing the button order, or something is wrong in the
new Arabic setup.
For reference, support for RTL locales was introduced in this patch (without it
the test would likely fail even harder):
commit b8d01f9e1e8c44df5172c4cbfae627158930db72
Author: Alex Henrie <alexhenrie24(a)gmail.com>
AuthorDate: Mon Nov 20 22:54:35 2017 -0700
Commit: Alexandre Julliard <julliard(a)winehq.org>
CommitDate: Tue Nov 21 21:47:42 2017 +0100
comctl32/tests: Detect and handle an RTL locale.
Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com>
Signed-off-by: Alexandre Julliard <julliard(a)winehq.org>
--
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.