Testing Result for Beta EVE Launcher

EVE Technology and Research Center Linux
42

It could as well be connected to the way launcher passes arguments to the client. I will try to check this hypothesis tomorrow.

1 Like
43

I managed to get SiSi client running via linux launcher as well. Command lines seem to differ in a few things:

  1. Second part of ssoToken is different
  2. Windows launcher passes refreshToken and machineHash, linux launcher does not
  3. Linux launcher passes ā€œ/remotefilecachefolder=Z:/home/dfx/.eve//ResFilesā€ and ā€œ/triPlatform=dx9ā€, windows launcher does not

I tried modifying launch arguments so that they mimic ones passed by the linux launcher and launch EVE client directly, but it seems to always lead to the same crash, see stdout below:

Network layer using: CarbonIO
MESA-INTEL: warning: Performance support disabled, consider sysctl dev.i915.perf_stream_paranoid=0

MESA-INTEL: warning: Performance support disabled, consider sysctl dev.i915.perf_stream_paranoid=0

MESA-INTEL: warning: Performance support disabled, consider sysctl dev.i915.perf_stream_paranoid=0

MESA-INTEL: warning: Performance support disabled, consider sysctl dev.i915.perf_stream_paranoid=0

MESA-INTEL: warning: Performance support disabled, consider sysctl dev.i915.perf_stream_paranoid=0

EVE Client version 19.09 build 1946089 starting 09/30/2021 14:31:20
Cerberus localization module loaded on client
EVE Client version 19.09 build 1946089 started 09/30/2021 14:31:21
...loading from: C:/EVE/SharedCache/sisi/bin64/packages/eveProto/generated/client.pyd
Loaded native protobuf serialization
EXCEPTION #1 logged at 09/30/2021 14:31:23 : Unhandled exception in <TaskletExt object at 0x3ea6808, abps=1001, ctxt=None>

Formatted exception info: ImportError: DLL load failed: Success.

Common path prefix = c:/buildagent/work/28f796d548f5b3f2/eve/staging/2021-iceberg

Caught at:
<pre>/packages/bluepy/__init__.py(52) CallWrapper

Thrown at:
<pre>/packages/bluepy/__init__.py(43) CallWrapper
<pre>/carbon/common/lib/autoexec_client_core.py(166) Startup
<pre>/carbon/common/script/sys/serviceManager.py(132) Run
<pre>/carbon/common/script/sys/serviceManager.py(88) _BuildClassMap
<pre>/eve/common/modules/nice/client/_nastyspace/svc.py(81) <module>
<pre>/eve/client/script/parklife/fleetSvc.py(17) <module>
<pre>/eve/client/script/ui/shared/fleet/fleetwindow.py(16) <module>
<pre>/eve/client/script/ui/shared/fleet/fleetRespawnPoints.py(1) <module>
<pre>/eve/common/modules/nice/client/_nastyspace/listentry.py(92) <module>
<pre>/eve/client/script/ui/shared/incursionJournal.py(11) <module>
<pre>/eve/client/script/ui/shared/mapView/mapViewUtil.py(12) <module>
<pre>/eve/client/script/ui/shared/systemMenu/betaOptions.py(11) <module>
<pre>/packages/launchdarkly/__init__.py(69) <module>
        __builtins__ = {'AUR': 30,
                        'ArithmeticError': <type 'exceptions.ArithmeticError'>,
                        'AssertionError': <type 'exceptions.AssertionError'>,
                        'AttributeError': <type 'exceptions.AttributeError'>,
                       ...
        __doc__ = None
        __file__ = None
        __loader__ = None
        __name__ = None
        __package__ = None
        __path__ = None
        _make_user_object = None
        client = None
        client_instance = None
        ext = None
        get_client = None
        imp = None
        json = None
        logger = None
        logging = None
        monolithconfig = None
        on_client = None
        os = None
        platform = None
        sdk = None
        set_user = None

Thread Locals:  session was <Session: (sid:4439296696296545826, mutating:0, contextOnly:False, corprole:0x0, languageID:EN, role:0x4000000000000000L, sessionType:5, rolesAtAll:0x0, rolesAtH
Q:0x0, rolesAtBase:0x0, rolesAtOther:0x0)>
Stackhash: 1095971830
Reported from:  logmodule
EXCEPTION END
An exception has occurred. It has been logged in the log server as exception #1
2 Likes
44

Thanks for testing that! I am actually debugging where launchdarkly gets loaded now. It looks like the native DLL is actually loaded successfully but the embedded Python interpreter sees it as an error some some reason, hence the cryptic Failed to load DLL: Success message.

1 Like
45

(after reading all of these things)
Iā€™m wondering about TQ playability under linux after next update. Right now its fine, BUT it seems problems are coming to me.

1 Like
46

Yes, quite obviously it will be broken for launching via Windows launcher with modern Wine versions. The only known workaround so far is using linux launcher. Maybe old wine versions will also work.

47

More progress:

I think I found the reason for the cryptic error code. Basically launchdarkly_client.pyd is failing to load with LoadLibraryExW, but the game code isnā€™t checking the error status before doing processing on it. This processing is changing the error status value before it gets reported, which causes it to say ā€œSuccessā€ in the logs instead of the actual error message.

48

More progress:

I managed to get the real error code back from the OS: itā€™s 0x7e, which means module not found. Looking at how it loads the modules, it uses an absolute path for every one EXCEPT launchdarkly:

Wine-dbg>x /u $rcx
C:\EVE\SharedCache\sisi\bin64\controlTowerResourcesLoader.pyd
Wine-dbg>c
Stopped on breakpoint 1 at 0x000000001e008ced
Wine-dbg>x /u $rcx
launchdarkly_client.pyd

launchdarkly is using a relative path for some reason and not able to be found by wine. Looking into why this would only affect Wine and not windows now.

2 Likes
49

I think it was you who fixed prev launcher disease under linux?

Blessed will be your ways man. I owe you whatever amounts you want of solo 1vs1 at the sun

2 Likes
50

Thanks :slight_smile: I did gather enough info to figure out the root cause, but it was the wine devs who actually fixed it

51

OK, Iā€™ve confirmed that the launchdarkly_client.pyd module successfully loads with a relative path on windows, and does not in wine. Iā€™m thinking itā€™s related to this last argument theyā€™re passing to LoadLibraryExW:

LoadLibraryExW((LPCWSTR)plVar4[3],(HANDLE)0x0,8);

8 for this argument messes with the search order for DLLs, and is undefined when passing a relative path as the first argument (which theyā€™re doing with launchdarkly but no other modules).

1 Like
52

Iā€™ve opened a wine bug ticket here: WineHQ Bugzilla ā€“ Bug 51821 ā€“ EVE Online Sisi Client Crashes Due to differences in how Wine and Windows handle LoadLibraryExW Undefined Behavior

Please go ahead and post a comment to show that it affects multiple users

6 Likes
53

Thank you Renard for doing the heavy lifting. Would help out more if I knew how to get the relevant information.

1 Like
54

BTW everyone, while I work on a proper fix, Iā€™ve discovered that if you copy launchdarkly_client.pyd from C:\EVE\SharedCache\sisi\bin64 to C:\EVE\SharedCache\sisi\, Sisi will launch just fine, confirming itā€™s an issue with the DLL search path behavior in Wine. You should be able to use this as a workaround for now.

5 Likes
55

My manā€¦ thank you! Will update and verify/confirm once I have a chance.

I guess we should keep a copy of the pyd file in case this change gets pushed to the TQ launcher before itā€™s resolved via Wine?

Update - Just tried this out. It works.
Wanted to point out that you need to run the launcher first, then copy while itā€™s running. If you copy before the launcher is run, the launchdarkly_client.pyd will be deleted when the launcher starts. Also, similarly you will have to cp the file into the directory again every time you run the launcher, as when the launcher starts, it will delete the launchdarkly_client.pyd file

1 Like
56

Thanks for the notes! I forgot to mention that the Launcher cleans out extra files etc. when it starts so youā€™re exactly right that you need to start the launcher before copying it. Iā€™m talking to the wine devs on IRC now so hopefully we can figure out a fix.

I guess we should keep a copy of the pyd file in case this change gets pushed to the TQ launcher before itā€™s resolved via Wine?

I doubt you would need to, although it wouldnā€™t hurt. There isnā€™t really a problem with the file, itā€™s just that Wine doesnā€™t resolve the correct directory when loading it, while Windows does.

57

@D43dun are you comfortable building wine from source? Iā€™ve got a patch I need to test that fixes it on my system. Iā€™m working on creating more conformance tests that are required before it could be eligible to be accepted in wine, but it would be good to know if it fixes the problem with Sisi on other systems and doesnā€™t introduce any other serious bugs.

58

Also I want to try it too. Im kinda ok with building form source, I think. Can I participate?

59

Grab this patch and apply it with git am. Should apply cleanly to both vanilla wine and wine-staging.

60

yep. I can give it a tryā€¦ Never done it before, but can look into this in the next day or so.

61

So, I compiled wine and wine64 from source with your patch applied. Compiling wine reminded me why I stopped using gentoo a long time ago.

I use lutris to run the game, so I pointed the game runner to be the recently compiled wine, and I couldnā€™t get the launcher to begin. I sense that this might be some sort of issue between how Iā€™m calling wine through lutris. Also, I couldnā€™t find the debug output from Lutris.

Will try to run again today in the evening, and tail -f the logs straight from the system to see whatā€™s wrong when running this, try to get the launcher/game to run.