https://bugs.winehq.org/show_bug.cgi?id=51234
Bug ID: 51234
Summary: user32:clipboard test_ClipboardOwner() has a race
condition with clipboard managers
Product: Wine
Version: 6.8
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: user32
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
test_ClipboardOwner() has a race condition with clipboard managers that causes
this set of failures:
clipboard.c:404: Test failed: SetClipboardData succeeded
clipboard.c:406: Test failed: wrong error 3735928559
clipboard.c:407: Test failed: SetClipboardData succeeded
Fortunately(?) this failure is pretty rare.
What happens is this:
* test_ClipboardOwner() does this:
OpenClibpoard(NULL)
EmptyClipboard() // take ownership
CloseClipboard()
* Then the clipboard manager starts checking the content of the clipboard:
OpenClipboard(manager_hwnd)
...
* And then the next test_ClipboardOwner() test happens:
SetClipboardData(CF_WAVE, ...)
ok(GetLastError() == ERROR_CLIPBOARD_NOT_OPEN, ...)
ok(!IsClipboardFormatAvailable(CF_WAVE), ...
Because test_ClipboardOwner() opened the clipboard with a NULL windows handle,
EmptyClipboard() used that as the clipboard owner. But when the owner is NULL a
process can place data in the clipboard as long as any process opened it. This
is actually the whole point of the run_process("set_clipboard_data 4") test.
So the problem is that user32:clipboard assumes that no other process is going
to open the clipboard after it called CloseClipboard(). Yet that's precisely
when clipboard manager would receive a WM_CLIPBOARDUPDATE message and open it.
--
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=48911
Bug ID: 48911
Summary: Check for compilation warnings
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: ---
Compiling Wine with -Werror is troublesome because it applies blindly to both
wine-devel patches and patches submitted manually via the website. The sole
purpose of the latter is often to just clarify some point for the development
of another patch and are not meant to be submitted. Thus failing on warnings
just makes running these quick tests more cumbersome.
So the best way forward would be for the TestBot to identify and report
warnings but not fail the compilation and abort the tests when they occur.
So:
1. The builds should happen without -Werror.
2. GetLogLineCategory() should identify the warnings and add them to LogInfo
but distinguish them from errors (replace IsNew with a Category field?).
3. Compare task.log to the reference build log to distinguish new warnings from
old ones. This is necessary in case the compiler used by the TestBot produces
warnings on the unpatched Wine tree. It will require storing the build logs in
latest/ just like the TestBot already does for the reference WineTest reports.
4. LogInfo's will need to keep track of the number of new warnings which really
means renaming the 'NewCount' field to avoid confusion.
5. The warnings should be saved in the errors files. The new line types could
be 'w' and 'W' for old and new warnings respectively (then it would make sense
to use e and E for errors).
6. This will let the WineRun*() scripts know about both warnings and errors.
They can then decide what to do depending on the type of job and whether the
warnings are new or not.
- Old warnings would always be ignored.
- If a build task has new warnings, instead of marking it as 'badbuild' it
could be marked as 'completed' as usual but with a non-zero number of failures.
This would probably allow running the tests on Windows but the patch would
still be considered bad since the job would end up with a non-zero number of
failures.
- For Wine tasks the number of warnings would be added to the Failures field
for the same overall result.
- So in both cases the non-zero number of failures would only impact
wine-devel patches.
7. The JobDetails page should show the warnings in summary mode and highlight
them in the full build log. That would make it easy for developers to see the
warnings on web-submitted jobs, and thus fix them before submitting the patch
to wine-devel.
--
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=43653
Bug ID: 43653
Summary: Waves Central: install vst plugins issue
Product: Wine
Version: 2.16
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: viking991(a)gmx.de
Distribution: ---
Created attachment 59080
--> https://bugs.winehq.org/attachment.cgi?id=59080
waves central error message
Hi!
Waves Central (license manager / installer from waves.com) does not install vst
plugins in Wine.
installation aborts with this message box, also see attachment
###
Sorry
An error has occurred during installation
Please follow the steps in this troubleshooter
###
- System:
winehq-staging 2.16
debian stretch
- Steps to re-produce:
1) Download Waves Central installer
http://www.waves.com/downloads/central
Direct download link:
http://www.waves.com/dlrdr?id=central-win
Tested Waves Central Version: V1.3.3.4
sha1sum Install_Waves_Central.exe
0f90b9333855a8713e3f9ced767369364a46aa33 Install_Waves_Central.exe
2) Run Installer
wine64 Install_Waves_Central.exe
3) Run Waves Central
wine64 Waves\ Central.exe
4) Log in
unfortunately this needs an account with waves.com:
-> Log in -> create account -> web browser opens to create account
user user/pass in Waves Central to log in.
5) install any VST:
-> install products
-> install from online
-> choose products to install -> All Waves products
-> select any product, for example H-Reverb Hybrid Reverb 9
-> click install, message box as attached appears.
also check bug 43648
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=42588
Bug ID: 42588
Summary: Vietcong - graphics glitches since Wine 2.1
Product: Wine
Version: 2.1
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: directx-d3d
Assignee: wine-bugs(a)winehq.org
Reporter: havran.jan(a)email.cz
Distribution: ArchLinux
Created attachment 57517
--> https://bugs.winehq.org/attachment.cgi?id=57517
Vietcong - terminal log
In version 2.1 was introduced new bug that causes graphical glitches like
flickering soldiers. I can confirm this bug in wine versions 2.1, 2.2 and 2.3.
In versions 2.0 and below it worked probably fine - this bug is not 100%
reproducible - sometimes soldiers are flickering and glitches are shown very
often, sometimes just for few milisecond, but i am pretty sure that this was
introduced in version 2.1
Tested on Intel and AMD GPUs, Vietcong 1.60 with VCStarter 1.7 Beta
--
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=50218
Bug ID: 50218
Summary: Unable to finish the installation of Lego Staunt
rallye: request for indeo codec
Product: Wine
Version: 5.22
Hardware: x86
URL: https://www.myabandonware.com/game/lego-stunt-rally-bd
5#download
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: jeremielapuree(a)yahoo.fr
Distribution: Ubuntu
Created attachment 68723
--> https://bugs.winehq.org/attachment.cgi?id=68723
screenshot of the error
At the end of the stage of install, setup complains about indeo codecs.
--
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=44230
Bug ID: 44230
Summary: SlingPlayer 1.5 crashes during configuration
Product: Wine
Version: 2.22
Hardware: x86
URL: http://download.slingmedia.com/player/pc/SlingPlayer-S
etup-EU-1.5.1.343.exe
OS: Linux
Status: NEW
Keywords: download, regression
Severity: normal
Priority: P2
Component: user32
Assignee: wine-bugs(a)winehq.org
Reporter: imwellcushtymelike(a)gmail.com
CC: julliard(a)winehq.org
Regression SHA1: 01676c5dd6f9fb61b9c4e52595f6e75e21050009
Distribution: Ubuntu
Created attachment 60025
--> https://bugs.winehq.org/attachment.cgi?id=60025
Wine 3.0-rc3 console output
SlingPlayer 1.5 crashes when attempting to configure the Slingbox (Alt+E -->
Slingbox Configuration --> Change...) (Slingbox needed)
Native qcap causes a new problem so can't try that as a workaround.
Native quartz needed to get this far.
The crash does not occur in Staging 2.21.
I compiled Wine 3.0-rc3 with -O0 and the crash does not occur. Compiling again
with -O1 or -O2 and the problem returns (did not try -O3). I also receive the
following warning during compilation, but further testing suggests it is not
related:
cc1: warning: unrecognized command line option ‘-Wno-packed-not-aligned’
I tried reverting 6864803f1ab70f9f9e90903b13e67da40973d12a but it did no make
any difference.
https://source.winehq.org/git/wine.git/commitdiff/6864803f1ab70f9f9e90903b1…
I also tried compiling with the following, which the man page claims GCC sets
with -O1, but the crash still didn't occur:
-fomit-frame-pointer -ftree-phiprop -ftree-sink -ftree-slsr -ftree-sra
-ftree-pta -ftree-ter -funit-at-a-time -ftree-copy-prop -ftree-copyrename
-ftree-dce -ftree-dominator-opts -ftree-dse -ftree-forwprop -ftree-fre
-fmove-loop-invariants -fshrink-wrap -fsplit-wide-types -ftree-bit-ccp
-ftree-ccp -fssa-phiopt -ftree-ch -finline-functions-called-once
-fipa-pure-const -fipa-profile -fipa-reference -fmerge-constants
-fdelayed-branch -fdse -fforward-propagate -fguess-branch-probability
-fif-conversion2 -fif-conversion -fauto-inc-dec -fbranch-count-reg
-fcombine-stack-adjustments -fcompare-elim -fcprop-registers -fdce -fdefer-pop
The crash goes away when reverting commit
01676c5dd6f9fb61b9c4e52595f6e75e21050009 and recompiling.
01676c5dd6f9fb61b9c4e52595f6e75e21050009 is the first bad commit
commit 01676c5dd6f9fb61b9c4e52595f6e75e21050009
Author: Alexandre Julliard <julliard(a)winehq.org>
Date: Sat Nov 25 11:48:02 2017 +0100
user32: Use the magic format string prefix for relay traces.
Signed-off-by: Alexandre Julliard <julliard(a)winehq.org>
:040000 040000 c075dd76fd2d86e2cb8e14a300f4f8a7a8952bf4
ab6d49e1c18eae5208a19b0be062ffbf7abc8518 M dlls
Staging 2.21 does have this commit, but the binary packages do, beginning with
release 3.0-rc1.
Workaround unknown.
--
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=47828
Bug ID: 47828
Summary: regedit: Random crashes on selecting an entry
(thread-related?)
Product: Wine
Version: 4.0
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: ed7-aspire4925(a)hotmail.com
Distribution: ---
Created attachment 65333
--> https://bugs.winehq.org/attachment.cgi?id=65333
commented logs from the various crashes
As described above. By selection I meant double-clicking or pressing [return]
on a highlighted entry
Sometimes the "debuggee" works, sometimes it doesn't.
Sometimes the back trace shows, sometimes it doesn't.
Sometimes the application crash window doesn't even appear.
Definitely a threading issue...
The crash occurs at around the eighth key selection.
--
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=48322
Bug ID: 48322
Summary: World of Warcraft Classic: Mouse movement can block
keydown events from registering
Product: Wine-staging
Version: 5.0-rc1
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: m.schaefer8(a)gmail.com
CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com
Distribution: ---
This seems to be a regression:
I've noticed this in the game World of Warcraft Classic. In Wine 4.17.r11
mouse/keyboard behave as expected. With 5.0-rc1 when keeping the right mouse
button clicked *and* moving the mouse (changing character orientation and view
orientation with the mouse) all other keydown events are ignored. Moving the
mouse by itself does not block keydown events; keeping the button pressed but
not moving the mouse also does not block keydown events.
Keyup events are processed as normal.
Software I'm using is specifically Wine-Staging with TKG patches.
Having never filed bugs for Wine before, please inform me if you require
additional information, logs (and how to acquire said logs), etc.
--
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=47438
Bug ID: 47438
Summary: Bloodstained: Ritual of the Night freeze at
whitescreen because of mfplat commit
eff5a7aebc65e98cacf0d6a0ccc6101ffa552aa0
Product: Wine
Version: 4.4
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: mfplat
Assignee: wine-bugs(a)winehq.org
Reporter: GloriousEggroll(a)gmail.com
Distribution: ---
Bloodstained: Ritual of the Night shows a white screen upon opening and freezes
there due to the following commit that was made to mfplat:
eff5a7aebc65e98cacf0d6a0ccc6101ffa552aa0
mfplat: Implement media event queue
I did a bisect between 4.3 and 4.4 as it works in 4.3, and found that commit to
be the cause.
As a lot of work has been done on mfplat, and this is implementing a rather
large feature, its not some thing that seems to be easily revertible.
Using winetricks mf results in the game just popping up an error.
--
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=41339
Bug ID: 41339
Summary: Minor regression: Wine loads with
"/wine/dlls/ntdll/loader.c: loader_section" errors
when creating a new prefix or running an application
Product: Wine
Version: 1.9.18
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: fjfrackiewicz(a)gmail.com
Distribution: ---
I noticed that with Wine 1.9.18, whenever I either created a new prefix or ran
an application I would receive the following errors in my terminal:
err:ntdll:RtlpWaitForCriticalSection section 0x7bcf4f84
"../../../wine/dlls/ntdll/loader.c: loader_section" wait timed out in
thread 001d, blocked by 001e, retrying (60 sec)
err:ntdll:RtlpWaitForCriticalSection section 0x7bcf4f84
"../../../wine/dlls/ntdll/loader.c: loader_section" wait timed out in
thread 001c, blocked by 001e, retrying (60 sec)
This issue was also brought up by Bruno Jesus in the wine-devel mailing list
here: https://www.winehq.org/pipermail/wine-devel/2016-September/114672.html
Since I am not the only one experiencing this, I decided to run a regression
test. According to the git bisect I have performed this issue first appears in
wine-1.9.17-149-gd2b782f
The bad commit in question:
commit d2b782f4e4f0efa6e783031d57cf98789cdc4742
Author: Henri Verbeet <hverbeet(a)codeweavers.com>
Date: Fri Aug 26 13:51:22 2016 +0200
ddraw: Rename "wineD3DVertexBuffer" to "wined3d_buffer".
Signed-off-by: Henri Verbeet <hverbeet(a)codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard(a)winehq.org>
:040000 040000 719fe9426a27661606b40339c96588fa09e3385e
07af319b9fd2e194b9a5990a0c09277d34ed42bb M dlls
--
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.