linux xlib bug

Post Reply
ChrisC
Posts: 12
Joined: Wed Nov 29, 2006 9:27 am

linux xlib bug

Post by ChrisC »

I have used both jam and cmake to compile bullet
both methods create demos that behave like the output below
this effects ALL the demos...

Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified

freeglut (./BasicDemo): failed to open display ':0.0'


Any ideas most welcome!
ChrisC
Posts: 12
Joined: Wed Nov 29, 2006 9:27 am

FYI

Post by ChrisC »

Just grabbed svn trunk instead of the tgz mentioned on the wiki and it doesnt do the same
User avatar
SteveBaker
Posts: 127
Joined: Sun Aug 13, 2006 4:41 pm
Location: Cedar Hill, Texas
Contact:

Post by SteveBaker »

Let me explain what the message means. I apologise for the length of the explanation - but I don't know how much you already know so I have to start from scratch.

The X-windows system is split between the 'client' and the 'server'.

The client and server theoretically talk to each other over a network connection so that the application can run on some remote 'server' computer while it's graphics and GUI are rendered on a 'client' machine that you are sitting in front of.

So the X client is the thing that draws stuff onto your screen - the X server is the software that your application code talks to. Of course on a modern PC, the client and server are typically the same computer and the network connection isn't really there - so all of this wonderous flexibility isn't really obvious.

But - if you do run the program on one computer and display on another - there is a network connection. There is also a network-like connection (a UNIX 'socket') if you run the program under one user ID when you logged in as another. So I log in as 'steve' and then do an 'su bob' and then try to run the program - then X will use a socket for the connection between the program (being run by 'bob') and the X client (being run by 'steve').

How does an application program know which X client to talk to? Well - there is a shell variable 'DISPLAY' that takes the form:

export DISPLAY=machine:client.screen

Where 'screen' and 'client' are going to be '0' on all but some very exotic setups and 'machine' defaults to the computer your application is running on. Hence, the default value for DISPLAY is :0.0 -- so...looking at your error message:

Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified

...it seems that the Xlib 'server' library (which your program links with) cannot talk to the X client (which draws the pictures).

When the X server has to talk to the X client via the network (if you are running a program on a computer other than the one you are sitting in front of - or if you did an 'su' or a 'sudo' to a different user) - then there is a permissions issue.

You wouldn't want any idiot out on the Internet being able to send X-windows server commands into your PC's X-client because that would allow them to pop up windows on your desktop, read your keystrokes and your mouse clicks!! (YIKES!!!!) So the X client has security settings that permit you to limit who can talk to your computer. The defailt setting is very, very conservative. It only allows programs being run by you on your computer to write to the screen.

So - if you try to run a program that does GUI operations (like all of the Bullet demos) whilst 'su'ed or whatever then you'll run into the security barrier and your X client will refuse a connection.

Hence the error message.

So - either "Don't Do That" - or you need to change the security settings on your X-client.

The program that sets the X-client settings is called "xhost" - do a "man xhost" to find out how to use it. xhost has to be run on the client machine as the person who logged in - so run xhost BEFORE you 'su' or remote login or whatever.

As a quick test, running 'xhost +' - that opens up all of the permissions to all machines (which sounds pretty dangerous - and it might be if you leave it set like that for weeks at a time!)...that should make your program work just fine.

Another remote possibility is that you've done something 'exotic' like running multiple X clients on your machine at the same time (in which case you'll have DISPLAY=:0.0 for one display and DISPLAY=:1.0 on the other...there are lots of possibilities.

I hope this rather long explanation helps.
User avatar
SteveBaker
Posts: 127
Joined: Sun Aug 13, 2006 4:41 pm
Location: Cedar Hill, Texas
Contact:

Re: FYI

Post by SteveBaker »

ChrisC wrote:Just grabbed svn trunk instead of the tgz mentioned on the wiki and it doesnt do the same
I'm 99% certain that this has nothing whatever to do with Bullet or the demo program itself. It's much more lilkely that you were remotely-logged in somewhere or su'ed to another user when you were having problems - and not when your tried it again.

If you have the problem again - try running something really simple like 'xcalc' or 'xclock' or something - I bet it'll come up with the same error message.

If this were (VERY unlikely) an application program problem, it couldn't be in Bullet or the demo program - it would have to have been inside 'freeglut'. (I happen to own/run the freeglut project) - but if the problem fixed itself without you downloading a new freeglut library - I don't think it could be a bug in there.

So - as I said - it's 99% certain to be something to do with how you were logged in when you ran it.
ChrisC
Posts: 12
Joined: Wed Nov 29, 2006 9:27 am

Post by ChrisC »

I think you are probably right I d/loaded 2.37.tgz and tried again
(if the wiki link hasnt changed in the last day or so then thats the version I first used)

Theres no problem with 2.37, god knows what caused the auth problem with X most strange, I cant replicate it!

Sorry for the waste of time!

:oops: !
User avatar
SteveBaker
Posts: 127
Joined: Sun Aug 13, 2006 4:41 pm
Location: Cedar Hill, Texas
Contact:

Post by SteveBaker »

ChrisC wrote:Theres no problem with 2.37, god knows what caused the auth problem with X most strange, I cant replicate it!
Well, if you type:

su {some other user}

...enter the password - then run your program (without setting 'xhost') - it'll do it again. But so will xclock, xcalc, etc.

What's cool is that you can run X programs that do graphics on a computer way over on the far side of the Internet and have the GUI pop up on your local machine while all of the work is done on the remote machine.
ChrisC
Posts: 12
Joined: Wed Nov 29, 2006 9:27 am

Post by ChrisC »

oh man I know what I did...

I su'd to make install in jam and then forget to exit :oops:

I gotta say this is one impressive lib ! thanks guys!
User avatar
SteveBaker
Posts: 127
Joined: Sun Aug 13, 2006 4:41 pm
Location: Cedar Hill, Texas
Contact:

Post by SteveBaker »

ChrisC wrote:I su'd to make install in jam and then forget to exit :oops:
Ha! I win!
User avatar
Erwin Coumans
Site Admin
Posts: 4221
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Post by Erwin Coumans »

SteveBaker wrote:
ChrisC wrote:I su'd to make install in jam and then forget to exit :oops:
Ha! I win!
Yeah, but Bullet would be better if we had a build system for Unix that works out-of-the-box. CMake is very nice, but it requires installation. I use Jam mostly to autogenerate MSVC projectfiles that don't depend on CMake. Also Jam has very good dependency/compile times.

To avoid build system hassle, I want ordinary Makefiles configured by autotools. Ideally ./configure will configure both Jam and Unix Makefiles.
Then you just type 'make', instead of the Jam hassle.

Can someone help with autotools so './configure' generates Makefiles next to Jamfiles?
Erwin
User avatar
SteveBaker
Posts: 127
Joined: Sun Aug 13, 2006 4:41 pm
Location: Cedar Hill, Texas
Contact:

Post by SteveBaker »

Erwin Coumans wrote:Yeah, but Bullet would be better if we had a build system for Unix that works out-of-the-box.
I agree - but it wouldn't have helped in this case. You need to 'su root' to install most serious packages - and if you forget to log out - and if you have your X permissions set 'right' - it'll refuse to run any X-based applications.

So it doesn't matter what installation system you use - you'll have the same chance for 'operator error'. It's the price you pay for Linux quality security.
Post Reply