#68 X Error: BadAccess (attempt to access private resource ...)


First I'd like to state that there was already a very similiar bug in Feb 2007, but I think it had a different cause.
(It was "BadAccess - MIT-SHM - X_ShmAttach - ID: 1658510")

The recordMyDesktop version used is: v0.3.8.1
(as currently available in Ubuntu 10.10, the full package version is

I tried to record a screencast inside an LTSP session (running an Ubuntu Maverick based LTSP thin client) with default settings using gtk-recordmydesktop and the following error message was returned:
"exited with status 256 error while parsing the arguments"

Did not give up just yet. In gtk-recordMyDesktop-crash.log I saw the following:

#This is the command given at initialization:
recordmydesktop -o /home/myuser/out.ogv --fps 15 --channels 1 --freq 22050 --v_quality 63 --s_quality 10 --workdir /tmp

#recordMyDesktop stderror output:
Initial recording window is set to:
X:0 Y:0 Width:1680 Height:1050
Adjusted recording window is set to:
X:0 Y:4 Width:1680 Height:1040
Your window manager appears to be Metacity

Buffer size adjusted to 4096 from 4096 frames.
Opened PCM device default
Recording on device default is set to:
1 channels at 22050Hz
X Error: BadAccess (attempt to access private resource denied)

Running recordmydesktop with the above commandline resulted in the same error message.
I've downloaded the Ubuntu package source, added stacktrace logging (via backtrace_symbols_fd) to rmd_error.c in rmdErrorHandler and got the following result on stderr:

X Error: BadAccess (attempt to access private resource denied)
backtrace() returned 10 addresses

From this I instantly got the idea: in LTSP we cannot use MIT-SHM! Running recordmydesktop with the "--no-shared" option worked like a charm (the video had no sound, but that's another matter).

Now the question is whether this is a bug or not. I'm not too familiar with X programming and do not know recordmydesktop's source that much. However I've found that the LTSP client starts Xorg in auto-configuration mode (ie. Xorg detects all settings) and unfortunately it loads the MIT-SHM extension as well. I could confirm this by running an "xdpyinfo -ext MIT-SHM" and the output contained:
MIT-SHM version 1.1 opcode: 141, base event: 77, base error: 150
shared pixmaps: no

My guess is that recordMyDesktop does not try to detect whether MIT-SHM extension is available or not. But even if it did, that'd not be enough. I think that recordMyDesktop tries to use "shared pixmaps" (as detected by xdpyinfo), but does not lookup for shared pixmaps support. If that's the case, then this is a bug and should be fixed.

Ie. recordMyDesktop should test (in case shared memory should be used based on defaults and current commandline options) whether shared pixmaps are supported or not (the code for this could be looked up in xdpyinfo's source) and exit with a user-understandable error message about the missing shared pixmaps support (and that "--no-shared" option should be used). Or maybe it could just print a warning about the missing shared pixmap support and automatically fall back to the use of the "--no-shared" option.