icewm 3.7.0 carriage-returns in desktop files

[fungilife]

We built the way we always had, we built like arch, we built it from git with autoconf

very hard to debug, the whole system drops on its knees, even ssh access died,
It starts up either from xinitrc "exec icewm-session" and crashes/freezes when menu is clicked either from mouse or by panel, but even if left alone it crashes, kills icewm and restarts it

Only code I got with option -g by starting it on terminal is signal 9, we used -v no output.
Rolling back to 3.6.0 everything works as always had

Our system is very much like arch just no systemd or logind anywhere, build-tools are same versions, we also use eudev if that matters, all other wm X11 and wayland we have work flawlessly, so this is specific to icewm

Using a sleep function and killall icewm icewm-session seems to work, in getting us out of having to use hard button ..

[gijsbers]

Thanks for your report. Is that system a remote machine or a local VM? In the former you may have some kind of non-ssh serial connection for reliable communications and in the latter the VM-manager may provide a way to help debugging? There are ways to trace what is going on and get more insight using ltrace, strace, xtrace, etc. Icewm is just an X11 application like any other. If icewm could trash your system then any other application can as well. We first need more concrete information to help find a direction in our search for the cause. I tested 3.7.0 on eight very different systems and they all worked fine. Sofar only one clear bug was reported (the breaking of ModSuperIsCtrlAlt=1). Thanks and good luck!

[fungilife]

This is on local hard installation, no dm, no ck/logind, just xinit -->exec icewm-session and 3.6.0 works well
I have even resurrected old wm (twm, vtwm, jwm, blackbox, .. other floating and tiled) builds to see if any other wm triggers something that relates to X and input devices, the last msg I see on tty before freeze is kbd something, I'll try ltrace and so on and report back.

Minimal ltrace revealed this

  
--- SIGUSR1 (User defined signal 1) ---
--- SIGUSR2 (User defined signal 2) ---
--- SIGCHLD (Child exited) ---
--- SIGCHLD (Child exited) ---
02:23:13.054: icewm-session: icewm was killed by signal 9.
--- SIGUSR1 (User defined signal 1) ---
--- SIGUSR2 (User defined signal 2) ---
--- SIGCHLD (Child exited) ---
--- SIGCHLD (Child exited) ---
02:23:33.477: icewm-session: icewm was killed by signal 9.
--- SIGUSR1 (User defined signal 1) ---
--- SIGUSR2 (User defined signal 2) ---
--- SIGCHLD (Child exited) ---
--- SIGTERM (Terminated) ---
+++ exited (status 0) +++

the last exit was caused by running a sleep + kill function for 4m after start
I somehow think it relates to creating xdg menu on both the panel and r-mouse click
When I revert to 3.6.0 menus are fine

[gijsbers]

Good! When you say last thing is kbd, then I suggest running icewm --extensions for 3.7.0 to see if the new use of the xkeyboard extension may be involved. When you say xdg menu then I think that the new icewm-menu-fdo is involved. Check in your menu file how that is started and see if you can run it without icewm.

[gijsbers]

If you only replace the icewm-menu-fdo with the one from 3.6.0, does that make a difference?
Or replace icewm-menu-fdo with /usr/bin/true.

[fungilife]

I am not too familiar with icewm, I am trying to package it for joborun, so help me out.
In both machines tried the setup is pretty much default, and changing from 1 theme to the next didn't change anything. I have 2 files in ~/.icewm preferences which is blank and theme

I have now 3 pkgs I am contrasting, 3.6.0 3.7.0 (tar ball) 3.7.0 (git) and I haven't found much difference in the later 2.

I dumped the output of fdo and contrasted it
3.6

menu zzz folder {
prog zxzx 
prog jsjs
}

3.7

menu zzz folder {
    prog zxzx 
    prog jsjs
}

I am not sure where it is parsing the names and descriptions of the applications
grep Comment /usr/share/applications/*

There is one throwing the pattern off by adding a hard return on the description

	prog "DIN Is Noise
" din
 din
	prog

so if menu creation sensitive in finding menu prog or { after a hard return then it falls on its face

Version : 58.1-2
Description : A sound synthesizer and musical instrument.
Architecture : x86_64
URL : https://dinisnoise.org/

By removing the . at the end of the comment in .desktop didn't change anything, so is it just the name throwing it off?

/usr/share/applications/din.desktop

[Desktop Entry]
Encoding=UTF-8
Type=Application
Name=DIN Is Noise
Comment=DIN Is Noise.
Exec=din
Icon=din
Terminal=false
StartupNotify=false
Categories=AudioVideo;Audio

Can it be that simple?

By just removing the din.desktop file everything worked well

[gijsbers]

What are the exact parameters of your invocation of icewm-menu-fdo?
If I add your din.desktop to my system, I don't get your output glitch.
Is there maybe a hidden character in your din.desktop? Attach the exact file as attachment?

[fungilife]

just

icewm-menu-fdo >3.6.0
icewm-menu-fdo >3.7.0

diff 3.6.0 3.7.0

on 3,6

prog "DIN Is Noise" din din

[gijsbers]

Maybe @Code7R can shed light on what happens inside icewm-menu-fdo when it produces such a glitch in the output. What should be a single output line is here written in three lines instead.

[gijsbers]

The icewm-menu-fdo from 3.7.0 generates the following erroneous output on din.desktop:

        prog "DIN Is Noise^M" din^M din^M

It contains three carriage-returns when the din.desktop file terminates every line with a \r\n.

[gijsbers]

This fixes the problem also in icewm-menu-fdo for all input.

[vityank]

@gijsbers,

I need to verify if our RHEL9 crash-loop of v3.7.0 (The UI blinks like crazy with subprocesses starting+crashing(loop) in journalctl) is related to his issue or not(Installing v3.6.0 fixed the issue with all apps being left intact in the IceWm desktop).
Backtrace points to Menu parser, so can be very much related to this issue. I'll try to add this patch to the spec file and rebuild.
Update 1: My config files and files inside /usr/share/applications/ don't have CR character in them, so its possibly another issue...

Process 84018 (icewm) of user 1000 dumped core.

                                                    Stack trace of thread 84018:
                                                    #0  0x000055d0717f2800 _ZN9ObjectBar9addButtonE7mstring3refI5YIconEP12ObjectButton (icewm + >
                                                    #1  0x000055d0717f2e60 _ZN9ObjectBar9addObjectEP7DObject (icewm + 0xbfe60)
                                                    #2  0x000055d0717f8a72 _ZN10MenuLoader12parseProgramEPcS0_P15ObjectContainer (icewm + 0xc5a7>
                                                    #3  0x000055d0717f906c _ZN10MenuLoader10parseMenusEPcP15ObjectContainer (icewm + 0xc606c)
                                                    #4  0x000055d0717f99ba _ZN10MenuLoader9loadMenusE5upathP15ObjectContainer (icewm + 0xc69ba)
                                                    #5  0x000055d07179431b _ZN7TaskBar11initAppletsEv (icewm + 0x6131b)
                                                    #6  0x000055d071797786 _ZN7TaskBarC2EP4IAppP7YWindowP15YActionListenerP11YSMListener (icewm >
                                                    #7  0x000055d0717c5b1d _ZN6YWMApp10handleIdleEv (icewm + 0x92b1d)
                                                    #8  0x000055d071777fd4 main (icewm + 0x44fd4)
                                                    #9  0x00007f898b2295d0 __libc_start_call_main (libc.so.6 + 0x295d0)
                                                    #10 0x00007f898b229680 __libc_start_main_impl (libc.so.6 + 0x29680)
                                                    #11 0x000055d071786095 _start (icewm + 0x53095)
                                                    ELF object binary architecture: AMD x86-64

[gijsbers]

When I translate you trace with c++filt then I get this:

Process 84018 (icewm) of user 1000 dumped core.

Stack trace of thread 84018:
#0  0x000055d0717f2800 ObjectBar::addButton(mstring, ref<YIcon>, ObjectButton*) (icewm + >
#1  0x000055d0717f2e60 ObjectBar::addObject(DObject*) (icewm + 0xbfe60)
#2  0x000055d0717f8a72 MenuLoader::parseProgram(char*, char*, ObjectContainer*) (icewm + 0xc5a7>
#3  0x000055d0717f906c MenuLoader::parseMenus(char*, ObjectContainer*) (icewm + 0xc606c)
#4  0x000055d0717f99ba MenuLoader::loadMenus(upath, ObjectContainer*) (icewm + 0xc69ba)
#5  0x000055d07179431b TaskBar::initApplets() (icewm + 0x6131b)
#6  0x000055d071797786 TaskBar::TaskBar(IApp*, YWindow*, YActionListener*, YSMListener*) (icewm >
#7  0x000055d0717c5b1d YWMApp::handleIdle() (icewm + 0x92b1d)
#8  0x000055d071777fd4 main (icewm + 0x44fd4)
#9  0x00007f898b2295d0 __libc_start_call_main (libc.so.6 + 0x295d0)
#10 0x00007f898b229680 __libc_start_main_impl (libc.so.6 + 0x29680)
#11 0x000055d071786095 _start (icewm + 0x53095)
ELF object binary architecture: AMD x86-64

This relates to the parsing of the "toolbar" file within the TaskBar and hence is another issue. Is your "toolbar" file somehow different than ours? We can continue this issue here.

[gijsbers]

You can see which of the nine different configuration files it is processing by setting --trace=conf command line option or the Trace="conf" preference. Maybe attach your "toolbar"?

[vityank]

@gijsbers,
Thanks.
We have customized toolbar(And menu) with apps configured.
I can open new issue for this problem if you prefer :).
Toolbar file is attached.

toolbar.txt

[gijsbers]

This commit fixes this toolbar parsing bug.

[vityank]

@gijsbers,
Added th patches to the spec file:
Patch0001: icewm-3.7.0-menu-crlf.patch
Patch0002: icewm-3.7.0-menu-crlf-2.patch
Patch0003: icewm-3.7.0-toolbar-addButton.patch

IceWM online update works just fine. No more process crashing and DE seem stable.
Thanks.