Re: cannot map temp file pool

[Mike McCarty <Mike.McCarty@sbcglobal.net>]

Jan Willem Stumpel wrote:
> Damyan Ivanov wrote:
> 
> 
>>>WTH is this? No idea what "map temp file pool" means. I hope
>>>someone is still around who can answer this. The dosemu font was
>>>always OK, BTW.
>>
>>
>>I'd run xdosemu under strace and look for "permission denied" errors
>>there.
> 
> 
> I tried that -- but could not make sense of it. I get things like

These things make some sense to me. Perhaps I can help. Someone with
the source can help better.

> open("/dev/shm/dosemu_16975", O_RDWR|O_CREAT|O_TRUNC|O_NOFOLLOW,
> 0600) = 5

open(.,.,.) opens files or devices for reading or writing, and
returns a small positive integer on success. This integer is
used for later calls to do things to the file or device.
If it fails, it returns -1. This indicates successful open
on /dev/shm/dosemu_16975 with READ+WRITE, CREATE if non-existent,
TRUNCATE an existing file and reuse it, do NOT FOLLOW links.

Now, /dev/shm is SHARED MEMORY. It is there to allow multiple
processes to access the same memory area without having to
use interprocess communication. There is no file involved.

The open channel number (FD or File Descriptor) is 5.

> fcntl64(5, F_GETFD)                     = 0

fcntl(fd,option,...) does various File CoNTroL operations.
It returns 0 for success, -1 for an error. FD number 5 (return
from above open) was successfully queried.

   F_GETFD
        Read  the  close-on-exec flag.  If the FD_CLOEXEC bit is 0, the
        file will remain open across exec, otherwise it will be closed.
 

> fcntl64(5, F_SETFD, FD_CLOEXEC)         = 0

Again, FD 5 has had an option set successfully.

  F_SETFD
        Set  the  close-on-exec  flag  to  the  value  specified by the
        FD_CLOEXEC bit of arg.

In this case, set to TRUE.

> unlink("/dev/shm/dosemu_16975")         = 0

The "file" has been "removed". This means it has been marked
by the system for removal. But it is still open (we guess,
since no close() has been done), so the "file" still exists,
but when it is closed, it will automagically go away.

IOW, when all processes have relinquished access to the
shared memory (like by exiting to the system), then the
shared memory will be returned to the pool.

> ftruncate(5, 0)                         = 0

ftruncate(Fd,Size) sets the size of a file. I suppose
that in the case of shared memory, it resizes it. This
is a successful call.

> ftruncate(5, 15794176)                  = 0

Ditto. It successfully changed FD 5 to 15794176 bytes.

> mmap2(NULL, 15794176, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_SHARED,
> 5, 0) = -1 EPERM (Operation not permitted)

This is a POSIX call, IIRC.

This call has failed. mmap2() attempts to map a shared memory region
to a real process relative memory address so it can do accesses.
 
      void * mmap2(void *start, size_t length, int prot, int flags, int  fd,
        off_t pgoffset);

start	the requested start location in memory; this is only a
	suggestion, and the system may not use the requested
	address. NULL means you are willing to accept whatever
	the system gives you (which is what is going to happen,
	anyway)

length	number of bytes to map to the process memory

prot	access protection requested

flags	some access flags

fd	File Descriptor (5 in this case, our shared memory region)

pg_offset	offset into the shared memory region to start
		mapping. In this case, no beginning piece
		is skipped over, we want it all.


This call, when it succeeds, returns a pointer to the shared memory
region. Again, this was done on FD 5. The requested
permissions are READ, WRITE, EXECUTE, flags are SHARED access.
The return indicates that the operation failed (-1) and
the errno indicates PERMISSION DENIED.

So, it appears that something is wrong with your permissions
on /dev/shm/dosemu_16975.

$ ls -ld /dev/shm
drwxrwxrwt  2 root root 40 Sep  8 06:57 /dev/shm

My shared memory is accessible to everyone, apparently.

I wonder whether your permission bits are incorrect on
/dev/shm.

> write(4, "ERROR: MAPPING: cannot map temp "..., 67) = 67

This is a successful attempt to write some byes to
FD 4 (probably some log file). It tried to write 67 bytes,
and wrote 67 bytes. This is a successful call, probably
reporting the mmmap2() failure.

> write(2, "ERROR: MAPPING: cannot map temp "..., 67) = 67

This is a successful attempt to write to FD 2 (stderr, the
standard error reporting file, likely your display) probably
the very same message.

> 15794176 is some suspiciously "round" number (hex 00F10000).

It's the length of the mapped area. It's normal for this
to be a "round" number.

> I'd appreciate any ideas.

Well, hopefully I've given you some.

Mike
-- 
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!