[Bug 51139] New: Application T@X 2021 freezes when trying to transmit data to Elster (German Tax Application)
https://bugs.winehq.org/show_bug.cgi?id=51139
Bug ID: 51139 Summary: Application T@X 2021 freezes when trying to transmit data to Elster (German Tax Application) Product: Wine Version: 6.8 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: [email protected] Reporter: [email protected] Distribution: ---
T@X20XX can be used with wine since years. This year it apparently worked as usual, with one frustrating exception: when trying to transfer the entire documetation to the finance office at the end the application freezes and does noting any more. Unfortunately no error shows in the logs when starting wine with a corresponding debug option (WINEDEBUG=+relay, I hope this is ok ...). I have 32 GByte of logging code what is meaningless to upload - but no "real" error message inside.
"top" shows 100% CPU - load by the wine process stman.exe. Messages show like:
01b8:Call ntdll.RtlAllocateHeap(00220000,00000000,00000024) ret=089a10d6 01b8:Ret ntdll.RtlAllocateHeap() retval=3ec3bbe0 ret=089a10d6 01b8:Call ntdll.RtlAllocateHeap(00220000,00000000,00000024) ret=089a10d6 01b8:Ret ntdll.RtlAllocateHeap() retval=2f24da98 ret=089a10d6 01b8:Call KERNEL32.HeapFree(00220000,00000000,2f24da98) ret=0899e7eb 01b8:Ret KERNEL32.HeapFree() retval=00000001 ret=0899e7eb 01b8:Call KERNEL32.HeapFree(00220000,00000000,3ec3bbe0) ret=0899e7eb 01b8:Ret KERNEL32.HeapFree() retval=00000001 ret=0899e7eb
in fast sequence and this:
01b8:Call ntdll.RtlAllocateHeap(00220000,00000000,00000014) ret=6be509ba 01b8:Ret ntdll.RtlAllocateHeap() retval=31991020 ret=6be509ba 0238:Call ntdll._strnicmp(17f9c7cc "Inter-| Receive | Transmit\n",17f9ca0c "eth1",00000004) ret=7eceaa21 01b8:Call ntdll.RtlAllocateHeap(00220000,00000008,00000014) ret=6be7960b 0238:Ret ntdll._strnicmp() retval=00000001 ret=7eceaa21 01b8:Ret ntdll.RtlAllocateHeap() retval=31983590 ret=6be7960b 0238:Call ntdll._strnicmp(17f9c7cd "face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed\n",17f9ca0c "eth1",00000004) ret=7eceaa21 01b8:Call ntdll.RtlAllocateHeap(00220000,00000000,00000020) ret=6be798c1 0238:Ret ntdll._strnicmp() retval=00000001 ret=7eceaa21 01b8:Ret ntdll.RtlAllocateHeap() retval=31992478 ret=6be798c1 0238:Call ntdll._strnicmp(17f9c7d0 "lo: 376975 3786 0 0 0 0 0 0 376975 3786 0 0 0 0 0 0\n",17f9ca0c "eth1",00000004) ret=7eceaa21 0238:Ret ntdll._strnicmp() retval=00000001 ret=7eceaa21 01b8:Call ntdll.RtlAllocateHeap(00220000,00000000,0000000c) ret=6be7974e 0238:Call ntdll._strnicmp(17f9c7ce "eth1: 727671935 574392 0 0 0 0 0 2870 31275660 279019 0 0 0 0 0 0\n",17f9ca0c "eth1",00000004) ret=7eceaa21 01b8:Ret ntdll.RtlAllocateHeap() retval=31991978 ret=6be7974e 0238:Ret ntdll._strnicmp() retval=00000000 ret=7eceaa21
cycling through eth0, eth1, wlan0 etc ...
Finally I see once this at the begin (when the trouble starts ...):
01b8:Ret ntdll.RtlAllocateHeap() retval=3ecc7cc8 ret=089a10d6 01b8:Call KERNEL32.OutputDebugStringW(3ecc7cd8 L"void __thiscall BTS::FormViewerPage::enablePrevNext(void) -1 21\n") ret=67020427 01b8:Call ntdll.RtlInitUnicodeString(0021d000,3ecc7cd8 L"void __thiscall BTS::FormViewerPage::enablePrevNext(void) -1 21\n") ret=7b0125fa 01b8:Ret ntdll.RtlInitUnicodeString() retval=00000082 ret=7b0125fa
with the "void __thiscall entries - but no clue on my behalf. Any support is very much appreciated, most specifically what could I do and how could I better debug the process without flooding my harddisk with trillions (ok, maybe less :-)) of messages.
Thank you very much, take care
Dieter Jurzitza
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #1 from Dieter Jurzitza [email protected] --- I worked on it a little more, reduced the amount of logging information. Basically the problems (might ...) be related to some graphics issues - when pressing the final key on the way to the freeze messages start to show about graphics:
0280:fixme:dxgi:DXGID3D10CreateDevice Ignoring flags 0x20. 0280:fixme:dwrite:dwritefactory_CreateMonitorRenderingParams (00000001): monitor setting ignored 036c:fixme:d3d:state_linepattern_w Setting line patterns is not supported in OpenGL core contexts. 0280:fixme:d2d:d2d_geometry_sink_SetSegmentFlags iface 224E25A0, flags 0 stub! 0280:fixme:dwrite:dwritefactory3_GetSystemFontCollection checking for system font updates not implemented 0280:fixme:d2d:d2d_geometry_sink_SetSegmentFlags iface 3FEF9020, flags 0 stub! 0280:fixme:d2d:d2d_path_geometry_ComputeArea iface 3FEF8F88, transform 0021A7E0, tolerance 2.50000000e-01, area 0021A7DC stub! 0280:fixme:d2d:d2d_geometry_sink_SetSegmentFlags iface 3FEF99C8, flags 0 stub!
shortly after that nothing goes ... Thank you for looking into this, take care
Dieter
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #2 from Dieter Jurzitza [email protected] --- Created attachment 70014 --> https://bugs.winehq.org/attachment.cgi?id=70014 This is the output of wine without extra debug settings ....
https://bugs.winehq.org/show_bug.cgi?id=51139
Dieter Jurzitza [email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- Distribution|--- |SUSE
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #3 from Dieter Jurzitza [email protected] --- Created attachment 70018 --> https://bugs.winehq.org/attachment.cgi?id=70018 Same story on different computer, different logdata, different behavior
This is the same try but on another computer. The thing goes futher until the crash, a messagebox is displayed (however, it does not contain "YES" or "NO" but only stating "A severe error occured, do you want to continue" but there is no choice. If one clicks the cross on the right upper corner the entire application stops. Maybe this helps somewhat. Thank you for looking into this. Best
Dieter Jurzitza
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #4 from Dieter Jurzitza [email protected] --- Created attachment 70037 --> https://bugs.winehq.org/attachment.cgi?id=70037 This is a zipped logfile, already reduced in size. Please see "RaiseException" message ....
See above, zipped logfile. Please see "RaiseException" message until (last line ...) MessageBox where the program asks you whether you want to go on but allows only closing the program.
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #5 from Dieter Jurzitza [email protected] --- If you need me to debug furhter - just tell me. I am more than willing to track this further down but would need some guidance. Thanks
Dieter Jurzitza
https://bugs.winehq.org/show_bug.cgi?id=51139
[email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] | |e
--- Comment #6 from [email protected] --- Apparently it is not the "ELSTER" transmission itself, but previewing the report (which is triggered by the transmission).
The hang can also be triggered by selecting the "ELSTER" -> "Voransicht der ELSTER Steuererklärung STRG+E" ("Preview of ELSTER Tax report").
@dieter - can you confirm?
As the application uses Qt5.15, there is a slight chance the hang comes from some Qt code, not application specific code. Could be possible to use a debug build of Qt5 then.
The previous years version, using Qt5.12, still works fine with wine 6.11.
When the program is started with "MESA_GL_VERSION_OVERRIDE=3.0", the preview at least partially renders, but an error dialog appears, which can't be clicked (paraphrasing from german):
------ Fatal Error. Do you want to continue? ------ There was an error in your application. Do you want to continue anyway? [Yes] [No] ------
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #7 from [email protected] --- This bug apparently affects any tax software from Buhl (current version, for reporting for 2020), also OEM versions like "Steuer 2020" (Aldi), WISO Steuer, ...
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #8 from Dieter Jurzitza [email protected] --- Hello Stefan, yes, I can confirm the behavior you are describing. Depending on the libray - replacements you choose the software differs - however, you cannot preview what is meant to be uploaded towards Elster. Debugging of QT is difficult ... but what I consider possible is to test on a different openSUSE version ... when 15.3 will be out I can give this a try, reporting here -> it should come with a different QT - library. By the way, the window of death shows even without adding "MESA_GL_VERSION_OVERRIDE=3.0" over here and it behaves as you describe - there are no yes / no boxes but you can click on the cross in the upper right order causing the application to die as well ... Thank you for looking into this, in my desperation I was urged to install on M$ and upload from there ... a real shame :-) Take care
Dieter
https://bugs.winehq.org/show_bug.cgi?id=51139
ms [email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected], | |[email protected], | |[email protected], | |[email protected]
--- Comment #9 from ms [email protected] --- the crash or hang is in d2d1.dll.
with Fedora 34's Wine 6.13 this crash occurs by stack overflow: 0104:err:virtual:virtual_setup_exception stack overflow 1220 bytes in thread 0104 addr 0x219dedc2 stack 0x1df0b3c (0x1df0000-0x1df1000-0x1ef0000
haven't had any luck with winedbg, it doesn't show any debuginfo.
building current master 04d52eb83fa5c37cfe1100f435e36c2f78918338 and then linking the new d2d1.dll into /usr, some added debug tracing in geometry.c helped to pin down the problem.
oddly enough, the problem manifests as an infinite loop now, not a stack overflow any more, probably because of different optimization flags.
in d2d_geometry_resolve_beziers() the innermost of 3 while loops never terminates, because there's a point that has x and y both NaN.
the NaN was created in d2d_geometry_add_bezier_line_intersections() because "t" is NaN because it's created by dividing 0 by 0.
unfortunately am rather clueless about graphics, so have only found a workaround "if (isnan(t)) {return TRUE;}" that prevents the crash, the resulting images are obviously wrong as most of the text is missing.
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #10 from ms [email protected] --- Created attachment 70378 --> https://bugs.winehq.org/attachment.cgi?id=70378 debug trace
relevant part of trace that shows both "isnan" checks where it's introduced, and loop at the end that never makes progress
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #11 from ms [email protected] --- Created attachment 70379 --> https://bugs.winehq.org/attachment.cgi?id=70379 patch only for debugging
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #12 from Henri Verbeet [email protected] --- (In reply to ms from comment #9)
in d2d_geometry_resolve_beziers() the innermost of 3 while loops never terminates, because there's a point that has x and y both NaN.
the NaN was created in d2d_geometry_add_bezier_line_intersections() because "t" is NaN because it's created by dividing 0 by 0.
unfortunately am rather clueless about graphics, so have only found a workaround "if (isnan(t)) {return TRUE;}" that prevents the crash, the resulting images are obviously wrong as most of the text is missing.
Does it also help if you replace "if (isnan(t)) return TRUE;" with "if (isnan(t)) t = 0.0f;"?
In any case, from the log it looks like the reason we end up with "t" being NaN is that we have a degenerate (i.e., zero-length) line segment that intersects the curve segment. It would be good to figure out what kind of geometry reproduces that, so that we can add a test case for it.
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #13 from ms [email protected] --- (In reply to Henri Verbeet from comment #12)
Does it also help if you replace "if (isnan(t)) return TRUE;" with "if (isnan(t)) t = 0.0f;"?
i don't see any difference...
it's a couple pages of forms, the rectangles and separator lines appear to be present but the text is missing except for a few lone characters here and there.
of course that could be unrelated to the NaN problem...
there are some more traces about unimplemented methods: 0104:fixme:d2d:d2d_path_geometry_ComputeArea iface 37DC4E90, transform 01EEB644, tolerance 2.50000000e-01, area 01EEB640 stub! 0104:fixme:d2d:d2d_geometry_sink_SetSegmentFlags iface 37E22A60, flags 0 stub! 0104:fixme:d2d:d2d_device_context_DrawGeometry Ignoring stroke style 37DEC698.
In any case, from the log it looks like the reason we end up with "t" being NaN is that we have a degenerate (i.e., zero-length) line segment that intersects the curve segment. It would be good to figure out what kind of geometry reproduces that, so that we can add a test case for it.
will attach a copy-pasted test that reproduces the NaN loop...
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #14 from ms [email protected] --- Created attachment 70383 --> https://bugs.winehq.org/attachment.cgi?id=70383 test to reproduce NaN loop
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #15 from ms [email protected] --- (In reply to ms from comment #13)
(In reply to Henri Verbeet from comment #12)
Does it also help if you replace "if (isnan(t)) return TRUE;" with "if (isnan(t)) t = 0.0f;"?
i don't see any difference...
i mean, no difference between those 2 changes, both fix the loop.
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #16 from Dieter Jurzitza [email protected] --- I tried to guess from ms' patch what is the culprit and tried to change the code a such for futher testing:
--- dlls/d2d1/geometry.c.original 2021-07-20 22:09:28.000000000 +0200 +++ dlls/d2d1/geometry.c 2021-07-30 21:51:31.768045816 +0200 @@ -1708,12 +1708,21 @@ { D2D1_POINT_2F intersection; float t; - + double delta=0; + d2d_point_calculate_bezier(&intersection, p[0], p[1], p[2], s); - if (fabsf(q[1]->x - q[0]->x) > fabsf(q[1]->y - q[0]->y)) - t = (intersection.x - q[0]->x) / (q[1]->x - q[0]->x); - else - t = (intersection.y - q[0]->y) / (q[1]->y - q[0]->y); + if (fabsf(q[1]->x - q[0]->x) > fabsf(q[1]->y - q[0]->y)){ + delta=(q[1]->x - q[0]->x); + if (delta < 1.0e-12) + delta=1.0e-12; + t = (intersection.x - q[0]->x) / delta; + } + else { + delta = (q[1]->y - q[0]->y); + if (delta < 1.0e-12) + delta=1.0e-12; + t = (intersection.y - q[0]->y) / delta; + } if (t < 0.0f || t > 1.0f) return TRUE;
thereby trying to avoid a divide - by - zero situation. However, this did not change anything in regards to the system behavior and the bug apparently remained "as is", wine crashing after messaging that a severe error had occured. I guess my assumption is wrong - would some kind soul direct me to the right place that needs modification? Thank you take care
Dieter
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #17 from ms [email protected] --- (In reply to Dieter Jurzitza from comment #16)
thereby trying to avoid a divide - by - zero situation. However, this did not change anything in regards to the system behavior and the bug apparently remained "as is", wine crashing after messaging that a severe error had occured.
that is the right place, not sure why that doesn't work - maybe delta is still too close to 0?
for the workaround, try either:
- if (t < 0.0f || t > 1.0f) + if (isnan(t) || t < 0.0f || t > 1.0f) return TRUE;
or:
+ if (isnan(t)) { t = 0.0f; } if (t < 0.0f || t > 1.0f) return TRUE;
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #18 from Nikolay Sivov [email protected] --- We'll need a data set to recreate such geometry as a test case, so this could be solved properly.
https://bugs.winehq.org/show_bug.cgi?id=51139
Nikolay Sivov [email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|[email protected] |
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #19 from Dieter Jurzitza [email protected] --- Hello Nikolay, I am 100% with you. Apart of this: a potential divide - by - zero as identified by ms (many thanks for this!) is a bug because this error should be caught. Even if it is impossible to really fix the bug right now because there is insufficient information available I suggest to replace that function by something as ms added or something that I added ... but not to leave it "as is". I am willing to help but would need some guidance in how I could provide what you call a "dataset". Best
Dieter
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #20 from Henri Verbeet [email protected] --- (In reply to Dieter Jurzitza from comment #16)
I tried to guess from ms' patch what is the culprit and tried to change the code a such for futher testing:
--- dlls/d2d1/geometry.c.original 2021-07-20 22:09:28.000000000 +0200 +++ dlls/d2d1/geometry.c 2021-07-30 21:51:31.768045816 +0200 @@ -1708,12 +1708,21 @@ { D2D1_POINT_2F intersection; float t;
- double delta=0;
- d2d_point_calculate_bezier(&intersection, p[0], p[1], p[2], s);
- if (fabsf(q[1]->x - q[0]->x) > fabsf(q[1]->y - q[0]->y))
t = (intersection.x - q[0]->x) / (q[1]->x - q[0]->x);- else
t = (intersection.y - q[0]->y) / (q[1]->y - q[0]->y);
- if (fabsf(q[1]->x - q[0]->x) > fabsf(q[1]->y - q[0]->y)){
delta=(q[1]->x - q[0]->x);if (delta < 1.0e-12)delta=1.0e-12;t = (intersection.x - q[0]->x) / delta;- }
- else {
delta = (q[1]->y - q[0]->y);if (delta < 1.0e-12)delta=1.0e-12;t = (intersection.y - q[0]->y) / delta;- } if (t < 0.0f || t > 1.0f) return TRUE;
thereby trying to avoid a divide - by - zero situation. However, this did not change anything in regards to the system behavior and the bug apparently remained "as is", wine crashing after messaging that a severe error had occured. I guess my assumption is wrong - would some kind soul direct me to the right place that needs modification?
Well, the issue is more with the numerator than with the denominator in that code. E.g. for "t = 1.0f / 0.0f" we'd get "t = +INF", but the rest of the code would handle that fine. The issue is specifically "t = 0.0f / 0.0f" giving us "t = NAN". The right answer in that case is "t = 0.0f". (Or "t = 1.0f"; it doesn't really matter.)
The real question then becomes whether a zero-length segment can legitimately occur here, or if that's simply caused by a bug elsewhere.
(In reply to Nikolay Sivov from comment #18)
We'll need a data set to recreate such geometry as a test case, so this could be solved properly.
Does the testcase from ms in comment 14 (I haven't looked myself yet, but thanks for that) work for you?
https://bugs.winehq.org/show_bug.cgi?id=51139
Henri Verbeet [email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |d2d
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #21 from Nikolay Sivov [email protected] --- Didn't notice the test, sorry. I can confirm that it does show the problem. I was able to reduce it further, this sequence shows the same infinite loop:
--- set_point(&point, 6.63999975e-01, 3.21999997e-01); ID2D1GeometrySink_BeginFigure(sink, point, 0); quadratic_to(sink, 6.63999975e-01, 2.22000003e-01, 6.30999982e-01, 1.48000002e-01); quadratic_to(sink, 6.63999975e-01, 4.21999991e-01, 6.63999975e-01, 3.21999997e-01); ID2D1GeometrySink_EndFigure(sink, 0); ---
https://bugs.winehq.org/show_bug.cgi?id=51139
Bernhard [email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected]
--- Comment #22 from Bernhard [email protected] --- Following code snipped also causes a hang inside the d2d_geometry_sink_Close function:
ID2D1Factory *d2d1_factory; D2D1CreateFactory(D2D1_FACTORY_TYPE_SINGLE_THREADED, &d2d1_factory);
printf("Created D2D1 Factory: %p\n", d2d1_factory);
ID2D1PathGeometry* pathGeometry; ID2D1GeometrySink* geometrySink; d2d1_factory->CreatePathGeometry(&pathGeometry); pathGeometry->Open(&geometrySink);
geometrySink->BeginFigure({ 2.73000002e-01, 5.00000000e-01 }, D2D1_FIGURE_BEGIN_FILLED); geometrySink->AddQuadraticBezier({ {3.40999991e-01, 6.52000010e-01}, { 3.95000011e-01, 6.11999989e-01 } }); geometrySink->AddQuadraticBezier({ {4.49000001e-01, 5.72000027e-01}, {4.49000001e-01, 4.97999996e-01} }); geometrySink->EndFigure(D2D1_FIGURE_END_OPEN);
geometrySink->BeginFigure({ 2.56000012e-01, 5.88000000e-01 }, D2D1_FIGURE_BEGIN_FILLED); geometrySink->AddQuadraticBezier({ {3.07999998e-01, 5.88000000e-01}, {2.56000012e-01, 5.88000000e-01} }); geometrySink->EndFigure(D2D1_FIGURE_END_OPEN);
HRESULT hr = geometrySink->Close();
printf("GeometrySink closed with HRESULT: %x\n", hr);
geometrySink->Release(); pathGeometry->Release(); d2d1_factory->Release();
https://bugs.winehq.org/show_bug.cgi?id=51139
Wolfram Sang [email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected]
--- Comment #23 from Wolfram Sang [email protected] --- For users needing a workaround: Replace the D2D1 DLL with a native one. More information can be found here: https://forum.winehq.org/viewtopic.php?t=35318
I hope you guys don't mind the redundancy of me posting a workaround here as well. I had trouble finding this information, so I want to spread the word.
Cool that you already have a testcase for the builtin D2D. I wish you good luck fixing it! Much appreciated.
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #24 from [email protected] --- I think I have nailed down the underlying problem.
In case `EndFigure` is called with D2D1_FIGURE_END_OPEN, and the last vertex (point) is coincident with the first one of the figure, later calculations fail.
As the last segment then has an undefined direction and a length of 0, causing the `nan`s seen.
Omitting the last segment when it has zero length fixes the problem. This is already explicitly done when D2D1_FIGURE_END_CLOSED is set.
Anyone who is using openSUSE and wants to give it a try can check: https://download.opensuse.org/repositories/home:/StefanBruens:/branches:/Emu... https://build.opensuse.org/package/show/home:StefanBruens:branches:Emulators...
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #25 from [email protected] --- Created attachment 71469 --> https://bugs.winehq.org/attachment.cgi?id=71469 Proposed fix
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #26 from Wolfram Sang [email protected] --- Now, this is some good news to end the year :) I didn't test yet, but patch looks highly promising. Thank you for your efforts! All the best.
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #27 from Stefan Brüns [email protected] --- The original patch caused some regressions in d2d.
I have reworked the changes, but there are still some regression (or more exactly, current output no longer matching previous output). I need to investigate if the changes are actually bad or just false positives ...
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #28 from Dieter Jurzitza [email protected] --- Hello Stefan, so I downloaded the wine binaries you had had built from openSUSE and replaced the ones on my system with them. However, the behavior remained the very same. Please see attachement. Thank you for your efforts - could you kindly share your wine setup (what dlls you have as "native" ones and what dlls you use from "Wine" so I can mimick your setup, thereby removing potential other problems?) Thanks again, take care
Dieter
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #29 from Dieter Jurzitza [email protected] --- Created attachment 71590 --> https://bugs.winehq.org/attachment.cgi?id=71590 Last message before the death of T@X 2021 ...
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #30 from Stefan Brüns [email protected] --- (In reply to Dieter Jurzitza from comment #29)
Created attachment 71590 [details] Last message before the death of T@X 2021 ...
Make sure to replace the wine-32bit package (wine-7*.x86_64.rpm is irrelevant here).
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #31 from Stefan Brüns [email protected] --- Please provide the output of rpm -qi wine wine-32bit
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #32 from Dieter Jurzitza [email protected] --- Hello Stefan, I guess you meant to say rpm -qa wine wine-32bit, here you go:
djunix:/home/fred/Downloads/Wine # rpm -qa wine wine-32bit wine-32bit-7.0~rc5-lp152.930.1.x86_64 wine-7.0~rc5-lp152.930.1.x86_64
so I replaced *all* instances of wine by the ones of your repository ... I assume this is what you're asking for ... Thank you
Dieter
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #33 from Stefan Brüns [email protected] --- (In reply to Dieter Jurzitza from comment #32)
Any messages on the console? Both, with WINEDEBUG="" and WINEDEBUG=+d2d.
I can trigger the same message (or similar) when I downgrade the supported OpenGL version to 3.0. What hardware are you using? Please attach the output of glxinfo.
Btw, Leap 15.2 is EOLed.
https://bugs.winehq.org/show_bug.cgi?id=51139
Julian Rüger [email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected]
https://bugs.winehq.org/show_bug.cgi?id=51139
Louis Lenders [email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected]
--- Comment #34 from Louis Lenders [email protected] --- This commit: b92b6c29298805abd18a3c7ea0f7905099af572d apparently also fixes another application, Teamviewer ( i tested v15) (for which there`s a dozen bugzilla entries...)
I checked, and before the commit it just hangs at start, after the commit it starts fine, and shows ui , though it`s a bit slow, but one can interact with it. Didn`t test any further; but nicely done Stefan!
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #35 from Dieter Jurzitza [email protected] --- Ok, today I tried forth and back - reinstallation is impossible because I know that I ran out of keys. Please find attached the latest log I get until the picture I saved before with the message about the severe error. Command
wine stman.exe > logstman 2>&1
Thank you for looking into this, probably someone can read something from this. I tried to replace 1, then 3 libraries by their "native" version -> in vain:
msvcp140 (Native, Builtin) msvcp140_1 (Native, Builtin) vcruntime140 (Native, Builtin)
Take care
Dieter
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #36 from Dieter Jurzitza [email protected] --- Created attachment 71638 --> https://bugs.winehq.org/attachment.cgi?id=71638 wine stman.exe > logstman 2>&1, no additional debugging options
This has been achieved using the packages as provided by Stefan containing a fix.
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #37 from Stefan Brüns [email protected] --- Unfortunately the log is somewhat short of information.
There are several likely and less likely causes of the crash (which I don't run into): - T@X 2021 has some additional components not included in the more limited "Steuersparbuch" variants. Code not run can't crash - Different graphics drivers - Older graphics drivers.
Possible things to try out:
- Check if the problem is triggered by the Wine unittests. Grab d2d1_test.exe from https://testbot.winehq.org/JobDetails.pl?Key=105160 und run it with wine. It should report no test failures, and of course should not crash.
- Rerun with "WINEDEBUG=+d2d"
- Use "llvmpipe". Run with `LIBGL_ALWAYS_SOFTWARE=1 MESA_EXTENSION_OVERRIDE="-GL_EXT_memory_object" wine ./stman.exe`
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #38 from Dieter Jurzitza [email protected] --- Ok, I ran wine d2dl_test.exe > logit 2>&1
it is crashing - the output can be taken from the attachement logd2d1_test
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #39 from Dieter Jurzitza [email protected] --- Created attachment 71643 --> https://bugs.winehq.org/attachment.cgi?id=71643 logging from d2d1_test ...
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #40 from Dieter Jurzitza [email protected] --- Created attachment 71644 --> https://bugs.winehq.org/attachment.cgi?id=71644 WINEDEBUG=+d2d wine d2d1_test.exe > logit 2>&1
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #41 from Dieter Jurzitza [email protected] --- On top of this (I had been of the opinion that I already wrote a corresponding comment ...): I had had copied my entire ".wine" - Directory to another computer running leap 15.3 - it shows the exact same behavior. So, 15.2 is not the problem. Unfortunately - as already pointed out - I cannot reinstall as I have no more new installation attempts left.
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #42 from Dieter Jurzitza [email protected] --- Created attachment 71645 --> https://bugs.winehq.org/attachment.cgi?id=71645 Using the last settings as per Stefan's recommendations ...
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #43 from Dieter Jurzitza [email protected] --- No change in behavior .... this seems weird (to me). My computer runs 24x7 since weeks & month without any issue - but stman2021 keeps crashing ever since. Anyway, thank you for looking into this!
Dieter Jurzitza
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #44 from Dieter Jurzitza [email protected] --- Ok, I installed the new version of T@X (2022) for the bravehearted :-). To be sure to not run into trouble I replaced three dlls as per the recommendation for T@X2021 - and everything ran just smoothly. With the renewed .wine - directory I had had set up the d2d1 - test is running without flaw. So I am sure that there was something odd in my old setup. Unfortunately as readily pointed out I have no more installations left over for T@X2021 and T@X2022 does not allow you to try to upload the tax delcaration of 2020 - hence I cannot test the improvements by Stefan. Because I need several additional documents to generate the tax delcaration of 2021 it will take several month until I can report anything - only if someone knows whether or not there is an option to upload the old declaration so I would be able to test ....
I have been using msvcp120, msvcp140 and vcruntime140 replaced by the native versions - so, your mileage might vary.
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #45 from Stefan Brüns [email protected] ---
Because I need several additional documents to generate the tax delcaration of 2021 it will take several month until I can report anything
You can always trigger the preview manually, even with an incomplete declaration: Menu "ELSTER" -> "Voransicht der ELSTER Steuererklärung - STRG+E"
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #46 from Dieter Jurzitza [email protected] --- Dear listmembers, so, after more than a year and Wine 7.10 as of today morning no change (T@X 2022 Professional) I can start the preview (Strg-E) of the tax-declaration at the end *if* I use the Win 7 compliant mode (for other modes it crashes more or less immediately) Then I get an output of nearly empty pages (that stay empty when printed, too). Please see attachement - and let me know if anything would have to be tested. It is a pity that one may come flawlessly through 99.5 % of the procedure but fails badly at the very last step of the procedure. Thank you for looking into this, take care
Dieter Jurzitza
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #47 from Dieter Jurzitza [email protected] --- Created attachment 72544 --> https://bugs.winehq.org/attachment.cgi?id=72544 First page of the tax declaration achieved by calling "Strg-E" ...
So, this is a mainly empty page showing some artifacts - but not what I would have expected.
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #48 from Dieter Jurzitza [email protected] --- Created attachment 72545 --> https://bugs.winehq.org/attachment.cgi?id=72545 Another excerpt showing another part of the declaration ...
First page of the "Attachement EUER" - some boxes, but mainly empty. As I get many messages about fonts in the logs, would it theoretically be possible that a very special font is used that is simply not found and hence ignored?
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #49 from Dieter Jurzitza [email protected] --- Ok, today I found the solution - after thoroughly studying recommendations that were already there. It was all about replacing d2d1.dll with a native one and put it into the main directory of T@X. Having done this it is working smoothly - for T@X professional as well. So, this ticket can be closed - it took me quite a while to find out what is the right fix.
Best
Dieter Jurzitza
https://bugs.winehq.org/show_bug.cgi?id=51139
Joerg Schiermeier [email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected]
--- Comment #50 from Joerg Schiermeier [email protected] ---
So, this ticket can be closed - it took me quite a while to find out what is the right fix.
So this bug should be: close / fixed
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #51 from Bernhard Kölbl [email protected] --- The problem is still present in the Wine codebase though, so it can't really be treated as fixed.
https://bugs.winehq.org/show_bug.cgi?id=51139
azrdev [email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected]
--- Comment #52 from azrdev [email protected] --- Running the variant "WISO Steuer-Sparbuch 2022" here, I'm also having trouble submitting:
- with d2d1.dll from a Windows 10 installation, and the override set to "native", the preview (Ctrl+e or invoked implicitly by the submission) triggers an exception, i.e. I see that "fatal error" messagebox.
- without the override, the preview does not throw an exception, but contains mostly white pages with only some lines and numbers, but not the expected content. Scrolling prints to stdout (with WINEDEBUG=+d2d1) a lot of those lines:
010c:fixme:d2d:d2d_path_geometry_ComputeArea iface 3DF1B140, transform 018CAAE4, tolerance 2.50000000e-01, area 018CAAE0 stub!
This is archlinux with wine 8.7 Log with WINEDEBUG=+d2d1 and the wine-version of d2d1.dll is attached (starting with me pressing ctrl-e, i.e. without the startup and loading of the file).
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #53 from azrdev [email protected] --- Created attachment 74461 --> https://bugs.winehq.org/attachment.cgi?id=74461 wine stdout+stderr after triggering the report generation, with WINEDEBUG=+d2d1 and the native d2d1.dll
https://bugs.winehq.org/show_bug.cgi?id=51139
NochnTim [email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected]
--- Comment #54 from NochnTim [email protected] --- Running the variant "WISO Steuer-Sparbuch 2022" here, I have set wine to Windows 10 and tried d2d1.dll native versions 10.0.19041.329, 10.0.15063.0, 10.0.10240.16384 with the same results as azrdev. Changing settings to Windows 7 and using version 7.0.6002.18107 still does the trick.
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #55 from Dieter Jurzitza [email protected] --- New year - bad luck. Using T@X2024 on my system the functionality is gone again.
Putting a 32 - bit d2d1.dll into the root - directory of T@X (the one that is working fine for T@X2023 and still is after testing ...) shows pages with partial lines and a few numbers only - just like without "native" version.
Putting a 64 bit - version of d2d1.dll into the very same directory causes T@X to message an error and ask whether it should terminate.
Wine - Windows - version is set to Windows 7 - however, I can use other variants with identical results.
Any ideas? Anyone that tried the same and failed in a similar manner?
Thank you very much, take care
Dieter
wine - versioninfo: wine-9.5-lp154.1701.3.x86_64 wine-gecko-2.47.4-lp154.68.1.noarch winetricks-20240105-lp154.45.2.x86_64 wine-binfmt-1.2.1-lp154.3.3.noarch wine-32bit-9.5-lp154.1701.3.x86_64 wine-mono-9.0.0-lp154.68.1.noarch
https://bugs.winehq.org/show_bug.cgi?id=51139
Maro [email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected]
--- Comment #56 from Maro [email protected] --- To add info to the issue: It seems like they don't release a 32 bit version of the tool anymore, so the release is 64 bits. However, putting a 32 bit d2d1.dll (with native, builtin) results in an empty page except for lines, whereas using a 64 bit dll results in a crash (with the app asking whether to continue or close).
Win 7 or Win 10 configuration does indeed not alter that behavior on my side as well.
Without too much insight, I would guess the 32 bit behavior is a the result of a fallback to the builtin, and the 64 bit thing is trying to access the dll which fails.
https://bugs.winehq.org/show_bug.cgi?id=51139
Ken Sharp [email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |testcase
https://bugs.winehq.org/show_bug.cgi?id=51139
[email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected]
--- Comment #57 from [email protected] --- I can confirm Dieter's observations: Using wine-9.9 and native (Windows) 64-bit d2d1.dll in versions 6.3.9600.16473, 10.0.10586.0 and 10.0.19041.329 cause an exception when opening Elster preview and wine asks if it should terminate.
Has anyone an idea how to find out what goes wrong when using the native dll?
Furthermore I looked into the "fixme:d2d:d2d_path_geometry_ComputeArea" messages and tried to return some bogus area calculations. However it had no effect on the output of Elster preview. Either I returned the wrong values, or this might be a red herring. But please take this information with a grain of salt, because I only have minimal experience in programming in C, and none in Windows functions.
The question remains: Which function is implemented incorrectly and causes the mostly blank pages in Elster?
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #58 from Maro [email protected] --- While it unfortunately adds nothing to solve the issue, printing the forms (CTRL-F or the „Formulare“ button in the ribbon bar) seems to work flawlessly alltogether, even saving that output to pdf works fine. In the document in CTRL-E („ELSTER“), some pages are working fine (i.e. all pages with names starting with „Anlage“. For me, its only the „ELSTER Dokumente“ part that is ill-formatted. Is that behavior the same for other as well?
https://bugs.winehq.org/show_bug.cgi?id=51139
[email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected]
--- Comment #59 from [email protected] --- I am also experiencing excessive memory usage in tax 2024 when trying to display the "Eric" results. However, I've found a fix at least for the blank pages: https://gitlab.winehq.org/wine/wine/-/merge_requests/6492
https://bugs.winehq.org/show_bug.cgi?id=51139
--- Comment #60 from Dieter Jurzitza [email protected] --- Hello @all, I can confirm the statement of Philipp, after patching "geometry.c" using the suggested patch of Philipp the data in the preview of the tax declaration as of a sudden become visible. So, I can only hope that this handling of data (or any way that is as efficient ...) will find its way into the wine code - preferrably rather earlier than later :-). The next tax declaration is "in front of the door" Thanks for the efforts, take care
Dieter
-
WineHQ Bugzilla