Failed to establish shared memory mapping

[Duncan]

Martin van Es posted on Tue, 17 Nov 2015 12:50:35 +0100 as excerpted:

> Hi,
> 
> I've searched high and low but couldn't find a satisfactory answer to
> the question: why do all KDE/Plasma apps warn "Failed to establish
> shared memory mapping, will fallback to private memory -- memory usage
> will increase"?
> 
> I have /dev/shm mounted (tmpfs) and /dev/shm has drwxrwxrwt mode bits,
> /run/shm is a symbolic link to /dev/shm
> 
> What I find curious is that when I start the same app as root it doesn't
> show the warning, but I can't for the life of me understand why I can't
> establish shared memory as a user and can as root?
> 
> /dev/shm contains file that have pulse-shm in their name, and ipcs -a
> shows me many shared memory segments?
> So why can't KDE apps establish shared memory?

This /may/ be a result of some sort of security measures your distro has 
setup.  Unfortunately you didn't mention the distro and version you're 
running, but I've not seen such warnings here, on Gentoo/~amd64.

Also, you didn't mention what version of kde/plasma.  With many distros 
switching to kde-frameworks-5 and plasma-5, while others are still on 
kde4, and even where the switch to 5 has taken place, individual apps may 
remain kde4 based for the time being, this could be important, as well.

FWIW, kde4 here, tho I have most of a minimal kde-frameworks-5/plasma-5 
installed for easier testing, lacking only the few bits that can't be 
installed along with the kde4 versions, so I can keep what's configured 
and working, while quickly switching to the new versions for testing when 
I have time.

As for the warning itself, I don't believe it actually refers to shm.

KDE (at least kde4, and kde3 before it, and I'd guess plasma5 does 
something similar) normally starts up using a special initialization 
sequence that starts one process and then forks several others off it, 
doing it in such a way that they can share the same library (elf *.so 
shared objects) address space, etc, thus allowing shared libraries with 
faster launching and lower memory usage, even where security measures 
such as memory-space randomization would normally force separate 
applications to use their own separately randomized library addresses for 
the same libraries, making it impossible to share the same library 
address space and increasing memory usage.

I'd guess that this isn't working in your case for whatever reason, very 
possibly due to additional security measures taken by your distro.  If 
so, it really doesn't have anything to do with tmpfs or /dev/shm and its 
permissions, but rather, with whatever additional security measures your 
distro is enforcing.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.