[Bug 58952] New: Zbrush (2022.06) Decimation Master plugin does not function correctly in .exe or .dll mode
http://bugs.winehq.org/show_bug.cgi?id=58952 Bug ID: 58952 Summary: Zbrush (2022.06) Decimation Master plugin does not function correctly in .exe or .dll mode Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: brandon(a)garagebay9.com Distribution: --- Program: Zbrush 2022.06 (this is not the latest release, but it is the last release with a permanent license version, so it is in heavy use) Issue: the Decimation Master plugin is a key workflow component that processes extremely dense meshes at the conclusion of the sculpting process, and once they are pre-processed, it provides a dynamic interface to the artist to reduce the mesh in vertex / poly count from millions or more to tens of thousands (which makes the outputted meshes practical to upload, use in game engines, or 3D print). Decimation Master has two compatibility modes, a separate .exe and a .dll mode. Currently, .exe mode gets stuck in the mid 90% range when pre-processesing meshes, although it can be cancelled with Esc and the Zbrush remains otherwise usable. .dll mode successfully pre-processes a mesh, but will crash zBrush with an "unrecoverable error" prompt when the button is pressed to actually decimate the mesh to the target density. As a result, neither are working, and one fully hard-crashes Zbrush with 100% reliability. NOTE: THIS ISSUE IS NOT PRESENT IN THE 8.26-GE RELEASE OF THE WINE-GE FORK BY GLORIOUS EGGROLL, AVAILABLE FOR INSPECTION HERE:https://github.com/GloriousEggroll/wine-ge-custom, WHICH MAY HELP IN IDENTIFYING THE SPECIFIC CAUSE OS: Debian 13 / Trixie Kernel: 6.16.3+deb13-amd64 Wine version: 10 Stable, 10.18 Staging (also present in prior Stable and Staging versions, per my own experience and discussion on ZbrushCentral regarding Zbrush on WINE) I attempted to capture this in a log using WINEDEBUG = +heap,+err but was unsuccessful. I'm happy to help in tracking this down further if someone has specific settings and procedures they want me to run log captures with. -- 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=58952 --- Comment #1 from Brandon T <brandon(a)garagebay9.com> --- Created attachment 79656 --> http://bugs.winehq.org/attachment.cgi?id=79656 Crash log of Decimation Master Captured via described test process, in Wine 10.15 -- 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=58952 --- Comment #2 from Brandon T <brandon(a)garagebay9.com> --- I have managed to catch an in-depth crash log of DecimationMaster.exe (the plugin in question when running in .exe mode). I have not previously gotten in-depth crash data like this. This was triggered by doing the following: - subdividing a mesh past approx 2m points - setting Decimation Master to .dll mode (which allows it to successfully preprocess a mesh; .exe mode sticks when trying to preprocess) - completing preprocessing - setting Decimation Master to .exe mode - attempting to Decimate to a low (~50k points) vertex count target using the existing preprocess cache data Switching between .dll and .exe mode halfway through is *not* the normal workflow for the plugin, but at least we have something to work with now. -- 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=58952 --- Comment #3 from Brandon T <brandon@garagebay9.com> --- More investigation by Claude has pinpointed that this is actually caused by an inherent flaw in Decimation Master itself, one that Windows either shims or somehow bypasses, preventing it from crashing or malfunctioning in a native Windows environment. Wine is simply exposing a previously undetected flaw. ----- Summary: "The writer and reader agree on the layout. The writer (around 0x140017c2a) and the reader (0x1400181e0) use the same sequence: a 4-byte count n1, then (n1+7)/8 bytes of bitmap, then a 4-byte field at +0x278, then a 4-byte count n2 (the bit count at +0x2b0), then (n2+7)/8 bytes of bitmap, then a 4-byte field at +0x2b8. A correctly written file should give the reader the true n2. The reader only ends up with n2 ≤ 0 if the file holds zero there or the reads are misaligned. There are two width bugs, not one. Both count reads have the same pattern: a 4-byte fread into a stack slot, followed by an 8-byte load (mov 0x38(%rsp),%r12). Count1 at VA 0x140018b14 (file offset 0x17f14) is still unpatched. Count2 at VA 0x140018ba1 (file offset 0x17fa1) is the site your earlier patch changed. The other 8-byte loads from 0x38(%rsp) in this function read pointers or the FILE*, so they’re fine. The earlier patch fixed only count2. Why patching count2 changed the behavior. reserve sign-extends the low dword in both builds, so the allocation decision is identical. The only difference is the fread length. The unpatched build uses all 64 bits, and the patched build uses only the low 32. With n2 = 0, the patched build reads zero bytes, the mask is empty, and decimation has nothing to do. That matches the 0.0% stall. The unpatched build’s stale upper dword makes the length huge, so the copy runs from the static sentinel at .data (0x14005e041) into .pdata at 0x14005f000, which is read-only. That matches the crash. What this means for Wine. The 8-byte load is a bug in DM’s own binary, and Windows runs the same instruction. Whether it bites depends on what was left at rsp+0x3c by earlier code. That stale value comes from the CRT and kernel code Wine runs, so Wine’s version can change it. But there is no Wine arithmetic bug here to patch. The durable fix is in the DM binary, and a Wine change would only work by accident. Bug 58952 should probably be reframed around this." ----- Ultimately, the following change to a copy of the .exe resulted in correct behavior and full function during test procedures that previously were a 100% consistent guaranteed crash. PATCH PROCEDURE FOR 2022.06 DecimationMasterApp.exe: Set DecimationMaster preferences to .exe mode and save prefs. (Make a backup copy of DecimationMasterApp.exe) Verify that: xxd -s 0x17f14 -l 5 DecimationMasterApp.exe xxd -s 0x17fa1 -l 5 DecimationMasterApp.exe show 4c 8b 64 24 38 printf '\x44' | dd of=DecimationMasterApp.both.exe bs=1 seek=$((0x17f14)) conv=notrunc printf '\x44' | dd of=DecimationMasterApp.both.exe bs=1 seek=$((0x17fa1)) conv=notrunc To verify correct changes: xxd -s 0x17f14 -l 5 DecimationMasterApp.exe xxd -s 0x17fa1 -l 5 DecimationMasterApp.exe Both should now show 44 8b 64 24 38 ----- All this being the case, this bug can either be closed because it's not strictly a Wine problem, or if Wine wants to investigate why this DOESN'T crash in a native Windows environment and match compatibility behavior as a feature goal, it can be left open. -- 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 (2)
-
WineHQ Bugzilla -
WineHQ Bugzilla