Failed to establish shared memory mapping

Martin van Es mrvanes at gmail.com
Fri Nov 20 08:55:47 GMT 2015


Hi Duncan,

I feel your sentiment and I know how to bisect. I just don't have big can
of time lying around in storage and I hate to mess up my daily work laptop.
I could however create a testaccount with the offending configuration and
leave my normal account as it is now I think of it.

I still have the old homedir, so who knows what Xmass holidays will bring?

Thx for thinking along with this! I do have a synaptics touchpad and
configuring it does ring a bell...

Regards,
Martin

On Fri, Nov 20, 2015 at 5:19 AM, Duncan <1i5t5.duncan at cox.net> wrote:

> Martin van Es posted on Thu, 19 Nov 2015 15:09:52 +0100 as excerpted:
>
> > I just discovered that a newly created account doesn't suffer from this
> > warning. So what option in my carefully crafted (kde) configuration
> > could be responsible for plasma/kde not being able to initialize shared
> > memory?
>
> While I see you've solved the problem with a variant of what I was about
> to suggest, and I've not the /foggiest/ what might be causing it, when I
> have such a problem here with no real idea of where it might be, I use a
> "bisect" process to find the problem.  If you're familiar with git
> bisect, it's doing the same thing in a git context, except automating it.
>
> The idea with a bisect is to repeatedly "bisect" or split the problem
> space roughly in half, testing an often arbitrarily chosen half at each
> step to see if the problem remains in that half, or if it's in the other
> one, then repeating the bisect on the half now known to be the problem.
>
> Which is more or less what you did, by recreating your home dir and only
> copying back documents, .config, .local, and .kde, except you stopped at
> the first bisect step instead of recursing down into what was left to
> trace the problem further.
>
> Personally, I customize so heavily, and am curious enough about what
> might be causing my problem, that I'd never be satisfied with the single
> step.  I'd recurse bisect down until I found the individual file, then,
> assuming it's a text-based config file as kde files tend to be, I'd
> switch to a text editor and continue recurse-bisecting down to the
> individual configuration section within the file, and then probably down
> to the individual configuration line, to find the specific setting
> causing the problem.
>
> That way, the next time it or something similar, happened, I'd have a
> pretty good idea of where to look first, and would either try flipping
> that specific setting in the GUI, or simply try removing that file, as a
> quick test to see if I was on the right track, before reverting to bisect
> mode if it turned out to be a different problem this time.
>
>
> If you're up for it, I'd love to see you continue that bisect,
> particularly now that you know it's not in the big locations so there's
> far less to bisect down now, just because I'm curious about what could
> possibly trigger such an error, as well as confirming or disproving
> whether my initial guess that it might not be shm related after all, vs.
> yours that it was.
>
> Plus, knowing what it was might help me better help the next person
> (which for all I know might be me), and until we know what was causing
> it, there's no indication whether it might be a bigger problem and the
> list is about to get inundated with people asking about it...
>
>
> FWIW, the other conceivable thing I know of that it /might/ be, and that
> was definitely shm-based, would be a likely older synaptics driver
> touchpad device configuration tool, as I know they did in fact use shm
> some time ago, but AFAIK, that's deprecated usage now, and even then, it
> was primarily used when tweaking the initial configuration to get the
> settings just right for a specific hardware installation and individual
> user, and wasn't necessary once a user had appropriate settings to put in
> the permanent config.  Which might explain why you had forgotten about
> it, if you'd experimented with it some years ago and had long since
> gotten the settings you wanted, or even switched to non-touchpad hardware
> and don't even use the thing any more.
>
> As that was not kde specific it wouldn't have used the kde dir for its
> settings, and that usage probably predates the XDG standardization
> on .config and .local, so those settings would likely be in some other
> dot-file directly in your home dir, and thus not copied when you copied
> only the docs and .kde, .local, and .config dirs from your old home dir.
>
> So if an old synaptics or touchpad config possibly using shm rings a
> bell, that's where I'd look next.  Other than that, I'd certainly be
> bisecting here, as I literally have no other ideas, but would certainly
> be in hot pursuit of the problem and its location using bisect, once I
> knew for sure it was definitely within my specific user config.
>
> --
> 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.
>



-- 
If 'but' was any useful, it would be a logic operator
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde/attachments/20151120/e38467ee/attachment.htm>
-------------- next part --------------
___________________________________________________
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.


More information about the kde mailing list