I must to write my issue here

Open forum for end-user questions about Wine. Before asking questions, check out the Wiki as a first step.
Forum Rules
Locked
ZaeNae
Level 1
Level 1
Posts: 8
Joined: Fri Jan 28, 2022 12:32 pm

I must to write my issue here

Post by ZaeNae »

So, I tried to send a bug report to Bugzilla. It wanted to create an account. That is OK, although I didn't understand why cannot use my forum account.
The Bugzilla made so hard to follow the process, I wasn't able to do that.
Here is the issue what I wanted to report.

I am using the 3D GameStudio (link: http://www.3dgamestudio.com) suit to develop some programs under wine, because the suit was made for Windows.
Until the last few weeks everything worked fine, but i needed to reinstall my system and I got a brand new wine package together with that.
The version number is 9.11-1.

Now, in my c programs the fflush() function wont work.
If my memory doesn't cheat me the 9.8 or some older versions have no problem.
ZaeNae
Level 1
Level 1
Posts: 8
Joined: Fri Jan 28, 2022 12:32 pm

Re: I must to write my issue here

Post by ZaeNae »

Addendum.

I tried figure out which wine version worked and which didn't with fflush.
It seems to me the 8.7 version and all the olders worked fine.
The 8.8 and all the newer versions didn't worked with fflush.
User avatar
DarkShadow44
Level 9
Level 9
Posts: 1338
Joined: Tue Nov 22, 2016 5:39 pm

Re: I must to write my issue here

Post by DarkShadow44 »

Can you provide a simple example program so we can test?
ZaeNae
Level 1
Level 1
Posts: 8
Joined: Fri Jan 28, 2022 12:32 pm

Re: I must to write my issue here

Post by ZaeNae »

Of course. Here is an example in Lite-C, it runs under 3D Gamestudio.
Insert the code into SED (the code editor shipped together with 3D GS) and run from there.
You can see the file_close is commented out for testing purpose.
If everything goes well the file will be closed normally and contains the text, without the execution of the file_close.

Code: Select all

/*
    fflush trying (3D Gamestudio Lite-C)
*/

#include <strio.c>
#include <windows.h>
#include <stdio.h>
#include <d3d9.h>

function main() {
    var fhandle_n = 0;
    var xhandle_n = 0;

    level_load(NULL);
    wait(2);

    fhandle_n = file_open_write ("bubu.txt");
    xhandle_n = fhandle_n;
diag_var("\nfhandle_n: %6.3f",fhandle_n);

    file_str_write(fhandle_n, "bubu\n\r");
diag("\ncomes");
diag_var("\nfhandle_n: %6.3f",fhandle_n);
    fflush(xhandle_n);        // stucks here..
diag("\ngoes");

//    file_close(fhandle_n);
}
User avatar
DarkShadow44
Level 9
Level 9
Posts: 1338
Joined: Tue Nov 22, 2016 5:39 pm

Re: I must to write my issue here

Post by DarkShadow44 »

Created a bug report for you here: https://bugs.winehq.org/show_bug.cgi?id=57011

Are you sure it fails in wine-8.8? For me it starts failing with wine-9.5
PaulGofman
Newbie
Newbie
Posts: 2
Joined: Mon Jul 29, 2024 8:34 pm

Re: I must to write my issue here

Post by PaulGofman »

I've put the lengthy technical description here in the bug ticket: https://bugs.winehq.org/show_bug.cgi?id=57011#c2 and sent the MR upstream (https://gitlab.winehq.org/wine/wine/-/m ... uests/6175) which effectively changes the hang into the error message displayed when attempting to execute the script. But in the essence of that is script bug which works on Windows silently only by chance (and that fflush() doesn't do anything while possibly corrupting unrelated data).

What file_open_write() returns is not a C file structure, you can't pass those objects to fflush (which is a native CRT library function which expects FILE structure). The engine doesn't seem to do any validation on that. If you use fflush() on fhandle_n insetad of a copy it will display message box both on Windows and Wine complaining about access violation (happening in msvcrt because in that case it is bit less lucky with random data and just crashes in the fflush logic). That's probably why this copy was added? But it doesn't help really.

I don't know if this script engine has its own function for flushing output but passing random data to native functions is not an option. Maybe it is possible to use CRT fopen() and friends instead of engine's file functions, no idea about this engine beyond what I debugged WRT the concerned issue.
ZaeNae
Level 1
Level 1
Posts: 8
Joined: Fri Jan 28, 2022 12:32 pm

Re: I must to write my issue here

Post by ZaeNae »

Here is the precise list what I tried with various wine versions (I don't know what were the particular patch version numbers):
8.1 works
8.4 works
8.6 works
8.7 works
8.8 not works
8.11 not works
9.6 not works
9.8 not works
9.11 not works
9.12 not works

I don't agree totally with Paul Gofman. In the older versions it not randomly worked but always worked.
User avatar
DarkShadow44
Level 9
Level 9
Posts: 1338
Joined: Tue Nov 22, 2016 5:39 pm

Re: I must to write my issue here

Post by DarkShadow44 »

ZaeNae wrote: Tue Jul 30, 2024 12:41 am I don't agree totally with Paul Gofman. In the older versions it not randomly worked but always worked.
Yes, unfortunately this is a property of undefined behavior - it may work reliably for a long time, until it doesn't. As noted, for me it works reliably until 9.5.

Furthermore, Paul wrote
Note that in this repro script fhandle_n is copied to xhandle_n before file_str_write and fflush. Changing that to a straightforward way (just fflush(fhandle_n)) causes access violation in this fflush() both on Windows and Wine and results in a message box complaining about invalid access.
For me, that only results in a "deadlock", no messagebox.

If it really passes "random" data, and I trust Paul's analysis on this, I don't see anything we can do to make it work properly.
PaulGofman
Newbie
Newbie
Posts: 2
Joined: Mon Jul 29, 2024 8:34 pm

Re: I must to write my issue here

Post by PaulGofman »

ZaeNae wrote: Tue Jul 30, 2024 12:41 am I don't agree totally with Paul Gofman. In the older versions it not randomly worked but always worked.
I want to stress the point again. As far as I could see, it *never* worked, neither on Windows nor on older Wine versions. In a sense that fflush(...) on what is passed to it was *never doing anything*. But was lucky (or, rather, unlucky, hiding the actual problem??) not to visibly break but continue as if everything is fine and possibly corrupting memory affecting things at script execution at random.

The fact that it just hangs (instead of breaking in some other way) is not quite correct though, I sent upstream MR (https://gitlab.winehq.org/wine/wine/-/m ... uests/6175) so critical section wait doesn't hang but instead errors out in case of invalid (random in this case handle). If that gets in the script will display error messabe box instead of hanging which I believe is the best possible luck here (as it indicates that script is wrong). Although since it depends on semi-random unitialized on-stack data it still possible it will change in the future either due to some random unrelated changes in script engine or the same random and unrelated changes in Wine which would only affect leftover stack data.
Locked