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!