From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike McCarty Subject: Re: cannot map temp file pool Date: Tue, 19 Sep 2006 11:48:52 -0500 Message-ID: <45101F74.9050107@sbcglobal.net> References: <450FE24A.30906@my.home> <450FEFA0.5070800@modsoftsys.com> <45100BB0.2020905@my.home> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <45100BB0.2020905@my.home> Sender: linux-msdos-owner@vger.kernel.org List-Id: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: dosemu 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!