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!
-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
