#104 Hang when running fre:ac under KDE

Next snapshot
closed
None
1
2015-11-20
2015-07-30
No

How to reproduce:
- install linux distro with KDE5 (e.g. this: http://cdimage.ubuntu.com/kubuntu/releases/15.04/release/kubuntu-15.04-desktop-amd64.iso.torrent), or run kwin_x11 5.x on existing distro
- run linux version of fre:ac
- have to reboot or restart X11
Checked on Kubuntu and Arch (both 64bit), Radeon HD 7850 GPU + opensource drivers (no Catalyst)

Discussion

  • AX Redneck 34noff

    p.s. Only Kwin + fre:ac cause problem, not fre:ac + other window manager nor Kwin + other tested software.
    p.s.2. Disabling compositing doesn't solve problem so it's hardly because of GPU or it's driver.

     
  • Robert Kausch

    Robert Kausch - 2015-07-30

    Thank you for reporting this!

    I managed to reproduce the issue on KaOS x64 and found out that it's caused by code that tells the window manager which icon should be used for window decorations and on the panel button.

    An easy work-around is to delete or rename the freac.png file in the icons subfolder. fre:ac will then be unable to load its icon and the window manager will use a default one.

    This is very likely a bug in kwin, not in fre:ac. The window manager just should not hang up and block the system, even if it cannot handle data sent by an application. However, I will see if I can do anything to avoid this issue in fre:ac.

    Will further investigate this tomorrow.

     
  • Robert Kausch

    Robert Kausch - 2015-07-30
    • assigned_to: Robert Kausch
     
  • AX Redneck 34noff

    Thank You for workaround! Now i can use Kwin at least.

     
  • Robert Kausch

    Robert Kausch - 2015-07-31

    So, I have a fix now.

    The reason for this issue is complicated. The root cause lies in the X11 API which is conceptually broken on x64 platforms in that it requires 32 bit values to be passed using 64 bit due to the long type (that changes size to 64 bit on x64) used in the original xlib headers.

    fre:ac (or rather the smooth library used by fre:ac) did not respect this requirement and used X11's CARD32 type to pass 32 bit cardinals. The internet is undecided on whether CARD32 should be 64 bit on x64 platforms, but apparently on the system I used to build fre:ac, it stays 32 bit.

    The fix was to replace the CARD32 type with the 64 bit unsigned long when dealing with 32 bit cardinals...

    Now to the KDE side: Most window managers on x64 just ignored the icon data passed by fre:ac and displayed it without an icon. KWin, however, does insufficient sanity checking on the data and as a result tries to copy a huge amount of memory, thereby accessing invalid memory regions and causing itself to crash.

    This insufficient checking was reported to the KDE team and fixed in 2004 - but sadly reintroduced in KDE 5...

    So, unfortunately this was a combination of bugs in fre:ac and KDE. I'm reporting this on the KDE bug tracker. Thank you for finding it!

    Attached is a fixed smooth library for Linux x64. x64 packages for Linux and FreeBSD have been updated on the download page as well.

     
  • Robert Kausch

    Robert Kausch - 2015-07-31
     
    Last edit: Robert Kausch 2015-08-18
  • Robert Kausch

    Robert Kausch - 2015-07-31
    • status: open --> pending
     
  • AX Redneck 34noff

    Thanks! This libsmooth.so isn't odds with Kwin. fre:ac's window appears with icon.

     
  • Robert Kausch

    Robert Kausch - 2015-08-18

    The KDE project has fixed their part of this bug in kwindowsystem 5.13. After upgrading to that package version, you should be able to run older versions of fre:ac under KDE again.

    By the way, fre:ac has been selected to take part in the October 2015 Project of the Month Vote. It would be great if you could leave a vote for fre:ac (bonkenc) at that page!

     
  • Robert Kausch

    Robert Kausch - 2015-08-26
    • status: pending --> closed
     


Anonymous

Cancel  Add attachments





Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks