November 2020 - Wine-Bugs - list.winehq.org

[Bug 32725] New: VC runtime functions crash when called from reloaded library in a thread
by wine-bugs＠winehq.org May 5, 2021

May 5, 2021

http://bugs.winehq.org/show_bug.cgi?id=32725 Bug #: 32725 Summary: VC runtime functions crash when called from reloaded library in a thread Product: Wine Version: 1.3.24 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: msvcrt AssignedTo: wine-bugs(a)winehq.org ReportedBy: most(a)museresearch.com Classification: Unclassified Created attachment 43181 --> http://bugs.winehq.org/attachment.cgi?id=43181 msvcrt-dll-problem.zip Assume WHAT.DLL is a windows DLL with static MSVCRT linkage. If WHAT.DLL is unloaded and reloaded, it's C runtime functions like std::cout can crash when called from a thread. According to Piotr Caban (piotr dot caban at gmail dot com) "The crash is caused by incomplete FlsFree implementation. There's a comment in it's code that says what needs to be added: /* FIXME: add equivalent of ThreadZeroTlsCell here */" The crash is repeatable with the attached example winelib program (captain.exe) and windows DLL (what.dll). Code for the compiled what.dll is included. An included README file describes the contents. 'make test' demonstrates the problem. -- 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.

2 8

[Bug 33660] New: CS:GO - Call votes respond
by wine-bugs＠winehq.org May 4, 2021

May 4, 2021

http://bugs.winehq.org/show_bug.cgi?id=33660 Bug #: 33660 Summary: CS:GO - Call votes respond Product: Wine Version: 1.5.30 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: pepe(a)bloodkings.eu Classification: Unclassified Once a player can call vote, and only works the first choice (F1, 1). -- 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.

2 19

[Bug 31787] New: Run the tests in Wine
by wine-bugs＠winehq.org May 3, 2021

May 3, 2021

http://bugs.winehq.org/show_bug.cgi?id=31787 Bug #: 31787 Summary: Run the tests in Wine Product: Wine-Testbot Version: unspecified Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: fgouget(a)codeweavers.com Classification: Unclassified The Wine TestBot runs the conformance tests on Windows VMs before they are committed to Wine. This greatly helped improve the quality of our conformance tests. The next step is making sure that the conformance tests work reliably in Wine too, and that Wine patches don't break them. The hope is that this will help us improve the state of the WineTest results: http://test.winehq.org/data/ Doing so will be much more processor intensive than the current process: * Currently only the conformance test patches are tested whereas we would need to test almost every single patch (we could ignore some documentation patches for instance). * Currently we only have to generate a binary for the one conformance test that's impacted. That's quick. Testing all Wine patches will require recompiling Wine every time which takes more time, even with ccache. * A Wine patch can have wide-ranging effects. For instance a patch to ntdll could impact pretty much any conformance test. That means rerunning all of them for every patch... unless we find reliable ways of pruning them (patches to conformance tests would be an obvious optimization). * Like for Windows we will need to test various configurations: different locales; 32, 64 and 32+64 bit Wine builds; different sound backends; possibly different Linux distributions; if possible FreeBSD and Solaris too (I'm leaving Mac OS X for another bug). In some cases the same binaries can be used for multiple tests (e.g. if only the locale changes) but in other cases not. * Also for the current Wine TestBot an unreliable test only impacts people modifying that test. But the above point means an unreliable test would impact most Wine patches, leading to lots of patches being rejected. So this means unreliable tests become a big issue and need to be handled in some way: fixed or blacklisted or still run but not considered cause for rejection (so one can notice when they get fixed). Then there is the question of whether this should be done by modifying the Wine TestBot or by using the BuildBot framework: http://trac.buildbot.net/wiki/AboutBuildbot Dan Kegel produced a proof of concept system based on BuildBot: http://wiki.winehq.org/BuildBot An issue is that without significant integration work, having both a WineTestBot and BuildBot system would be annoying: * The Wine TestBot currently has its own user database and BuildBot would add another one. So it would be one more login to manage for developers unless we manage to integrate either with another user database (e.g. through LDAP). * Developers would have to submit patches to both sites and check the results on both. * Integration with the Wine Patches site (http://source.winehq.org/patches/) would need to work with both systems. -- 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.

2 14

[Bug 33234] New: Improve user management
by wine-bugs＠winehq.org May 3, 2021

May 3, 2021

http://bugs.winehq.org/show_bug.cgi?id=33234 Bug #: 33234 Summary: Improve user management Product: Wine-Testbot Version: unspecified Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: fgouget(a)codeweavers.com Classification: Unclassified When an account request is sent to a WineTestBot administrator the URL he gfets sent to is the UserDetails.pl one but it only has an 'Approve' button, not a 'Reject' one. This makes it unclear how to reject spam requests for instance (bug 31798), but this has now been documented. Still, rejecting an application actually requires going to another page and deleting the provisional account. This should be simpler: there should be a 'Reject' button right on the UserDetails page that does that. Furthermore, the status of the account, 'Pending approval' and 'Pending activation', should be clearly indicated both on the UserDetails page and on the UsersList page. -- 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.

2 5

[Bug 48093] New: On cw-rx460 the WoW WinePrefixes are (likely) broken
by WineHQ Bugzilla May 3, 2021

May 3, 2021

https://bugs.winehq.org/show_bug.cgi?id=48093 Bug ID: 48093 Summary: On cw-rx460 the WoW WinePrefixes are (likely) broken 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: --- On cw-rx460 the wineprefixes created for the wow32 and wow64 test runs are flawed: * It looks like they do not define the %windir% and %SystemRoot% environment variables: https://www.winehq.org/pipermail/wine-devel/2019-October/152271.html * They may be responsible for a failure in crypt32:sip https://www.winehq.org/pipermail/wine-devel/2019-November/154240.html What's puzzling is that cw-rx460 runs the same wt-daily script (*) as cw-gtx560 and other machines which don't have the same set of failures (see also bug 48092). cw-rx460 is not a TestBot VM so this does not impact the TestBot results. But if the wineprefixes are indeed causing extra test failures this could lead developers on a wild goose chase. So to avoid confusion I disabled the wow32 and wow64 WineTest runs on that machine until I have had time to investigate. (*) https://github.com/fgouget/wt-daily -- 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.

1 4

[Bug 39442] New: Using Spice required to avoid failure in mmdevapi:capture
by wine-bugs＠winehq.org May 3, 2021

May 3, 2021

https://bugs.winehq.org/show_bug.cgi?id=39442 Bug ID: 39442 Summary: Using Spice required to avoid failure in mmdevapi:capture 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: --- The Windows 7+ VMs all use an ich6 virtual soundcard (they don't support any of ac97, es1370 or sb16 ones). But they have failures in mmdevapi:capture such as: capture.c:586: Returned latency: 5.8050 ms capture.c:178: Test failed: Position 375 expected 0 capture.c:186: Wait'ed position 375 pad 0 flags 1, amount of frames locked: 448 capture.c:228: Test failed: Position 1719 expected 823 [...] It turns out that the way the VM is configured for remote access impacts the result of the tests: * If configured for VNC then the tests fail as described, even if no client is connected. * If configured for Spice access then the tests succeed, even if no client is connected. And if a client is connected the sound is carried over with pretty good reliability. So the way one accesses the VM changes the behavior in the guest. That seems wrong and I reported it to QEmu: https://bugs.launchpad.net/qemu/+bug/1499908 I have updated the w7pro64 configuration on 2015/09/25 and it now only has one intermittent Master volume failure left in mmdevapi:capture. The change does not seem to have negatively impacted the other tests. So it seems the change can safely be propagated to the other Windows 7+ VMs. There may be one issue though, which is that combining QXL with Spice causes the Windows 10 VM to freeze very quickly. Hopefully that's specific to Windows 10. -- 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.

2 7

[Bug 39419] New: Fix the 'Failure running script in VM' errors
by wine-bugs＠winehq.org May 3, 2021

May 3, 2021

https://bugs.winehq.org/show_bug.cgi?id=39419 Bug ID: 39419 Summary: Fix the 'Failure running script in VM' errors 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: --- There are two very common 'boterror' types: Failure running script in VM: the "nc -q0 '10.42.42.133' '4242'" command returned 1 and Failure running script in VM: network read timed out (Connect:AgentVersion.h:0/9) Both seem to correspond to a network issue and both seem to almost exclusively and systematically happen with the w864 and w1064 VMs when running either a 32 or 64 bit WineTest job (i.e. running the full suite). -- 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.

2 2

[Bug 47852] New: Let developers pick any of the Wine VM's missions for their job
by WineHQ Bugzilla May 3, 2021

May 3, 2021

https://bugs.winehq.org/show_bug.cgi?id=47852 Bug ID: 47852 Summary: Let developers pick any of the Wine VM's missions for their job 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: --- Wine VMs can typically perform multiple missions. For instance the Debian 10 VM missions are: win32,test=module:win32,lang=fr_FR:win32,lang=ja_JP:win32,test=module,lang=zh_CN|wow32,test=module:wow64,test=module This means it can run the tests against the win32, wow32 and wow64 Wine builds, in English, French, Japanese and Chinese locales. But when submitting a job though the website the tests are only run against the win32 Wine build in the English locale and the developer cannot pick any other test configuration. This means debugging failures that only happen on the wow64 build of the TestBot require sending the patch to wine-devel which pollutes the mailing list, triggers many other tests, and is cumbersome for the developer. So the 'Submit job' page should analyze a Wine VM's missions and provide a way to pick any combination of build and language (since they are independent). -- 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.

1 2

[Bug 40239] New: Submitting more than one job for a given file fails
by wine-bugs＠winehq.org May 3, 2021

May 3, 2021

https://bugs.winehq.org/show_bug.cgi?id=40239 Bug ID: 40239 Summary: Submitting more than one job for a given file fails 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: --- Steps to reproduce: * Open the 'Submit job' page in two windows. * In both select the same file, for instance a patch.diff file or mytest.exe one. * Fill the Remarks field and click on the next button in both windows. * Continue the submission process on both sides. * At the end one job will work and the other will have 'unknown' written in the 'File name' column and fail with a TestBot error. During the submission process the server faces the following conditions: * The server needs the uploaded file early in the submission process so it can analyze it and adjust the questions it asks later (e.g. prefill the command line for patches, only present 64 bit VMs for 64 bit executables, etc.). * There is no job yet to store the user-provided file. So it is stored in a temporary 'staging' area and then moved into place when the job is created. * The user can abandon the submission process at any time which causes the temporary files he uploaded to be orphaned. To deal with this issue the server has a garbage collecting mechanism. * To avoid interference between users if they upload files that have the same name the temporary filename is prefixed with a per-user string. * However nothing prevents a collision in the staging area starts two job submissions at the same time for the same file. This is what happens in the steps above. That last point is somewhat intentional as it limits the accumulation of orphaned files if a user abandons a submission only to pick it up a bit later. But getting a broken job is wrong in any case. -- 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.

2 2

[Bug 39417] New: Display duration instead of 'Ended' time
by wine-bugs＠winehq.org May 3, 2021

May 3, 2021

https://bugs.winehq.org/show_bug.cgi?id=39417 Bug ID: 39417 Summary: Display duration instead of 'Ended' time 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: --- For Jobs and Tasks the website shows the 'Ended' time but this is not very practical. Developers would likely be much more interested in the time it took to run the job/task. So all this does is force them to do that calculation themselves. The (slight) difficulty is mostly that the relevant pages use a base class that builds the HTML from all the selected fields. So the framework would need to be modified to let subclasses either provide their own 'virtual columns' with the corresponding header and content. Alternatively, in this case we could make do with letting them replace the column's header and content. -- 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.

2 2