wine-bugs November 2021

wine-bugs@winehq.org

1 participants
4857 discussions

[Bug 48148] New: WinRAR x86 crashes when trying to view very large files
by WineHQ Bugzilla 14 Apr '22

14 Apr '22

https://bugs.winehq.org/show_bug.cgi?id=48148 Bug ID: 48148 Summary: WinRAR x86 crashes when trying to view very large files Product: Wine Version: 4.20 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs(a)winehq.org Reporter: aros(a)gmx.com Distribution: --- Steps to reproduce: 1. Navigate to any large file (>4GB). 2. Hit Alt + V (Commands -> View File) Assertion failed: ~para->member.para.nFlags & MEPF_REWRAP, file caret.c, line 232 -- 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 50322] New: REDEngineErrorReporter.exe Page fault while trying to print unimplemented function message to console.
by WineHQ Bugzilla 13 Apr '22

13 Apr '22

https://bugs.winehq.org/show_bug.cgi?id=50322 Bug ID: 50322 Summary: REDEngineErrorReporter.exe Page fault while trying to print unimplemented function message to console. Product: Wine Version: 6.0-rc2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: hibbsncc1701(a)gmail.com Distribution: --- Created attachment 68905 --> https://bugs.winehq.org/attachment.cgi?id=68905 Backtrace of bug. Crash occurs when attempting to debug print an unimplemented function call when launching Cyberpunk2077 (GOG version) using dxvk with wine's dxgi.dll. Triggered by REDEngineErrorReporter.exe and not the game itself. -- 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 3

[Bug 45023] New: TestBot Object Relational Mapper issues
by wine-bugs＠winehq.org 13 Apr '22

13 Apr '22

https://bugs.winehq.org/show_bug.cgi?id=45023 Bug ID: 45023 Summary: TestBot Object Relational Mapper issues 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 TestBot implements its own perl Object Relational Mapper (ORM) to access the database. It is implemented by the modules in lib/ObjectModel. The are two main concepts: * Items An Item is an object representing a table row. The classes such as Job, Step and Task all inherit from Item. * Collections A collection represents a table and is thus a collection of Items. To allow for fast access the items are stored in a perl hashtable indexed by their primary key. A Collection may not contain all of the table's rows. For instance a Step Collection only contains the Steps of the parent Job object used to create it. So $Job->Steps is a collection that contains only the $Job steps. The items in a Collection can be further filtered out by specifying that one of their property must be in a set of values. For instance $Jobs->AddFilter("Status", ["queued", "running"]) will cause the $Jobs collection to only return the queued and running jobs. Unfortunately this implementation has a number of limitations and design issues. 1. Care must be taken when creating multiple objects. my $Job1 = $Jobs->Add(); ... Set mandatory fields ... my $Job2 = $Jobs->Add(); ... Set mandatory fields ... # Here $Job1 != $Job2 $Jobs->Save(); Only $Job2 got saved to the database! The reason is that a Job's primary key is an auto-increment field. So the Job Id is set when it is saved to the database. Thus when created in memory that field is unset and an empty string is used when adding it to the $Jobs items hashtable. Thus $Job2 overwrites $Jobs->{Items}->{""} and is the only one that gets saved. Note that there is no such issue for Steps for instance because their key is not an auto-increment field and is set as soon as the object is created. Fortunately the workaround is simple: systematically save an object before creating the next one but the difference in behavior between $Jobs->Add() and $Steps->Add() is error prone. 2. Auto-increment values on new Items are not ignored If an auto-increment field is modified on an object, that value is used when saving the object to the database. This means fixing the previous issue is not as simple as setting $Job->Id(--$Unique): handling of auto-increment fields also needs to be changed when saving new objects. 3. Items retrieved from Detailref collections are missing fields 'Detailref' properties are used to represent 'one to many' relationships. They are used for instance to access the Steps that belong to a Job: my $Step = $Job->Steps->GetItem(1); Here Steps is a collection that gets created based on the information of the job's DetailRef property. However objects gotten in this way don't provide access to all of the corresponding database fields. In the case of Steps, although the Steps table has a JobId column, the $Step->JobId property does not exist. This presents difficulties in a number of cases such as when trying to figure out the name of the directory containing the Step's files since it is called "jobs/$JobId/$StepNo" (see Step::GetDir()). It also means there is no $Step->Job property to get back to the parent Job object (this would also cause a perl reference loop which would be troublesome). The reason for this issue is that when a Collection or Item has a parent object (called a 'master' object in the TestBot ORM) the parent's foreign key fields (Step.JobId here) are stored separately in a 'master cols' structure and are thus not accessible through the normal field methods. 4. "Child" objects can only be accessed from their parent Any collection referenced through a Detailref property can only be accessed through the corresponding 'parent' object. This is the case for the Steps collections. The only way to get a collection of steps is through $Job->Steps and this only returns the steps that belong to $Job. So it's not possible to iterate over all the rows in the Steps table. There is a (somewhat incorrect) workaround for this for the Records table. This involves having the CreateRecords() method picking one of two PropertyDescriptors list depending on the presence of a parent object. However the corresponding Record objects have an extra field compared to the ones obtained through $RecordGroup->Records: this time the foreign key identifying the parent object is accessible since it's not not tucked away in the 'master cols' structure. This is not an issue unless you start mixing both types of objects, for instance through scope inheritance. 5. The 'master cols' terminology is ambiguous. It's never clear if a 'master cols' method treats $self as a child of its parent object, or as the parent to other child objects. * $Step->GetMasterCols() treats $Step as a child object and returns the key columns of its $Job master object, that is (JobId). * Similarly $Step->MasterKeyChanged() means the parent object's key changed, so here that the value of $JobId changed (which happens on new objects due to the auto-increment field btw). * Despite the unchanged 'Master' moniker, $Step->GetMasterKey() considers $Step to be the master object of the Tasks it contains and thus includes the step's key in the returned columns. This means $Step->GetMasterKey() returns (JobId, StepNo). * Despite not having the 'Master' moniker, $Step->GetFullKey() works the same as $Step->GetMasterKey() but returns the column values as a single string '$JobId#@#$StepNo'. 6. Filters on Detailref collections It's possible to put a filter on a collection to only get a subset of the corresponding rows. For instance $Job->Steps->AddFilter('Status', ['queued']) ensures that one will only get the queued steps of $Job. But Detailref collections are stored as a field of the Item they belong to. This means $Job->Steps always returns the same collection object. So once a piece of code has set a filter on it, to only return 'queued' steps for instance, all other parts of the code will only get the 'queued' steps, no matter what they need. Also there is no method for cloning a collection (so one cannot do $Job->Steps->Clone()->AddFilter()), or for removing a filter. For instance: $Job->Steps->AddFilter('Status', ['queued']); ... # Here UpdateStatus() will only take into account the queued steps! $Job->UpdateStatus(); Note also that it's not entirely trivial to work around. It's tempting to do something like: $Job->Steps->AddFilter('Status', ['queued']); ... # Make sure the database contains an up-to-date view of all the Steps and # Tasks in $Job. $Job->Save(); # Then create a new job object from the database my $TmpJob = CreateJobs()->GetItem($Job->Id); # Now we can update the status without fearing bad filters. $TmpJob->UpdateStatus(); # But here $Job->Status could still be wrong so any code that still uses # $Job will be lead astray. So update $Job. $Job->Status($TmpJob->Status) # But that still leaves out every Step and Task object referenced by $Job # Also saving $Job will save $Job->Status, again. What could go wrong? 7. Filters vs. loading from the database Once a collection has been loaded from the database, adding a filter to it has no effect. That's because filtering happens by tweaking the SQL query and changing the filter does not mark the collection for reloading. Again this issue is made more severe because of the way Detailref collections are handled. If a piece of code has caused the $Job->Steps collection to be loaded, then adding a filter elsewhere will have no effect. For instance: $Job->UpdateStatus(); # calls $Job->GetItems(), loading it from DB ... $Job->Steps->AddFilter('Status', ['queued']); foreach my $Step ($Job->Steps->GetItem()) # Here we will get all steps, not just the queued ones! 8. No "or" operator in filters Originally the filters only allowed one to request that a field be in a set of admissible values. This was extended to allow requesting for a field to be less than, greater than or like some value. However it is still not possible to use an "or" operator in filters. So for instance one cannot retrieve all Steps that completed recently or correspond to a WineTest run (WHERE Ended > 5 minutes ago OR User == 'batch'). 9. No Itemref support for multiple key fields. A Task has a VMName field which is a foreign key referencing a VM. Through the use of an Itemref property one can directly access the VM with $Task->VM. But we cannot do the same thing for steps. The primary key of a step has two fields, (JobId, No). A step also has a PreviousNo field which identifies the step it depends on. So we would want to be able to access the previous step through $Step->Previous by using an Itemref property: CreateItemrefPropertyDescriptor("Previous", "Previous step", !1, !1, \&CreateSteps, ["JobId", "PreviousNo"]), However this fails with a "Multiple key components not supported" error. Note that for this to work we would also need a way to tell the Itemref that the Step.PreviousNo field should be mapped to Step.No. But there is no way to do so. 10. Collection::GetItem() blindly adds the item to the collection Collections have a GetItem() method that returns an item when given a string containing that object's key. So using the Step example above, if we still have the right $Job->Steps collection accessible, we can easily get the Previous step through: $Job->Steps->GetItem($Step->PreviousNo) However this also adds $Step->PreviousNo to the $Job->Steps collection, regardless of what the filter on that collection is. So when the scheduler analyzes the queued and running steps to figure out whether the one they depend on, $Step->PreviousNo, has completed, it also unwittingly adds the previous step to the $Job->Step collection. So the next iteration on the collection may return completed steps despite expectations. 11. Save order issues The TestBot ORM automatically takes care of saving parent objects before the child objects they contain. In practice, if you create a Job > Step > Task hierarchy you can count on the TestBot ORM to save the Job before saving the Steps that use the JobId as part of their key and so on. But this breaks down for $Step->PreviousNo. There you have to make sure to save the steps in the right order otherwise you get an SQL error. Similarly deletions must be performed in the right order. Fortunately this is mostly transparent since we only delete whole Jobs and Job::OnDelete() takes care of blanking the Step::PreviousNo fields before recursing. 12. No Order-by support There are a many cases where we retrieve a number of rows from the database and then do a simple alphabetical or numerical sort on them. That's the kind of thing that the database would do much faster than Perl. This is mostly an issue for the activity and statistics web pages because of the number of RecordGroups they handle. So it would be nice to be able to specify an Order-By SQL directive when retrieving the objects. However this would run into the same issues as the filters for Detailref collections with regards to already loaded collections, and GetItem() not knowing where to insert freshly loaded objects. 13. No support for joins There are a few cases where doing a join could be useful. For instance when reporting the activity what we really want is all the Records rows corresponding to a RecordGroup that is less than 12 hours old. For now we have to proceed indirectly: we query all the RecordGroup objects that are less than 12 hours old, take the lowest GroupId we find and then retrieve all the Records that have a Group Id greater than that. A different type of join could also be useful in many other places: currently we first retrieve the jobs and then we do one more SQL request per job to retrieve its steps and then one per step to retrieve the tasks. A join could let us load it all in one request. Fortunately we don't have many jobs so unlike in the activity case this does not have a significant performance impact. 14. Performance Most parts of the TestBot don't have much processing to do so that performance is not an issue (though there is not really any hard data). Things are different for the activity and statistics page. The statistics page is the worst and generating it takes over a dozen seconds. That's annoying because of the load it puts on the TestBot web server. It's also really long for a mere couple dozen thousand Records. Not all of it comes from the ORM but over 50% of it does. There are some relatively obvious paths for improvement. For instance accessing a field like $Job->Ended causes the ORM to loop over all of a job's property descriptors until it finds one called 'Ended', and then it returns the value from a hash table. It should be possible to make it so that most of the time the value is returned directly from the hash table. Detailref and Itemref properties have their own hash tables and so must be handled separately. But hat could likely also be changed. -- 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 51538] New: Control can no longer launch from an ntfs partition
by WineHQ Bugzilla 13 Apr '22

13 Apr '22

https://bugs.winehq.org/show_bug.cgi?id=51538 Bug ID: 51538 Summary: Control can no longer launch from an ntfs partition Product: Wine-staging Version: 6.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: ritalat(a)fastmail.com CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- Created attachment 70377 --> https://bugs.winehq.org/attachment.cgi?id=70377 control console output I have a shared NTFS partition that I have used between Arch Linux and Windows 10 for a few years now. I have been able to play games such as Control in the past from it. Now multiple games fail to launch from that partition with similar "err:module:import_dll Library X not found" errors. Copying the entire game to a ext4 partition fixes the issue. -- 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 11

[Bug 52102] New: outSPOKEN 3.0 demo crashes after error "Accessing unknown VxD 3167"
by WineHQ Bugzilla 12 Apr '22

12 Apr '22

https://bugs.winehq.org/show_bug.cgi?id=52102 Bug ID: 52102 Summary: outSPOKEN 3.0 demo crashes after error "Accessing unknown VxD 3167" Product: Wine Version: 6.22 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: alexhenrie24(a)gmail.com Distribution: --- Created attachment 71122 --> https://bugs.winehq.org/attachment.cgi?id=71122 Console output Steps to reproduce: 1. Delete ~/.wine or move it to another location. 2. Create a new Wine bottle with the command `WINEARCH=win32 wine winecfg` and set the Windows version to 95 or 98. 3. Run `wine osw30demo.exe` to install outSPOKEN. The setup wizard will not complete until you select a speech synthesizer from the list. When the wizard asks which COM port the speech synthesizer is connected to, select "Internal". 4. Run `wine 'C:\Osw\OSW.EXE'` to start outSPOKEN. outSPOKEN crashes immediately. Console output is attached. $ sha256sum osw30demo.exe 89ae45e689e35b0618b1b4fa27fb0c3e5b854461391100e2dc1742395ffa77b6 -- 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 8

[Bug 51983] New: foobar2000 v1.5.1+ crashes on startup with Wine v6.6+ with Windows version set to "Windows 10"
by WineHQ Bugzilla 12 Apr '22

12 Apr '22

https://bugs.winehq.org/show_bug.cgi?id=51983 Bug ID: 51983 Summary: foobar2000 v1.5.1+ crashes on startup with Wine v6.6+ with Windows version set to "Windows 10" Product: Wine Version: 6.6 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: the.derivative.of.calculus(a)gmail.com Distribution: --- Created attachment 70970 --> https://bugs.winehq.org/attachment.cgi?id=70970 foobar2000 1.5.1 crash with windows 10 profile I had an old version of foobar2000 that I had never got around to upgrading, so I only recently came across this issue. Looking online it appears that a few people ran into it starting with v6.6, and it still exists with v6.20 (and as far as I can tell no one bothered to report it): https://forum.winehq.org/viewtopic.php?t=35166 https://hydrogenaud.io/index.php?topic=54933.525 When you start foobar2000 with Windows version set to "Windows 8.1" or below it runs normally. However, if you use "Windows 10" the application window briefly appears before the whole application crashes. Testing it, this affects foobar2000 v1.5.1+ Looking through foobar2000's changelog: https://www.foobar2000.org/changelog The one thing mentioning Windows 10 is: Reworked integration with Windows 10 Universal Volume Control. Enabled by default once again. Looking at the error messages: 0024:fixme:combase:RoGetActivationFactory (L"Windows.Media.Playback.BackgroundMediaPlayer", {00000035-0000-0000-c000-000000000046}, 0032F9E4): semi-stub 0024:err:combase:RoGetActivationFactory Failed to find library for L"Windows.Media.Playback.BackgroundMediaPlayer" I'm wondering if there's a regression with Wine's handling of media controls for Windows 10 or equivalent. -- 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 8

[Bug 50526] New: ConEmu wineconsole Ctrl+m has different behavior
by WineHQ Bugzilla 12 Apr '22

12 Apr '22

https://bugs.winehq.org/show_bug.cgi?id=50526 Bug ID: 50526 Summary: ConEmu wineconsole Ctrl+m has different behavior Product: Wine Version: 6.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: inseng Assignee: wine-bugs(a)winehq.org Reporter: adrianekaleksander(a)gmail.com Distribution: --- Cmd on Windows: Ctrl+M moves the cursor to the next line (ENTER key) On wine: Ctrl+M shows ^M 1.Open wineconsole 2.Press ctrl+m -- 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 5

[Bug 52082] New: Ace Ventura the CD-ROM game, page fault on read access
by WineHQ Bugzilla 12 Apr '22

12 Apr '22

https://bugs.winehq.org/show_bug.cgi?id=52082 Bug ID: 52082 Summary: Ace Ventura the CD-ROM game, page fault on read access Product: Wine Version: 5.8 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: guillere(a)adinet.com.uy Distribution: --- Created attachment 71094 --> https://bugs.winehq.org/attachment.cgi?id=71094 backtrack Ace Ventura CD-ROM game hungs in the game start after 10 seconds confirmed in Ace Ventura CDROM (Latin America) and Ace Ventura CDROM (German) git bissect get this bug is introducced in commit 6b4de5102734de7dd77222bdb74f8cf5181022d8 This bug is a game bug (bad memory read)... but the game works OK in win 3.11 up to win xp (if i remember correctly) commit 6b4de5102734de7dd77222bdb74f8cf5181022d8 ntdll: Don't use a custom alignment for large heap blocks. -- 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 9

[Bug 51968] New: Winaero WEI Tool: Crash due to C:\windows\performance\winsat\datastore missing
by WineHQ Bugzilla 12 Apr '22

12 Apr '22

https://bugs.winehq.org/show_bug.cgi?id=51968 Bug ID: 51968 Summary: Winaero WEI Tool: Crash due to C:\windows\performance\winsat\datastore missing Product: Wine Version: 6.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: fox2code(a)gmail.com Distribution: --- Created attachment 70953 --> https://bugs.winehq.org/attachment.cgi?id=70953 Logs of the app crash Some apps crashes due to the assumption that C:\windows\performance\winsat\datastore exists It's affecting this app: https://winaero.com/winaero-wei-tool/ Creating the folder manually allow the application to launch correctly Note: I already have a WIP patch that I will submit to wine to fix this issue -- 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 5

[Bug 51938] New: Safe Exam Browser (SEB) won't install even with winetricks dotnet472
by WineHQ Bugzilla 12 Apr '22

12 Apr '22

https://bugs.winehq.org/show_bug.cgi?id=51938 Bug ID: 51938 Summary: Safe Exam Browser (SEB) won't install even with winetricks dotnet472 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: bammgabriana(a)gmail.com Distribution: --- Created attachment 70908 --> https://bugs.winehq.org/attachment.cgi?id=70908 Screenshot of "Setup Failed" message explaining the possible error Safe Exam Browser (SEB) is a kiosk-like application integrated in Moodle to let students take an online exam in full-screen mode. It requires that the student install the SEB browser on his computer, which requires .NET Framework 4.72 and VC++ 2015-2019 Redistributable runtimes. Unfortunately, the setup program won't let you install. Even if the requirements are installed via winetricks, the installer still complains that they are missing and setup fails. To install, download the file "SEB_3.3.1.388_SetupBundle.exe" from here: https://sourceforge.net/projects/seb/files/seb/SEB_3.3.1/ To reproduce: $ rm -rf ~/.wine $ wineboot $ winetricks -q dotnet472 vcrun2019 $ wine SEB_3.3.1.388_SetupBundle.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.

1 14

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-bugs November 2021