search

lxqt / lxqt-config

Tools to configure LXQt and the underlying operating system
https://lxqt.github.io
GNU Lesser General Public License v2.1
83 stars 61 forks source link

lxqt config-appereance with huge window size crashes session #907

Closed ringo32 closed 1 year ago

ringo32 commented 1 year ago

i am using arch based endeavouros , after update of today appereance settings logsout to sddm

Expected Behavior
Current Behavior

when i start lxqt-config-appereance it logsout to sddm

Possible Solution
Steps to Reproduce (for bugs)
Context
System Information

https://0bin.net/paste/ef-hZK3Y#bcxfw7vSs5zPKmrV3MCT9y6fJcLxpgomU-Hv/H5f682

local/liblxqt 1.2.0-1

pacman log https://termbin.com/3kuh

tsujan commented 1 year ago

Please do this and attach what comes after where:

  1. coredumpctl gdb lxqt-config-app (or whatever the name is)
  2. where
tsujan commented 1 year ago

Never mind; your link shows no problem specifically in lxqt-config-appearance. There may be something wrong with the builds or with the upgrade in your distro.

Closing, but you could add comments or more info to this page

ringo32 commented 1 year ago

when i do your coredumpctl i get https://termbin.com/ty61k

but

when i do [ringo@lxqt ~]$ coredumpctl gdb lxqt-config-appearance No match found.

it logs out to sddm ..

with adding the path https://termbin.com/y2yz

tsujan commented 1 year ago

What comes after where is more human-readable; otherwise, it's the same as your link: no specific line about lxqt-config-appearance, except that it started and crashed. It suggests that the cause is something else. My guess is either a bad/incompatible build or an incomplete distro upgrade.

EDIT: Please also note that the crash isn't reproducible on Arch itself.

ringo32 commented 1 year ago

i stil figuring command for where . but wil look further what it is ..

ringo32 commented 1 year ago

nevermind.. Removed LXQT config folder in .config , seems to be resolved.

tsujan commented 1 year ago

lxqt-config doesn't have a folder. Its conf file is ~/.config/lxqt/lxqt-config.conf and only contains the window size.

Which WM do you use? Openbox, KWin,...?

tsujan commented 1 year ago

You could also check suspicious lines in ~/.local/share/sddm/xorg-session.log (error, warning,…).

tsujan commented 1 year ago

Oh, my mistake! You meant LXQt's config folder, namely ~/.config/lxqt/.

If the session crash doesn't happen after its removal, the only things that come to my mind are an impossible WM like kwin_wayland or starting of two compositors alongside each other; otherwise, I don't think lxqt-config-appereance can cause a session crash by itself.

tsujan commented 1 year ago

To be thorough, there's also a third possibility: Using a Qt style belonging to qt5-styleplugins after upgrading Qt. qt5-styleplugins should be recompiled after upgrading qt5-base (it's in AUR); otherwise, it might cause crashes in all Qt apps. It's better not to use it at all.

But I wonder whether a session crash is possible because of it. There's no trace of it in your backtrace either.

stefonarch commented 1 year ago

The folder/file is gone at all now? Would be interesting trying reproduce with those settings.

ringo32 commented 1 year ago

i dont have qt5-styleplugins only lightly-qt but not in use. i picked the config and packet had got only the wingmenu from menu in active lxqt.tar.gz

dont have searched what it was actually

stefonarch commented 1 year ago

I loaded the config in a debian VM. When opening lxqt-config-appearance the desktop freezes for about 10 sec and then the lxqt-session is crashing as descibed. Deleting lxqt-config-appearance.conf is enough to fix it. The screen size was huge:

[General]
ControlGTKThemeEnabled=true
__userfile__=true
size=@Size(32706 32673)

@ringo32 Any idea how you got those window size setting saved?

ringo32 commented 1 year ago

i dont know but wil try emulate the size was also after an update after all have to think i did resize te screen further no special i think have to play with it

stefonarch commented 1 year ago

With 10k it still works, with 20k it freezes.

EDIT: no, it just takes just very long to open with 20k x 20k. My wild guess: ram is filled up.

ringo32 commented 1 year ago

i have to review , my other ssd disk died on me had to reinstall te system found an old lxqt iso from a year old i made my own iso was pretty ugly too, but configured completly can't recall direcly how it came...

tsujan commented 1 year ago

The screen size was huge:

Interesting! With which WM? (I'd asked this above.)

stefonarch commented 1 year ago

Openbox, could test also with others.

Edit: With xfwm4 it's worse - it freezes, only cursor moves and stop, so hard reset is the only way out.

ringo32 commented 1 year ago

aur packages are also picom-conf sddm-conf , havent played with other wm's yet with this install past install was i3wm xfwm4 but xfwm4 does not work nicely for me as keybindings of lxqt-panel taskbar .. dont know why it it become huge that way. .

tsujan commented 1 year ago

@stefonarch, thanks for your tests!

With xfwm4 it's worse - it freezes

Wow! I thought WMs should handle such extreme situations.

Although this case is very rare, I think we should set the screen size as the upper limit wherever we save the window size. First we need a list of LXQt apps that save their window sizes — except for pcmanfm-qt, lximage-qt and LXQt file dialog, whose codes I'll check.

stefonarch commented 1 year ago

I see only 3 files:archiver.conf, lxqt-config.confand the one of this issue.

tsujan commented 1 year ago

On second thought, since all saved sizes are actual window sizes, there's no need to clutter our codes by artificially setting upper limits.

Long story short, the config files are correctly created by their corresponding apps. If a user edits them manually, he/she will be responsible for the probable consequences.

stefonarch commented 1 year ago

I wonder if it's possible by mouse moving or similar - it doesn't look edited, and it's hard to imagine somebody editing those numbers. Or a saving failure? BTW the apps are more:

 cat * |grep @Size
WindowSize=@Size(1846 931)
WindowSize=@Size(837 535)
WindowSize=@Size(969 556)
size=@Size(757 485)
size=@Size(1253 750)
size=@Size(794 496)
size=@Size(1012 714)
tsujan commented 1 year ago

I wonder if it's possible by mouse moving or similar

To a width of 32706? Theoretically possible, but it should be a wonderful mouse movement ;)

Or a saving failure?

Qt doesn't save anything when an I/O failure happens. It uses a temporary file.

Anyway, it's not our job to prevent extremely rare mistakes.

Bluey26 commented 12 months ago

Hello.

I was having a similar problem. Yesterday the program was working properly ( ~12 hours ago).

Today i tried to open it, crashed my system , ram goes from 600MB to +3GB, i have to kill the process or the mouse will freeze and i have to force restart.

Deleting the 'lxqt-config-appearance.conf' found in ~/.config/lxqt/ solved the problem. (Found it here, thanks!!! )

I do not recall anything special about changing the window size of lxqt-config-appearance.

The logs, when opening the program from the terminal, did not show anything different than now, that i have solved the problem.

This is the first time that this happens to me, i do not recall even updating any packages yesterday.

In any case, i use:

liblxqt 1.3.0-2 Qt: 5.15.11 LXQt 1.3.0 lxqt-config 1.3.0-1 OS: Arch Linux WM: Openbox

Reinstalling the program (before removing the .ini file) did not solve the problem either.

Bluey.

PS: the old .ini is this:

[General]
ControlGTKThemeEnabled=true
__userfile__=true
size=@Size(32767 32767)

Instead, now the program has regenerated the file, with:

size=@Size(740 448)

tsujan commented 12 months ago

size=@Size(32767 32767)

Something should have resized the window to that enormous size; the app itself doesn't do it.

Also, IMHO, checking the screen size and limiting the window size to it in the code each time a window is opened — as a workaround for such cases — isn't an option.

WM: Openbox

As Openbox's development stopped years ago, I suspect that this may be related to it. But that's just a wild guess.

Bluey26 commented 12 months ago

size=@SiZe(32767 32767)

Something should have resized the window to that enormous size; the app itself doesn't do it.

Also, IMHO, checking the screen size and limiting the window size to it in the code each time a window is opened — as a workaround for such cases — isn't an option.

WM: Openbox

As Openbox's development stopped years ago, I suspect that this may be related to it. But that's just a wild guess.

Yes, i agree.

It is something unpredictable, but i just wanted to report more info about it. In the other hand, i have not found a 'logout' behavior, it just freezes the pc, but i guess the underlying problem was the same.

Maybe its related to Openbox, that was a shared thing with the topic creator.