Closed maguilara closed 3 years ago
Martchus
commented
3 years ago Strange, maybe there's UB somewhere in the code. Launching another instance will deligate to the first process, that's why it is working.
Did it work before some update? Which desktop environment do you use and which process is "menu"? Did you somehow customize the *. desktop file? Does it happen with the Qt 6 based version as well? Does it work with a clean config file (e.g. move the config file temporarily somewhere)?
Martchus
commented
3 years ago Not sure how to get output when launching it via the menu.
You can launch the "menu" (whatever process it is, possible the graphical shell you're using) manually from a terminal. A stacktrace (e.g. obtained via coredumpctl) would be helpful as well.
maguilara
commented
3 years ago Did it work before some update?
First time installing STT, so no baseline.
Which desktop environment do you use and which process is "menu"?
I'm using KDE. I refer to menu to the "Application launcher" widget found on KDE.
Did you somehow customize the *. desktop file?
When it failed I tried to customize the .desktop file adding the ampersand symbol, because why not, didn't work either and reverted to the original config (which is simply 'syncthingtray').
Does it happen with the Qt 6 based version as well?
Can't say nothing about the qt6, will try to give it a try.
Does it work with a clean config file (e.g. move the config file temporarily somewhere)?
I deleted the config and it worked fine, so I have isolated the issue that when I toggle the option to autolaunch syncthing, the app borks and behaves like I've mentioned before. I'll try to get the stacktrace.
maguilara
commented
3 years ago Here is the output I got from using the following command: coredumpctl debug --debugger-arguments="-batch -ex 'info all-registers'" , following the manpage for it. Let me know if this is correct.
https://pastebin.com/1WkG7iy9
Martchus
commented
3 years ago Judging by the stack trace, the C++ standard library fails to create a locale. It looks like the locale isn't setup correctly on your machine. Did you follow https://wiki.archlinux.org/title/Locale#Generating_locales ?
And now, since you know the actual source of the problem, can you launching from a terminal to get the exception message? (But I bet it looks like this: https://stackoverflow.com/questions/18686466/stdlocalefacet-s-create-c-locale-name-not-valid)
maguilara
commented
3 years ago Sorry, forgot to mention that when launching from console it does work, crash only happens when launched "standalone" via *.desktop file (?) Not sure what's the correct term. But it doesn't happen because my .zshrc file has set the LC_ALL/LCLANG environmental variable, when I commented those bits (I think I added them for a similar issue with other programs), it now fails when launching from shell with the error you indicate. Plasma also adds their own LC related envs from .config/plasma-localerc, deleted those just in case, r-configured the locale, rebooted and now it works. But I see a new aesthetic (?) bug, an orphan plasmoid appears on the system tray even when STT hasn't been initialized yet, and when I start STT, another one appears which is linked to this stt process. Is this a known issue?
Martchus
commented
3 years ago an orphan plasmoid appears on the system tray even when STT hasn't been initialized yet. Is this a knows issue?
I'm not exactly sure what you mean but I'm aware that sometimes the Plasmoid shows up as part of the system tray Plasmoid and one has to disable it there manually again. That seems to be a limitation of Plasma, though.
Good that we could pin down the issue. I guess you're not the first user hit by this issue. I remember one had problems running tests because the build environment lacked the correct locale setup. It would be good if one would get a warning instead of a hard crash and if it would just fallback to the "C" locale which should hopefully always work. Not sure whether that would be possible but I suppose I could check out that possibility.
maguilara
commented
3 years ago I'm not exactly sure what you mean but I'm aware that sometimes the Plasmoid shows up as part of the system tray Plasmoid and one has to disable it there manually again. That seems to be a limitation of Plasma, though.
I'll open a new issue then, just in case someone else experiences it too.
It would be good if one would get a warning instead of a hard crash and if it would just fallback to the "C" locale which should hopefully always work. Not sure whether that would be possible but I suppose I could check out that possibility.
That seems the most sensible choice, but it's a common failure not being able to default to a locale. Not sure why.
Martchus
commented
3 years ago It doesn't look like you've created a new issue but the unhandled exception should be fixed by https://github.com/Martchus/syncthingtray/commit/239d75134221aae1edd08ac6eac2f6d25402184c.
Relevant components
syncthingctl)libsyncthing)Environment and versions
syncthingtray,qtutilitiesandc++utilities: 1.1.10-1, 6.5.0-1, 5.11.1-1Bug description Launching the SyncthingTray from the menu fails.
Steps to reproduce
Expected behavior Launching syncthingtray should make appear the syncthing tray icon and launch syncthing too (syncthingtray handles the syncthing process)
Screenshots N/A
Additional context When launching via the menu, for a brief moment appears the syncthing icon on my taskbar, as if the web GUI had been requested, and then it dissapears and STT fails to launch. Launching via the terminal, syncthingtray works fine, and the previous behaviuor does not happen. Only output I get from launching via the terminal is:
Not sure how to get output when launching it via the menu.
EDIT: Okay, when launching via the terminal and keeping that one alive, if I try to open another instance of STT via the menu, it works. And I can keep opening multiple instances. BTW, the behaviour of the ST icon appearing briefly in the taskbar keeps happening when launching via the menu.