[Bug 59651] New: Greenfish Icon Editor errors on launch with MDB error: Input/Output error
http://bugs.winehq.org/show_bug.cgi?id=59651 Bug ID: 59651 Summary: Greenfish Icon Editor errors on launch with MDB error: Input/Output error Product: Wine Version: 11.6 Hardware: x86-64 URL: https://greenfishsoftware.org/gfie.php OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@list.winehq.org Reporter: tobbi.bugs@googlemail.com % ./wine --version wine-11.6-112-g504683b22d3 % openssl sha256 gfie4.5.zip SHA2-256(gfie4.5.zip)= 7cc9b150b3e09e1d59b162fc5aa1073387c91003f1dd6e75749067ae4af3f533 Steps to reproduce: 1. Extract the zip file and start gfie.exe using wine. Expected results: Program starts. Actual results: Error message: MDB error: Input/Output 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.
http://bugs.winehq.org/show_bug.cgi?id=59651 Bernhard Übelacker <bernhardu@mailbox.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bernhardu@mailbox.org --- Comment #1 from Bernhard Übelacker <bernhardu@mailbox.org> --- Created attachment 81048 --> http://bugs.winehq.org/attachment.cgi?id=81048 debugging notes Hello, I tried to find some more details. It looks to me it tries to open and map this file: "C:\\Greenfish Icon Editor Pro 4.5\\data\\shaders.lmdb" But a call to NtMapViewOfSection fails because of an input size of 0xffffffff, which exceeds some limit in virtual_map_section, therefore returns STATUS_INVALID_VIEW_SIZE. Hacking virtual_map_section to allow this size makes the application getting over that mapping, but hangs later. Can not yet tell if the size is the problem, or if NtMapViewOfSection should accept that size. -- 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=59651 --- Comment #2 from Bernhard Übelacker <bernhardu@mailbox.org> --- Unfortunately could not really follow this 0xffffffff back to a specific API call. But these MDB files may be a "Lightning Memory-Mapped Database". https://www.symas.com/symas-embedded-database-lmdb The observed opening sequence may match around this publicly available source code: https://github.com/LMDB/lmdb/blob/mdb.master3/libraries/liblmdb/mdb.c#L5079 So maybe building and running the tests of this module may show the same issue, while giving a chance to debug with symbolic debug informations ... -- 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=59651 --- Comment #3 from Bernhard Übelacker <bernhardu@mailbox.org> --- Created attachment 81060 --> http://bugs.winehq.org/attachment.cgi?id=81060 reproducer.c As I could not find an issue with the size_ptr input, it tried to create a minimal reproducer. An executable create from reproducer.c behaves different in Wine and Windows, example output inside the file. -- 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=59651 --- Comment #4 from Bernhard Übelacker <bernhardu@mailbox.org> --- Created attachment 81063 --> http://bugs.winehq.org/attachment.cgi?id=81063 Added a test to ntdll:virtual. Now the hard part, how to change Wine to succeed the test? -- 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=59651 Tobias (:Tobbi) Markus <tobbi.bugs@googlemail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |ntdll --- Comment #5 from Tobias (:Tobbi) Markus <tobbi.bugs@googlemail.com> --- Moving to ntdll component as per affected source code. -- 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=59651 --- Comment #6 from Tobias (:Tobbi) Markus <tobbi.bugs@googlemail.com> --- Created attachment 81121 --> http://bugs.winehq.org/attachment.cgi?id=81121 ntdll: Handle 0xffffffff flag for size_ptr properly in virtual_map_section -- 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=59651 Tobias (:Tobbi) Markus <tobbi.bugs@googlemail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #81121|0 |1 is patch| | Attachment #81121|application/mbox |text/plain mime type| | -- 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=59651 --- Comment #7 from Bernhard Übelacker <bernhardu@mailbox.org> --- Hello, your patch from comment 6 handles only a value of 0xffffffff, but the test from comment 4 should show also other value show this behaviour. However, using this workaround and WINEDEBUG=+pid,+seh leads here not to a crash, but shows several calls to OutputDebugStringA. The last one showing: "Putting shader 47D8511AACA17C6577A1D8EC27E7A8D1 into cache" This my be a hint our shaders.lmdb is stil not opened correctly, because of the workaround. I wonder if this 0xffffffff is used here as the size of the memory mapping, but the file size stays at the few bytes, it got written initially. And windows increases the file size when the mapped memory gets written. -- 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.
participants (1)
-
WineHQ Bugzilla