“Bill Caroselli (Q-TPS)” <qtps@earthlink.net> wrote:
OK. Either I misunderstood the original statement or I’m not understanding
your reply to me.If I do stuff to map some memory and I don’t munmap() it, then the
references count should NOT go to 0. The OS should NOT be free to give that
memory to another process.
I agree that it would be nice, and I realize that most other OSes work
that way. Unfortunately, QNX4 doesn’t, and that’s what the text I
quoted explains. QNX4 only counts fds as “references”, and mmaped pages
do not count. If you want to safely access the mmaped memory after the
shared object has been unlinked, you must keep an fd to it. That’s
documented behaviour – the fact that it’s non-standard doesn’t
necessarily make it a bug.
If the text that you are quoting is pointing out some possible benefit to
this behavior, I don’t understand what it could be.
The text doesn’t say that, but my guess would be that the main benefit
is simplicity of implementation. If I remember correctly, the original
QNX 4.0 did not have support for mmap() – it was added later, and it
probably was too difficult at that point to add code to Proc to keep
track of which shared object each page of memory belongs to.
Regarding your kill() code, if the executing code is valid then the OS must
do what it is told to do. But the OS is smart enough to at least check that
you are sufficiently priveleged before raising the signal.
Yes, but my point was that the OS may not be able to know whether your
code is valid or not. If a bug causes your code to ask the OS to do
something that looks valid (but is not what you meant), the OS will do
it, and that may “adversely affect another program”. I was just trying
to give an example of why your suggestion, taken literally, is way too
general to be realistic:
IMHO, ANY program bug should not adversly affect another program.
“Wojtek Lerch” <> wojtek@qnx.com> > wrote in message
news:9pd9m7$2br$> 1@nntp.qnx.com> …
“Bill Caroselli (Q-TPS)” <> qtps@earthlink.net> > wrote:“Gui Group” <> gui@qnx.com> > wrote in message
news:9pcig2$hup$> 1@nntp.qnx.com> …
If you do shm_open(), mmap(), close() and then shm_unlink() without
munmap(), then the memory you have mmapped stays mmapped but is
considered free memory and may get allocated to another (or the same)
process. Modifying it may cause that process to misbehave or crash.Please tell me that, this is being dealt with as a kernel bug.
I think it’s considered a feature.
From /etc/readme/technotes/shmem.txt:
2.2. close, unlink
The close system call releases the filedescriptor for
the shared memory object. The unlink system call causes the
shared memory object to be deleted. Unlink has the same
portability concerns as open and creat, thus there is a sim-
iliar function shm_unlink which hides the path /dev/shmem
from the application. Shared memory objects have a refer-
ence count attached to them. When the object is created,
the reference count is set to 1. Every time a filedescrip-
tor is opened to the object, the reference count is incre-
mented. Every time a filedescriptor to the object is
closed, the reference count is decremented. When the refer-
ence count reaches 0 (only possible if the object has been
unlinked and there are NO open file descriptors to it), the
memory associated with the object is returned to the system.
Any mappings which exist when the memory object is deleted
become undefined. Accessing such memory may cause unpre-
dictable effects in your process.
IMHO, ANY program bug should not adversly affect another program.Good one. >
How do you suppose we should prevent the following buggy code from
adversely affecting other programs:void foo( void ) {
pid_t pid;
kill( pid, SIGTERM );
}–
Wojtek Lerch QNX Software Systems Ltd.
–
Wojtek Lerch QNX Software Systems Ltd.