[Bug 52819] New: Smart-House Configuration Tool v1.25: crashes when configuring serial port
https://bugs.winehq.org/show_bug.cgi?id=52819
Bug ID: 52819 Summary: Smart-House Configuration Tool v1.25: crashes when configuring serial port Product: Wine Version: 3.21 Hardware: x86-64 URL: https://www.smartbuilding.dk/software/z_controller/Set up_SmartHouse%20125.zip OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: oleaut32 Assignee: wine-bugs@winehq.org Reporter: chroxvi@gmail.com CC: z.figura12@gmail.com Regression SHA1: 77b4391d442e927a2a59b5afb244355b0634aaa Distribution: Fedora
Created attachment 72199 --> https://bugs.winehq.org/attachment.cgi?id=72199 Terminal output logs and bisect result
Steps to reproduce:
1. Download and unzip the Carlo Gavazzi Smart-House Tool v1.25 from https://www.smartbuilding.dk/software/z_controller/Setup_SmartHouse%20125.zi... ("Setup_SmartHouse 125.exe" sha256sum: 5fc57b031e232fbb0c40f157ec133a324d74c1fe52806baf0172458aadab6067) 2. Install the tool using: - WINEARCH=win32 WINEPREFIX=~/.smarthouse_regtest wine winecfg - WINEPREFIX=~/.smarthouse_regtest winetricks -q vb6run - WINEPREFIX=~/.smarthouse_regtest wine Setup_SmartHouse\ 125.exe (click through the install GUI in its default configuration) 3. Run the tool: - WINEPREFIX=~/.smarthouse_regtest wine ~/.smarthouse_regtest/drive_c/Program\ Files/Carlo\ Gavazzi/smart-house/smart-house\ 1.25/smart-house\ Tool\ 0125.exe 4. Open the menu: "Options" --> "Serial Port" 5. Program crashes
This is a regression. The Smart-House tool (following the above procedure) works with no errors using Wine 3.20.
Using Wine 3.21, it crashes as soon as the program is executed. An error message is displayed. It contains the text: "Run-time error ‘-2147220990 (80040202)’: Automation error".
Using Wine 7.6, an error is shown when the program is executed, but the program starts. It contains the text: "Run-time error ‘-2147417839 (80010111)’: Method ‘~’ of object ‘~’ failed". When opening the menu "Options" --> "Serial Port", the application crashes. An error message is displayed. It contains the text: "Run-time error ‘-2147418105 (80010007)’: Automation error"
Using latest master (wine-7.6-152-g07f22e20d73), the program installer crashes. However, executing the program with wine-7.6-152-g07f22e20d73 using a wine prefix installed with Wine 7.6 behaves identically to Wine 7.6.
I did a bisect between Wine 3.20 and 3.21, which gave 77b4391d442e927a2a59b5afb244355b0634aaa as the first bad commit.
https://bugs.winehq.org/show_bug.cgi?id=52819
Christian Schou Oxvig chroxvi@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, hardware, | |regression
https://bugs.winehq.org/show_bug.cgi?id=52819
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1|77b4391d442e927a2a59b5afb24 |077b4391d442e927a2a59b5afb2 |4355b0634aaa |44355b0634aaa
https://bugs.winehq.org/show_bug.cgi?id=52819
--- Comment #1 from Zeb Figura z.figura12@gmail.com --- Created attachment 72260 --> https://bugs.winehq.org/attachment.cgi?id=72260 HACK: oleaut32: Work around a double free.
The application is broken. It calls the following method typelib-marshalled:
HRESULT Write( [in] unsigned char ucAddress, [in] unsigned char ucFunctionCode, [in] VARIANT vData, [in] unsigned char ucExpectedDataCount, [in] long lCookie);
It calls the method remotely with a VT_ARRAY variant parameter, and the stub calls VariantClear() on that parameter. This results in a double free when the RPC runtime subsequently tries to free the variant again.
Because the variant is passed by value, we have to copy it from the unmarshaling buffer onto the stack, so the fact that VariantClear() clears the VT doesn't prevent the double free. It's possible that the program even blits the variant again; I can't immediately tell.
Most likely the old typelib marshaller got away with this because the subsequent memory corruption just happened not to immediately touch anything critical.
I don't see a good way to fix this. The attached hack will help obviously, but that's not suitable for upstream. We can't reliably avoid memory corruption from a double free, and we can't avoid blitting the variant either. The only possible ideas I have are:
[1] It's possible that call isn't supposed to happen at all. I see the following in +ole after the offending call:
0020:011c:trace:ole:create_errorinfo_SetSource 02FE2E4C, L"MGComDrv.ComDriver.1". 0020:011c:trace:ole:create_errorinfo_SetDescription 02FE2E4C, L"CSerialPort::Write: Open must be called before Write".
which suggests that the call to Write() [or the error return? it seems to return S_OK, though...] is invalid and might be triggered by a bug in Wine.
[2] The RPC happens within a single process, which is odd. It's possible that we shouldn't be marshalling anything.
https://bugs.winehq.org/show_bug.cgi?id=52819
--- Comment #2 from Zeb Figura z.figura12@gmail.com --- (In reply to Zeb Figura from comment #1)
[2] The RPC happens within a single process, which is odd. It's possible that we shouldn't be marshalling anything.
Yeah, so it's marshalling from the implicit MTA to an STA (i.e. the STA is the caller). That means we really don't need to be using named pipes, but whatever.
Best I can imagine is that maybe rpcrt4 doesn't marshal [in] pointers in-process. I don't think that's ever been tested, though, and I'm not particularly hopeful. In all likelihood this works on Windows just by chance.
https://bugs.winehq.org/show_bug.cgi?id=52819
--- Comment #3 from Zeb Figura z.figura12@gmail.com --- (In reply to Zeb Figura from comment #2)
Best I can imagine is that maybe rpcrt4 doesn't marshal [in] pointers in-process.
This doesn't seem to be true in general, and it wouldn't help anyway, because what's getting double-freed is the safe array pointer itself.
https://bugs.winehq.org/show_bug.cgi?id=52819
--- Comment #4 from Christian Schou Oxvig chroxvi@gmail.com --- Thanks for looking into this!
The technical details are way beyond my understanding, but I can confirm that the patch seems to solve the problem. I have built Wine 7.7 with the patch applied, and it allows me to run the application and communicate with my Smart-House controller (the thing that is configured using the Smart-House Configuration Tool).
I wouldn't be surprised if the application is broken in many ways. It has always seemed a bit shaky to me. Unfortunately, one has to use this tool to configure the Gen 1 Smart-House controller - there are no other options.
It seems unlikely that Carlo Gavazzi is going to fix the application as long as it keeps working on Windows. Amazingly, this application from 2009 runs on Windows 7/10/11.
If you have no more ideas for a fix, I guess I am stuck with compiling my own version of Wine with the hack/patch applied - or use Windows. In that case, I think we can close this bug as a "won't fix".
However, if you do come up with a fix or have anything you would like me to test, please feel free to reach out.
-
WineHQ Bugzilla