Hey all, the linux launcher release is now quite far behind current windows release, so I’m embarking on a little project to bring it forwards in time somewhat.
The first step of this is to update the linux beta to bleeding edge, so I have released beta 1732117. I’d like to ask people to give this a try and let me know if they encounter issues. Don’t forget to include your distro and version!
Notable changes in 1732117:
QT version updated to 5.12.0
Login flow now contained entirely within main window
fancy splash screen
Like 9 months of other patches or something IDK there’s a lot of stuff in there
Looks like the reason mine forgot my accounts might be because the launcher isn’t actually closing properly, so after the patch I had multiple launchers open. Carefully killing all launchers after patch and then relaunching a single instance may restore the account list. Seen on Xubuntu 18.04.
If other people see this issue, please let me know.
Nice to see any progress after all. From time to time the QtWebEngineProcess crashes with following messages:
[gharim@amd4k3 evelauncher]$ ./evelauncher.sh
Settings path: "/home/gharim/.config/CCP/EVE.conf"
Language selected based on stored settings: "en"
QObject::startTimer: Timers can only be used with threads started with QThread
QApplication: invalid style override passed, ignoring it.
[0523/112939.710403:WARNING:resource_bundle_qt.cpp(116)] locale_file_path.empty() for locale
Installed Qt WebEngine locales directory not found at location /home/gharim/evelauncher/translations/qtwebengine_locales. Trying application directory...
Qt WebEngine locales directory not found at location /home/gharim/evelauncher/qtwebengine_locales. Trying fallback directory... Translations MAY NOT not be correct.
Path override failed for key ui::DIR_LOCALES and path '/home/gharim/.QtWebEngineProcess'
[0523/112939.762622:WARNING:resource_bundle_qt.cpp(116)] locale_file_path.empty() for locale
[S_API FAIL] SteamAPI_Init() failed; SteamAPI_IsSteamRunning() failed.
[S_API FAIL] SteamAPI_Init() failed; unable to locate a running instance of Steam, or a local steamclient.so.
../../3rdparty/chromium/sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0230
Received signal 11 SEGV_MAPERR 0000000000e6
#0 0x7feaf6c0632f <unknown>
#1 0x7feaf6c0672b <unknown>
#2 0x7feaf6c06dae <unknown>
#3 0x7feaf4533d70 <unknown>
#4 0x7feaf7c67ab3 <unknown>
#5 0x7feaf7c700ea <unknown>
#6 0x7feaf4533d70 <unknown>
#7 0x7feaf45bf2d1 __clock_nanosleep_2
#8 0x7feaf45c4bf7 __GI___nanosleep
#9 0x7feaf6c1331b <unknown>
#10 0x7feaf6c15438 <unknown>
#11 0x7feaf7d610f5 <unknown>
#12 0x7feaf900c831 <unknown>
#13 0x7feaf5558880 <unknown>
#14 0x7feaf8ff76ac <unknown>
#15 0x7feaf6e822a0 <unknown>
#16 0x7feaf6e85cab <unknown>
#17 0x7feaf6e89674 <unknown>
#18 0x7feaf6e7f5b0 <unknown>
#19 0x7feaf6e7f9b2 <unknown>
#20 0x7feaf6e9c5f0 <unknown>
#21 0x7feaf6b69667 <unknown>
#22 0x7feaf6bbe0f6 <unknown>
#23 0x7feaf6b69667 <unknown>
#24 0x7feaf6b900b7 <unknown>
#25 0x7feaf6b90afd <unknown>
#26 0x7feaf6b90dca <unknown>
#27 0x7feaf6b89a12 <unknown>
#28 0x7feaf6baa3ff <unknown>
#29 0x7feaf6be0098 <unknown>
#30 0x7feaf6c13660 <unknown>
#31 0x7feaf44d946f start_thread
#32 0x7feaf45f73d3 __GI___clone
r8: 000000000000fec0 r9: 00007feaf46387a0 r10: 00007feacf7fc190 r11: 6637303030307830
r12: 00007feacf7fc280 r13: 00007feacf7fc230 r14: 00000000012e7c70 r15: 00007feacf7fc280
di: 0000000000000001 si: 00007feacf7fc080 bp: 00007feacf7fc260 bx: 00000000000000e6
dx: 0000000000000000 ax: 0000000000000000 cx: 0000000000000012 sp: 00007feacf7fc230
ip: 00007feaf7c67ab3 efl: 0000000000010202 cgf: 002b000000000033 erf: 0000000000000006
trp: 000000000000000e msk: 0000000000000000 cr2: 00000000000000e6
[end of stack trace]
Calling _exit(1). Core file will not be generated.
After this a new process launched and works as intended.
The E0523 error have i suppressed by copying the cacert.pem from a eve client directory to /usr/local/share/grpc/roots.pem so that the launcher can establish a secure connection to this server elg.evetech.net (maybe some test server?).
Have the same effect with the ‘not closing’. Sometime it works if i close the launcher from tray icon sometimes not.
Distribution: Manjaro Linux 20.0.1 Lysia
Kernel: 5.4.40-1-MANJARO
The E0523 I’m not particularly worried about. It puts a lot of noise on the console, but I’m not sure it has any ill effects. I’m not sure what that server is, but I’ll check in with the launcher team about it. It’s probably a content server for some part of the UI.
I’m more worried about the crash. Does that happen under any specific circumstances?
No any specific circumstances i think, but it have maybe the same effect on the gui like in the old versions. This empty launcher window can it be. If i push the refresh button from the launcher menu starts in background a new QtWebEngineProcess and reload the gui is my guess.
With the E0523 you are right, it looks only ugly and lead maybe in the wrong direction, the launcher works with or without this error messages.
I haven’t looked any further into it, but my guess is that this might just be happening because in this update you moved from qt 5.11 to 5.12. Given that the launcher isn’t exiting properly, the two running versions may have been fighting with each other.
Based on what I’m reading in that bug report, I would guess that provided you stay on the current beta and do not downgrade, you should not see the issue again. Let me know if it does keep showing up
The launcher not closing properly is also an issues on windows. If I don’t close the launcher myself, windows is unable to shutdown.
If I forget to close the launcher I will have to click “shut down anyway” when promoted that the launcher is not safely closing.
If I don’t close the launcher or click “shut down anyway” my system will reboot instead of shutdown.
Today i have done a clean install from the beta launcher and can provoke this QtWebEngineProcess crash with this installation. To do this i have removed the cache directories from QtWebEngine in ~/.cache and ~/.local/share/CCP then started the launcher. He flashes white and on the console comes the crash message. Pushed then the refresh button on the menu and he reload the gui as before.
Closed the launcher, he hungs as before so i killed him with killall evelauncher, removed the QtWebEngine cache directories again, started again the launcher with the same effect. After the update to the new version has she the same behavior. On exit waits the launcher after closing the main loop of some event logger that he finish his crap (says the launcher log).
HTH
P.S. Interesting, that the windows version have the same bug with no clean exit.
It did append one time that the launcher process was eating 100% of one core, with is slightly annoying.
When exiting the launcher, it killed all my EVE clients (was about to leave for a > 1k capsulers fight).
Doing “killall evelauncher” do close the launcher without closing the EVE.
Is that a normal feature? I remember having closed the launcher from time to time in the past without it closing the EVEs in the process. Most of the time when it just eat 100% of one core for no reason.
I also am seeing the zombie process on close issue. I’ll poke people about it.
I can’t get a repro on the “closing the launcher kills the clients” issue. Any chance Gentoo is doing something super-weird involving placing the eve instances under the process tree of the launcher, instead of launching them as independent processes?
I’ve just pushed beta 1734683, containing a partial fix for the zombie process issue.
The underlying issue is that there is a background thread that can fail to initialize properly, and if it does fail to initialize it blocks termination of the entire process. That will need to be fixed by the launcher team, and affects all platforms.
However, the elg warning people were seeing was a symptom of a problem which was causing that thread to fail to initialize 100% of the time, and I have fixed that issue. You’ll get one last zombie process when the update to 1734683 happens, as the version it’s upgrading from fails to close properly. After that, for most people the zombie process issue should go away.
I did update the launcher and here are the differences I did notice:
Closing the launcher do actually close the launcher (no more zombie!)
Closing the launcher while EVE run don’t kill the EVEs anymore, but I can’t focus on them anymore nor move the EVE windows with ALT-click+move like usual. There kind of frozen. issuing the usual “killall evelauncher” fix that focus problem and the EVE windows unfreeze.
Note : the EVE process are indeed under the launcher tree. I’m not sure it’s Gentoo related thru, could be because I use a custom wine?.
I do get them placed under the same process tree as you. When I close the launcher, the existance of the eve processes seems to block the launcher process from going away.
However, in my case, it seems that closing the launcher causes the eve clients to lock up a few seconds later. I guess your distro is more aggressive in murdering processes that don’t respond to a kill. It definitely didn’t do this before, but rolling back to current release causes the same behavior. Any idea when it started?
From time to time the QtWebEngineProcess crashes with following messages:
