[Bug 56941] New: EA app fails to launch game if total size of environment variables exceeds ~32000 characters
https://bugs.winehq.org/show_bug.cgi?id=56941
Bug ID: 56941 Summary: EA app fails to launch game if total size of environment variables exceeds ~32000 characters Product: Wine Version: 9.12 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs@winehq.org Reporter: tinozzo123@gmail.com Distribution: ---
### Steps to reproduce
Preparation: - Have the EA app installed: https://origin-a.akamaihd.net/EA-Desktop-Client-Download/installer-releases/... - I installed it through Bottles, which installs the following Winetricks dependencies: https://github.com/bottlesdevs/programs/blob/main/Games/eaclient.yml
Reproducing: - Set a very long environment variable, before launching the EA app - From the EA app, launch any game - Alternatively, execute the game directly, it will automatically launch the EA app to launch the game - If you don't have any game, "The Sims 4" is free - The game won't launch, an error popup from the EA app will appear (see notes)
### Notes
It doesn't matter whether these ~32000 characters are from a single environment variable, or from the combination of many of them.
I didn't test on Windows. It may be impossible to test there, since the environment block there has a limit of 32760 characters (which may probably be the reason for this issue in the first place).
I say "~32000", because the issue starts occurring a little before 32760 characters. However, my counting method was imprecise (I simply typed `set` in `wine cmd`, then counted the characters), and there's also the fact that the EA app also sets its own environment variables.
The issue also occurs with games bought from Steam (thus launched with Proton) that also have to go through the EA app (thanks EA).
This issue existed before, and the weird thing is that the error popup from the EA app is different from some time ago (I imagine due to the app being updated). Before it was: "Failed to launch game. An error on our end caused the launch to fail. Try again a little later." Now it's: "The game hasn't released yet" (which is obviously untrue). Is it a stack overflow issue?
Logs obtained with `WINEDEBUG=EADesktop.exe:+relay` are too big to attach, even compressed. Let me know what `WINEDEBUG` parameters I should use instead. I can see that the app calls `GetEnvironmentStringsW`, shortly followed by a `WideCharToMultiByte` for each variable (key and value separately). This is done three times.
https://bugs.winehq.org/show_bug.cgi?id=56941
tinozzo123@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download
https://bugs.winehq.org/show_bug.cgi?id=56941
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de
--- Comment #1 from Fabian Maurer dark.shadow4@web.de --- If it won't work on windows, it doesn't have to work on wine either. How did you get that massive environment variables anyways?
https://bugs.winehq.org/show_bug.cgi?id=56941
--- Comment #2 from tinozzo123@gmail.com --- I'm using a Linux distribution that doesn't respect FHS (NixOS), and each "derivation" is isolated in the filesystem. That is, libraries are not all put together in /lib. Some applications (e.g. Qt, for instance if you use KDE Plasma) are unable to find their libraries unless you have environment variables pointing to them, which causes them to be massive since they have to list every individual path to the library (e.g. `XDG_DATA_DIRS` and `QT_PLUGIN_PATH`, on my end the former is larger than 20000 characters by itself).
IMO (assuming that the issue is EA app's fault, and not Wine's), I don't think that a workaround for this situation would be a bad idea. Something like "if the total size exceeds 32760, exclude the largest environment variables until you get under 32760". Considering that: - Having more than 32760 characters can't happen on Windows in the first place, so it's "sensible behavior" for a Windows application to assume that. - Whatever is excluded is unlikely to be used by the Windows app (e.g, in my case, I doubt any Windows app would care about `XDG_DATA_DIRS`). - The alternative would be for the user to put a workaround manually (like I do here: https://github.com/ValveSoftware/Proton/issues/6766#issuecomment-1819822798)
I'm not a Wine maintainer, though, so this is not my decision.
https://bugs.winehq.org/show_bug.cgi?id=56941
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=56941
mrdeathjr28@yahoo.es changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mrdeathjr28@yahoo.es
https://bugs.winehq.org/show_bug.cgi?id=56941
Alois Schlögl alois.schloegl@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |alois.schloegl@gmail.com
--- Comment #3 from Alois Schlögl alois.schloegl@gmail.com --- It seems this is a question which environment variables from the host system should be propagated to the application environment within wine. I compared the variables of the host running on the host env >env.list and wine cmd SET and compared the list of envvars. It seems that almost all envvars from the host are propagated, except a few are not propagaged (i.e. "blacklisted" ?). In my case, these have are not propagated
HOME PWD QT_ACCESSIBILITY QT_FONT_DPI QT_SCALE_FACTOR XDG_SESSION_TYPE
The majority is propagated. So, it seems that at the moment a kind of blacklisting is in place. However, it might be more sensible, to only whitelist those envvars that are meaningful to wine and its applications.
https://bugs.winehq.org/show_bug.cgi?id=56941
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |o.dierick@piezo-forte.be
--- Comment #4 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- Hello,
(In reply to Alois Schlögl from comment #3)
In my case, these have are not propagated
HOME PWD QT_ACCESSIBILITY QT_FONT_DPI QT_SCALE_FACTOR XDG_SESSION_TYPE
-- code from dlls/ntdll/unix/env.c --- /*********************************************************************** * is_special_env_var * * Check if an environment variable needs to be handled specially when * passed through the Unix environment (i.e. prefixed with "WINE"). */ static BOOL is_special_env_var( const char *var ) { return (STARTS_WITH( var, "PATH=" ) || STARTS_WITH( var, "PWD=" ) || STARTS_WITH( var, "HOME=" ) || STARTS_WITH( var, "TEMP=" ) || STARTS_WITH( var, "TMP=" ) || STARTS_WITH( var, "QT_" ) || STARTS_WITH( var, "VK_" ) || STARTS_WITH( var, "XDG_SESSION_TYPE=" )); } (...) if (is_special_env_var( p )) length += 4; /* prefix it with "WINE" */ (...) if (is_special_env_var( p )) /* prefix it with "WINE" */ { *envptr++ = strcpy( dst, "WINE" ); strcat( dst, p ); } (...) /* skip Unix special variables and use the Wine variants instead */ if (!strncmp( str, "WINE", 4 )) { if (is_special_env_var( str + 4 )) str += 4; else if (!strcmp( str, "WINEDLLOVERRIDES=help" )) { MESSAGE( overrides_help_message ); exit(0); } } else if (is_special_env_var( str )) continue; /* skip it */ -- end of code ---
(In reply to tinozzo123 from comment #0)
I say "~32000", because the issue starts occurring a little before 32760 characters. However, my counting method was imprecise (I simply typed `set` in `wine cmd`, then counted the characters), and there's also the fact that the EA app also sets its own environment variables.
(In reply to tinozzo123 from comment #2)
individual path to the library (e.g. `XDG_DATA_DIRS` and `QT_PLUGIN_PATH`, on my end the former is larger than 20000 characters by itself).
QT_PLUGIN_PATH meets the STARTS_WITH( var, "QT_" ) condition to is_special_env_var(), so it's one of the variable that gets mangled.
I wonder if adding those 4 "WINE" character to special variables when the environment is near the 32768 limit makes it overflow or something. Maybe WINE should not blindly add those characters but check if the size permits it.
I guess PATH, HOME and PWD are present on every system so that makes for at least 12 characters, and you have to add the wine-generated PATH, HOME and PWD.
Of course, this doesn't tell which of Wine or the application is failing.
However, simply blacklisting the longest variable is not a proper solution IMO, as it may be one variable that is required for proper operation, and smaller ones, not required for wine or system operation, should be removed instead. Then it would be up to the user to decide which variable to remove, and it would have to be done before launching the wine command.
Have you tried to launch the EA App with a script that sets a cleaner environment for wine before launching the command?
Regards.
https://bugs.winehq.org/show_bug.cgi?id=56941
--- Comment #5 from tinozzo123@gmail.com --- There's a discussion on https://gitlab.winehq.org/wine/wine/-/merge_requests/6140.
https://bugs.winehq.org/show_bug.cgi?id=56941
--- Comment #6 from tinozzo123@gmail.com --- Still reproducing the issue on Wine 10.4.
I tested on a completely fresh prefix. The error from the EA App is: "Failed to launch game. An error on our end caused the launch to fail. Try again a little later."
The game (Dead Space) launches successfully if I trim the environment variables.
http://bugs.winehq.org/show_bug.cgi?id=56941
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.winehq.org/sho | |w_bug.cgi?id=58333
http://bugs.winehq.org/show_bug.cgi?id=56941
--- Comment #7 from tinozzo123@gmail.com --- Still an issue on Wine 10.15.
-
WineHQ Bugzilla