X error: BadAccess (attempt to access private resource denied)
John Groenveld
An error has occurred. The following chain of information is available:
error 1: /Return/
message: X error: BadAccess (attempt to access private resource denied); serial: 108; major: 146; minor: 1; resource: 68;
The X servers are on Nevada B75 on a laptop and a patched S10 on W2100z
but when I boot Windows on my laptop and use X Win32, the application
works fine though spews a warning about MIT-SHM not being present.
How do I better debug this wierdness?
John
groe...@acm.org
gerryt
> My application recently began spewing this error:
> An error has occurred. The following chain of information is available:
> error 1: /Return/
> message: X error: BadAccess (attempt to access private resource denied); serial: 108; major: 146; minor: 1; resource: 68;
And that app would be...?
Knowing that, someone might be able to replicate the behaviour
> The X servers are on Nevada B75 on a laptop and a patched S10 on W2100z
> but when I boot Windows on my laptop and use X Win32, the application
> works fine though spews a warning about MIT-SHM not being present.
> How do I better debug this wierdness?
The usual tools like truss or dtrace
And as its happening on Nevada only(?) maybe try asking
at Opensolaris.org too I suppose
John Groenveld
MatrixOne.
>And as its happening on Nevada only(?) maybe try asking
>at Opensolaris.org too I suppose
Nevada and patched S10.
John
groe...@acm.org
Wolfgang
I have seen errors like this in a ssh-Environment, where new ssh client
use trusted cookies. I asume that the X you use also expect trusted
cookies, which the X Win32 dont expect and your application do not work
with. I dont know if X has a option to use the old style cookie behavior.
Wolfgang
gerryt
> In article <1194194855.346776.46...@i38g2000prf.googlegroups.com>,
Hmm - that's a lot of Google hits. I found matrixonesoftware.com
but its mostly broken links : <
An exact download URL might be helpful : >
John Groenveld
Wolfgang <wtr...@AT.web.de> wrote:
>I have seen errors like this in a ssh-Environment, where new ssh client
>use trusted cookies. I asume that the X you use also expect trusted
>cookies, which the X Win32 dont expect and your application do not work
>with. I dont know if X has a option to use the old style cookie behavior.
I am using X11 forwarding with SSH, but I am able to run
/usr/openwin/demo/xeyes.
John
groe...@acm.org
Wolfgang
i had the same behavior: some apps works some not, which can be very
confusing. i am not shure which combinations work.
Try to set the ssh Option ForwardX11Trusted to yes (ssh_config or
Commandline Option).
Wolfgang
Alan Coopersmith
The "major: 146" indicates it's an error from one of your X extensions
(since it's greater than 127). Extensions get their opcodes dynamically
assigned based on which ones are enabled in your configuration - to see
the current assignment of ids, run 'xdpyinfo -queryExtensions | grep
opcode' to see which opcode matches the one reported as "major".
--
Alan Coopersmith * al...@alum.calberkeley.org * Alan.Coo...@Sun.COM
http://blogs.sun.com/alanc/ * http://people.freedesktop.org/~alanc/
http://del.icio.us/alanc/ * http://www.csua.berkeley.edu/~alanc/
Working for, but definitely not speaking for, Sun Microsystems, Inc.
John Groenveld
Alan Coopersmith <al...@alum.calberkeley.org> wrote:
>The "major: 146" indicates it's an error from one of your X extensions
>(since it's greater than 127). Extensions get their opcodes dynamically
>assigned based on which ones are enabled in your configuration - to see
>the current assignment of ids, run 'xdpyinfo -queryExtensions | grep
>opcode' to see which opcode matches the one reported as "major".
$ /opt/mx1/scripts/system
An error has occurred. The following chain of information is available:
error 1: /Return/
message: X error: BadAccess (attempt to access private resource denied); serial: 108; major: 148; minor: 1; resource: 163;
$ xdpyinfo -queryExtensions | grep opcode | grep 148
MIT-SHM (opcode: 148, base event: 96, base error: 169)
John
groe...@acm.org
John Groenveld
I apologize for following up to my own post.
The tail end of the truss points in that direction:
1493: stat64("/opt/mx1/pixmaps/app/splash.gif", 0x080466D0) = 0
1493: open("/opt/mx1/pixmaps/app/splash.gif", O_RDONLY) = 7
1493: lseek(7, 0, SEEK_END) = 64494
1493: brk(0x09CA03F0) = 0
1493: brk(0x09CB03F0) = 0
1493: lseek(7, 0, SEEK_SET) = 0
1493: read(7, " G I F 8 9 aDE01AC01F7\0".., 64494) = 64494
1493: close(7) = 0
1493: brk(0x09CB03F0) = 0
1493: brk(0x09CE23F0) = 0
1493: shmget(IPC_PRIVATE, 128, 0777|IPC_CREAT) = 64
1493: shmat(64, 0, 0) = 0xD0310000
1493: shmdt(0xD0310000) = 0
1493: shmget(IPC_PRIVATE, 128, 0777|IPC_CREAT) = 65
1493: shmat(65, 0, 0) = 0xD0310000
1493: shmdt(0xD0310000) = 0
1493: shmget(IPC_PRIVATE, 128, 0777|IPC_CREAT) = 66
1493: shmat(66, 0, 0) = 0xD0310000
1493: shmdt(0xD0310000) = 0
1493: shmget(IPC_PRIVATE, 128, 0777|IPC_CREAT) = 67
1493: shmat(67, 0, 0) = 0xD0310000
1493: shmdt(0xD0310000) = 0
1493: uname(0x080467D8) = 1
1493: write(4, "940104\0\b\0 03 @\0\0\0".., 900) = 900
1493: read(4, 0x08046E90, 32) Err#11 EAGAIN
1493: pollsys(0x08046CB0, 1, 0x00000000, 0x00000000) = 1
1493: read(4, "\0\n l\0A3\0\0\001\094\b".., 32) = 32
1493: open("/usr/openwin/lib/X11/XErrorDB", O_RDONLY) = 7
1493: xstat(2, "/usr/openwin/lib/X11/XErrorDB", 0x08046B08) = 0
1493: read(7, " ! $ T O G : X E r r".., 35473) = 35473
1493: close(7) = 0
1493: brk(0x09CE23F0) = 0
1493: brk(0x09CEA3F0) = 0
1493: brk(0x09CEA3F0) = 0
1493: brk(0x09CF23F0) = 0
1493: brk(0x09CF23F0) = 0
1493: brk(0x09CF43F0) = 0
1493: brk(0x09CF43F0) = 0
1493: brk(0x09CF63F0) = 0
1493: fstat64(2, 0x080461B0) = 0
1493: write(2, " A n e r r o r h a s".., 73) = 73
1493: write(2, " e r r o r ", 10) = 10
1493: write(2, " 1 : ", 3) = 3
1493: write(2, " /", 1) = 1
1493: write(2, " R e t u r n", 6) = 6
1493: write(2, " /", 1) = 1
1493: write(2, "\n", 1) = 1
1493: write(2, "\t m e s s a g e : ", 10) = 10
1493: write(2, " X e r r o r : B a d".., 113) = 113
1493: write(2, "\n", 1) = 1
1493: llseek(3, 0xFFFFFFFFFFFFF000, SEEK_CUR) = 287744
1493: close(3) = 0
1493: lseek(1, 0, SEEK_CUR) = 690
1493: lseek(2, 0, SEEK_CUR) = 690
1493: lseek(2, 0, SEEK_CUR) = 690
1493: lseek(1, 0, SEEK_CUR) = 690
1493: lseek(2, 0, SEEK_CUR) = 690
1493: lseek(2, 0, SEEK_CUR) = 690
1493: _exit(1)
John
groe...@acm.org
Andrew Gabriel
groe...@cse.psu.edu (John Groenveld) writes:
> In article <fgoc6a$egq$1...@neuromancer.cse.psu.edu>,
> John Groenveld <groe...@cse.psu.edu> wrote:
>> MIT-SHM (opcode: 148, base event: 96, base error: 169)
I'm well out of my depth here, but since it relates to shared memory,
how about trying localhost TCP transport instead, e.g.
DISPLAY=localhost:0
rather than
DISPLAY=:0
--
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]
Gary Mills
>In article <fgodqg$h7f$1...@neuromancer.cse.psu.edu>,
> groe...@cse.psu.edu (John Groenveld) writes:
>> In article <fgoc6a$egq$1...@neuromancer.cse.psu.edu>,
>> John Groenveld <groe...@cse.psu.edu> wrote:
>>> MIT-SHM (opcode: 148, base event: 96, base error: 169)
>I'm well out of my depth here, but since it relates to shared memory,
>how about trying localhost TCP transport instead, e.g.
> DISPLAY=localhost:0
>rather than
> DISPLAY=:0
Is your system running out of shared memory? Are some other processes
leaving behind shared memory segments. Something like this will count
the number of segments:
$ ipcs -ma | grep ^m | wc -l
Here's a script that cleans up unused shared memory segments:
================8<================
#!/bin/sh
# rm-shm-seg: remove unreferenced shared memory segments
PATH=/usr/bin; export PATH
#### ipcs -mp:
#IPC status from <running system> as of Monday, October 15, 2007 6:33:20 PM CDT
#T ID KEY MODE OWNER GROUP CPID LPID
#Shared Memory:
#m 687865965 0 --rw-rw-rw- mills cserv 5005 3155
#m 117440622 0 --rw-rw-rw- umliu59 student 8150 8150
ipcs -mp | \
tail +4 | \
while read T ID KEY MODE OWN GRP CPID LPID XXX
do
ps -p "$LPID" > /dev/null 2>&1 || ipcrm -m "$ID"
done
#!/end
================8<================
--
-Gary Mills- -Unix Support- -U of M Academic Computing and Networking-
Alan Coopersmith
nv_76 did update the MIT-SHM extension to allow X clients in other zones
to use shared memory pixmaps for displaying on the X server in the global
zone, but the rest of the permission model should still be the same (the
X server checks the clients uid/gid against the shm segments access
control, much like access(3c) on a filesystem object).
There's a bit more detail in:
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6589829
Alan Coopersmith
|In article <fgodqg$h7f$1...@neuromancer.cse.psu.edu>,
| groe...@cse.psu.edu (John Groenveld) writes:
|> In article <fgoc6a$egq$1...@neuromancer.cse.psu.edu>,
|> John Groenveld <groe...@cse.psu.edu> wrote:
|>> MIT-SHM (opcode: 148, base event: 96, base error: 169)
|
|I'm well out of my depth here, but since it relates to shared memory,
|how about trying localhost TCP transport instead, e.g.
|
| DISPLAY=localhost:0
|
|rather than
|
| DISPLAY=:0
That won't disable shared memory on Solaris - older versions allow
shared memory when using TCP connections to an IP address returned from
an SIOCGLIFCONF ioctl (i.e. ifconfig -a), while the latest one (nv_76 &
later, and in the future, an S10 patch) allows it to any connection that
getpeerucred() can get local credentials for (which includes IP
addresses of other zones on the same system).
John Groenveld
John Groenveld <groe...@cse.psu.edu> wrote:
>My application recently began spewing this error:
>An error has occurred. The following chain of information is available:
> error 1: /Return/
> message: X error: BadAccess (attempt to access private resource
>denied); serial: 108; major: 146; minor: 1; resource: 68;
>
>The X servers are on Nevada B75 on a laptop and a patched S10 on W2100z
>but when I boot Windows on my laptop and use X Win32, the application
>works fine though spews a warning about MIT-SHM not being present.
My guess is that the application naively handles MIT-SHM.
Message-ID: <1992Apr14.0...@PA.dec.com> suggests that the
application should test MIT-SHM capability after interogating
the X server with XShmQueryExtension().
<URL:http://groups.google.com/groups?selm=1992Apr14.070937.28516%40PA.dec.com>
John
groe...@acm.org
anil...@gmail.com
hume.sp...@bofh.ca
There's forum necromancy, and then there's this... daaaaaaamn.
--
Brandon Hume - hume -> BOFH.Ca, http://WWW.BOFH.Ca/