IceWM crashes as of 4b8b7e1f

[marcelkorpel]

Since two weeks or so, all recent builds of IceWM crash immediately after starting (and sometimes, when started after compiling using Menu > Logout > Restart IceWM, it didn't crash then, but showed distorted icons in the taskbar).

After ploughing through commits, I managed to pinpoint the one that first causes crashes: it's 4b8b7e1f. I'm building using the Arch Linux AUR package with options

  ./configure --prefix=/usr --sysconfdir=/etc \
    --enable-shaped-decorations --enable-gradients \
    --enable-guievents --with-icesound=ALSA,OSS \
    --disable-menus-gnome2 \
    EXTRA_LIBS="/usr/lib/libsupc++.a"

Do you have any clue about what could cause these crashes?

[bbidulock]

Looks like I didn't push the latest icewm-git AUR package. Pull it again and try.

[marcelkorpel]

I did so, but no luck, it still crashes using the latest commit. Didn't retry earlier ones, though.

[bbidulock]

Strange, I can't get it to crash. I build in a clean chroot.

[bbidulock]

You could try my binary package at: http://www.unexicon.com/repo/pkgs/arch/os/x86_64/custom/icewm-git-1.4.2.1067-1-x86_64.pkg.tar.xz

[SolisX]

I'm also having problems with the current version of icewm. 1). Icons are corrupt.

2). If i go to look at the about icewm the window crashes.

3).If i right click on a window and select tray icon the window keeps moving down.

[marcelkorpel]

@bbidulock The package you provided also crashes.

@SolisX 1 is the same distortion I got initially. 3 is because IceWM crashes immediately after starting. The windows move down a bit after each crash to let you know the window manager crashed.

[bbidulock]

Sorry, can't get it to crash doing those things either! Do you have a coredump and an .xsession-errors file?

[marcelkorpel]

I cannot get IceWM to release a coredump. However, here's an .xsession-errors file: .xsession-errors.txt (the first 5 lines refer to xmodmap and are not related to this issue).

[bbidulock]

Try running icewm directly: e.g.

/usr/bin/startx /usr/bin/icewm >.xerrors 2>&1

If you look at the logs icewm-session says icewm died with signal 11; however, the debug logs say otherwise, because it continues logging without interruption. Anyways, running it directly should decide that issue.

[gijsbers]

Probably related: icewmbg only draws the top part of of the background for me. Valgrind reports:

==26824== Syscall param writev(vector[...]) points to uninitialised byte(s)
==26824==    at 0x74F9430: __writev_nocancel (in /lib64/libc-2.22.so)
==26824==    by 0x7E1264D: ??? (in /usr/lib64/libxcb.so.1.1.0)
==26824==    by 0x7E12A30: ??? (in /usr/lib64/libxcb.so.1.1.0)
==26824==    by 0x7E12AB0: xcb_writev (in /usr/lib64/libxcb.so.1.1.0)
==26824==    by 0x6662B85: _XSend (in /usr/lib64/libX11.so.6.3.0)
==26824==    by 0x665769D: ??? (in /usr/lib64/libX11.so.6.3.0)
==26824==    by 0x6658563: XPutImage (in /usr/lib64/libX11.so.6.3.0)
==26824==    by 0x426764: YXImage::renderToPixmap(unsigned int) (yximage.cc:901)
==26824==    by 0x421EBC: YPixmap::createFromImage(ref<YImage>, unsigned int) (ypixmap.cc:107)
==26824==    by 0x422254: YPixmap::load(upath) (ypixmap.cc:140)
==26824==    by 0x40A392: load (icewmbg.cc:74)
==26824==    by 0x40A392: pixmap (icewmbg.cc:47)
==26824==    by 0x40A392: get (icewmbg.cc:116)
==26824==    by 0x40A392: Background::getBackgroundPixmap() (icewmbg.cc:354)
==26824==    by 0x40A750: Background::changeBackground(bool) (icewmbg.cc:553)
==26824==  Address 0x8649a53 is 531 bytes inside a block of size 261,744 alloc'd
==26824==    at 0x4C29110: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==26824==    by 0x6665514: _XAllocScratch (in /usr/lib64/libX11.so.6.3.0)
==26824==    by 0x6657D3C: ??? (in /usr/lib64/libX11.so.6.3.0)
==26824==    by 0x665769D: ??? (in /usr/lib64/libX11.so.6.3.0)
==26824==    by 0x6658563: XPutImage (in /usr/lib64/libX11.so.6.3.0)
==26824==    by 0x426764: YXImage::renderToPixmap(unsigned int) (yximage.cc:901)
==26824==    by 0x421EBC: YPixmap::createFromImage(ref<YImage>, unsigned int) (ypixmap.cc:107)
==26824==    by 0x422254: YPixmap::load(upath) (ypixmap.cc:140)
==26824==    by 0x40A392: load (icewmbg.cc:74)
==26824==    by 0x40A392: pixmap (icewmbg.cc:47)
==26824==    by 0x40A392: get (icewmbg.cc:116)
==26824==    by 0x40A392: Background::getBackgroundPixmap() (icewmbg.cc:354)
==26824==    by 0x40A750: Background::changeBackground(bool) (icewmbg.cc:553)
==26824==    by 0x406B81: main (icewmbg.cc:928)

[SolisX]

Here is my xerror file. https://pastebin.com/PJuTDU3Z

[bbidulock]

Still can't get it to crash. I see the icon truncation, however, please open a new issue for that. Let's leave this one for what it was titled: i.e., the "crash".

[bbidulock]

@gijsbers what background are you loading? jpg?

[marcelkorpel]

Starting it directly using

/usr/bin/startx /usr/bin/icewm >.xerrors 2>&1

(or icewm-session) doesn't make it crash, so still no coredump. Apparently, only when starting IceWM using a display manager (in my case LightDM) results in crashes.

[marcelkorpel]

I just noticed that IceWM starts to crash as soon as there is a tray icon present. After starting X from the console no crash occured, but when opening keepass with this setting in winoptions

keepass2.tray: Exclusive

IceWM starts to crash. Still no coredump, though.

[marcelkorpel]

I misspelled the command, now my .xerrors looks like this: .xerrors.txt

[bbidulock]

How can there be an icewm-session log if you are not running icewm-wession?

[gijsbers]

I can reproduce the keepass crash easily:

==25241== Invalid read of size 8
==25241==    at 0x49000F: YXImage::composite(Graphics&, int, int, unsigned int, unsigned int, int, int) (yximage.cc:955)
==25241==    by 0x476D01: YIcon::draw(Graphics&, int, int, int) (yicon.cc:351)
==25241==    by 0x462AA6: TrayApp::paint(Graphics&, YRect const&) (atray.cc:133)
==25241==    by 0x48E007: YWindow::paintExpose(int, int, int, int) (ywindow.cc:755)
==25241==    by 0x48BC58: YWindow::handleEvent(_XEvent const&) (ywindow.cc:634)
==25241==    by 0x48F6DC: YXApplication::handleWindowEvent(unsigned long, _XEvent&) (yxapp.cc:1131)
==25241==    by 0x48F88D: YXApplication::handleXEvents() (yxapp.cc:1066)
==25241==    by 0x47E27C: YApplication::mainLoop() (yapp.cc:221)
==25241==    by 0x4085B6: main (wmapp.cc:1548)
==25241==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==25241== 
==25241== 
==25241== Process terminating with default action of signal 11 (SIGSEGV)
==25241==  Access not within mapped region at address 0x0
==25241==    at 0x49000F: YXImage::composite(Graphics&, int, int, unsigned int, unsigned int, int, int) (yximage.cc:955)
==25241==    by 0x476D01: YIcon::draw(Graphics&, int, int, int) (yicon.cc:351)
==25241==    by 0x462AA6: TrayApp::paint(Graphics&, YRect const&) (atray.cc:133)
==25241==    by 0x48E007: YWindow::paintExpose(int, int, int, int) (ywindow.cc:755)
==25241==    by 0x48BC58: YWindow::handleEvent(_XEvent const&) (ywindow.cc:634)
==25241==    by 0x48F6DC: YXApplication::handleWindowEvent(unsigned long, _XEvent&) (yxapp.cc:1131)
==25241==    by 0x48F88D: YXApplication::handleXEvents() (yxapp.cc:1066)
==25241==    by 0x47E27C: YApplication::mainLoop() (yapp.cc:221)
==25241==    by 0x4085B6: main (wmapp.cc:1548)

[gijsbers]

@bbidulock yeah some jpeg which is 2.3 times too big.

[gijsbers]

YXImage::composite incorrectly assumes that a Graphics always has a non-null color(), which leads to the crash...

[SolisX]

The icons problem for me is fixed in the lastest version of icewm. The crash however remains. I was able to log into icewm with my chromo icewm theme but when i switched to Dark-Ice theme icewm just kept crashing. The only difference i can think of the top of my head is that the taskbar size for Dark-Ice is bigger than with chromo.

[gijsbers]

Yeah Dark-Ice is really useful for testing. The icon upscaling is still no good as Dark-Ice shows vertical stripes for some icons for me now, but at least it doesn't crash anymore... This code wasn't yet ready to be used by non-developers.

[SolisX]

I tried that patch and Dark-Ice does not crash anymore. However i tried Nano-Blu and i see this.

[SolisX]

I guess that extra line and corruption was a problem with not having --enable-gdk-pixbuf.

[marcelkorpel]

But dependency on gdk-pixbuf2 has just been removed in the Arch Linux AUR package.

[gijsbers]

The extra line and corruption is still there in module yximage. More yximage corruption issues show up when the taskbar has lots of task buttons.