Crashes when used as standalone WM

[Trinity3e]

I use IceWM as a WM for LXQt session, since the last 5 or so major versions I have this issue where IceWM crashes under e.g. rapid window switching or rapid active/inactive state changes This happens in the default config aswell This does not happen in IceWM session (only when used as standalone WM)

As the crashes happen only sometimes, it will take me a while to give a log, as it requires manually starting and redirecting stderr, so sorry about that in advance

Edit1: I managed to make it crash, unfortunately no stderr output, only the last status was recorded terminated by signal SIGSEGV (Address boundary error). Next time I will try a trace.

[gijsbers]

There exists catchsegv, which gives a backtrace, which would be most helpful. Start it like catchsegv icewm.

Another option is to enable dumping of core files upon crashes and then use gdb /path/to/icewm /path/to/core and give it the command bt to obtain a backtrace.

Dunno if you do, but if you compile icewm yourself, replacing the -O compile options with -g would give the most accurate information.

What exactly is the difference between window switching and active/inactive state change?

What means rapid? 5 events per second?

How many windows total are running approximately?

I ask to simulate your situation myself.

Can't think of any reason why omitting icewm-session would change anything. Icewm-session restarts icewm automatically when it crashes and reports that in its output. You can get the location of the output file with lsof -p $(pgrep -x icewm) | grep -e 1w -e 2w.

[Trinity3e]

I will try with catchsegv, i have to somehow bring the binary on my arch based distro, hopefully these next few days i will be able to figure it out and run it as such.

The window that causes the crash may have some faulty elements, i remember in both particular cases it crashed they spam the xorg log with gtk/wxwidgets/qt lib errors and something about boundaries before the crash occurs. The programs themselves do not crash.

There are at least 2 other opened windows, and the crash may happen when bringing the program from the system tray or other hidden state, to the front, and then switching to another open window (possibly to the root window it can trigger easier). I would say ~3 events per second.

To be more particular, right now some programs who use WxWidgets are cosmetically broken in some distros, so try to run something like aMule in an Arch based distro and replicate above scenario.

And yeah, probably in icewm-session it runs as a userprocess so i don't notice the crash, i'l have to test that too.

I'll return when i gather some more info, thank you for the prompt reply.