Unable to Open an X11 display on MacOSX

Timer · 09-16-2004, 03:32 PM

I've developed an Xlib program which runs with no problems in my Linux Mandrake 9.2. I sent a copy of the source to a friend who uses OSX Panther with X11 for Mac. He could compile it with no errors but a 'Bus error' message appeared. By doing some kind of 'e-debugging' I found I was getting a null display with

Code:

display = XOpenDisplay(NULL);

In the Xlib documentation it is said that the contents of the DISPLAY extern variable will be used in a POSIX-compliant OS when specifying NULL as an argument. This should be something like ":0.0".

Anybody knows why may this be happening or had a similar problem? I'm not sure if he was using OSX's UNIX terminal or X terminal, does this matter?

Cedrik · 09-16-2004, 04:19 PM

He has to lauch apple X11 app first, then type in a xterm provided by apple X11

dakensta · 09-16-2004, 04:22 PM

Quote:

I'm not sure if he was using OSX's UNIX terminal or X terminal, does this matter?

A bit.

Make sure that the X11 server is running (so click on it in /Applications/Utilities/X11 for Apples X11 implementation or wherever it is installed) and if he is running from the Terminal, make sure he types 'export DISPLAY=0:0' (for the now default bash shell) before trying to run it.

Alternatively run straight from an xterm which probably opens automatically when starting X11.

I'm not a Mac or X11 expert, but following these steps I haven't had any problems thus far. Error messages do vary a bit though, but I would have expected a message like "could not open display".

Timer · 09-17-2004, 04:10 PM

Thanks, we solved everything by running the app in xterm. About dakensta's post, is it possible to run an X11 server by some kind of

Code:

system("command");

?

I don't want Mac users being forced to use any kind of term.

Cedrik · 09-17-2004, 05:16 PM

you could use :

system("open /Applications/Utilities/X11.app");

to make sure X11 is started first, but assuming the user did not move the X11.app in another location.

Timer · 09-19-2004, 09:39 AM

When everything seems is going to work well, and you have done 99% of normal work, you find that the last 1% is such a weird bug that doesn't look like having a solution. This is my case. Let me continue my story a bit:

"Yes, it works with Xterm. I've attached a screenshot of your program to the e-mail."

"OK, thanks. But the version you compiled is deprecated! I'm sending you the new beta before it's publicly released. Compile it so I can make a binary release for both Linux and Mac."

The new version I'm refering only fixes a couple of bugs and adds small functionality.

"It doesn't work now!"

Now comes a long, long debugging session which finishes with the following code:

Code:

fastBMP = XShmCreateImage(hDC.display, DefaultVisual(hDC.display, hDC.nScreen),
	DefaultDepth(hDC.display, hDC.nScreen), ZPixmap, NULL, &sharedmem,
	pAmplada, pAltura);
fprintf(stderr, "Bytes to be located: %i\n", fastBMP->bytes_per_line*pAltura);
errno = 0;
sharedmem.shmid = shmget(IPC_PRIVATE, fastBMP->bytes_per_line*pAltura,
	IPC_CREAT | IPC_EXCL | 0777);
fprintf(stderr, "ShmID is %i\n", (int)(sharedmem.shmid));
fprintf(stderr, "Error while creating memory is %i\n", errno);
fprintf(stderr, "ENOMEM is %i\n", ENOMEM);
errno = 0;
Pixels = shmat(sharedmem.shmid, 0, 0);
fprintf(stderr, "Error while locating memory is %i\n", errno);
fastBMP->data = (char*)Pixels;
sharedmem.shmaddr = (char*)Pixels;
sharedmem.readOnly = False;
int j = XShmAttach(hDC.display, &sharedmem);
fprintf(stderr, "Error Number is %i\n", j);
fprintf(stderr, "Pixels Pointer is %i\n", (int)Pixels);
fprintf(stderr, "SharedMem Pointer is %i\n", (int)&sharedmem);
XSync(hDC.display, false);
fprintf(stderr, "OK\n");

As you can see, it deals with the MIT-SHM X11 extension.
And here is the output he sent me:

Code:

Default display is ':0.0'
Opening display ':0.0'
ShmID is -1
Error while creating memory is 12
Error while locating memory is 22
Error Number is 1
Pixels Pointer is -1
SharedMem Pointer is 5259708
X Error of failed request:  BadAccess (attempt to access private resource denied)
  Major opcode of failed request:  132 (MIT-SHM)
  Minor opcode of failed request:  1 (X_ShmAttach)
  Serial number of failed request:  14
  Current serial number in output stream:  15

But the error doesn't look to be X-related. The error comes from upper lines of code, concretely from the shmget function, which reserves an amount of shared memory. The 'bytes to be located' statement was not still implemented in this output, but later its result was a bit higher than 3MB.

"I'm gonna kill you! Error 12 (ENOMEM) stands for not enough memory available!"

"But I do have free memory! Take a look at this:"

Code:

Processes:  62 total, 6 running, 56 sleeping... 186 threads            00:58:32
Load Avg:  0.84, 0.56, 0.52     CPU usage:  29.5% user, 31.6% sys, 38.9% idle
SharedLibs: num =  124, resident = 27.8M code, 2.79M data, 6.36M LinkEdit
MemRegions: num =  7663, resident =  171M + 9.43M private,  104M shared
PhysMem:  66.6M wired,  177M active,  206M inactive,  450M used, 61.6M free
VM: 3.97G + 83.8M   168153(5) pageins, 103855(0) pageouts

Here finishes the story. If anyone knows how to help this poor, poor developer, please report it into this forum. I hope you'll have had a nice time while reading this!