Caution notice on shmem in QNX425toQNX425E doc

Hi,

I am a little confused about the following notice in this doc:

CAUTION: The QNX 4 kernel does NOT maintain reference counts on shared-memory fds. If you mmap a pointer to your application, don't close the fd and then shmem_unlink the memory object and continue to reference that memory object through the pointer.

For example, here are the incorrect and correct forms:

Incorrect form:

fd = shmem_open(“memory”…);
ptr = mmap(…);

shmem_unlink(“memory”);
close(fd);
modify data at ptr

Correct form:

fd = shmem_open(“memory”…);
ptr = mmap(…);

shmem_unlink(“memory”);
modify data at ptr

If you don’t use the correct form, the memory that your ptr refers to
could be given back to the OS for other allocation. As a result, you
could end up writing into memory regions owned by another process, thus
causing that other process to fail.

What if I close(fd) and do NOT shm_unlink(). Is ptr valid then? i.e. is
the following correct:

fd = shmem_open(“memory”…);
ptr = mmap(…);

close(fd);
modify data at ptr



regards

chris

Previously, chris wrote in qdn.public.qnx4:

Hi,
[…]

What if I close(fd) and do NOT shm_unlink(). Is ptr valid then? i.e. is
the following correct:

fd = shmem_open(“memory”…);
ptr = mmap(…);

close(fd);
modify data at ptr

Yes, that will work.

Let me try to clarify this a little.

With QNX 4 you can 1. create a file, and 2. immediately unlink that file.
You would still have an open file descriptor to a valid disk file. There is
just no directory entry that pointed to that file. Compilers and other
programs that want to create temporary files do this. If the program
terminates, gracefully or otherwise, the disk space is freed up and given
back to the file system.

All of this is a cute little trick that some developers have used.

The WARNING that you saw is simply saying that if you thought you could use
the same trick on a shared memory block, it won’t work. The memory won’t be
returned to the system unless/untill it is specifically unlink()ed. So, if
you tried to use the same trick as with disk files, you would have a memory
leak.


Bill Caroselli - Sattel Global Networks
1-818-709-6201 ext 122



“Ken Schumm” <kwschumm@qsolv.com> wrote in message
news:Voyager.010530081623.257B@dilbert…

Previously, chris wrote in qdn.public.qnx4:
Hi,
[…]

What if I close(fd) and do NOT shm_unlink(). Is ptr valid then? i.e. is
the following correct:

fd = shmem_open(“memory”…);
ptr = mmap(…);

close(fd);
modify data at ptr


Yes, that will work.

chris <sscanf@usa.net> wrote:

Hi,

Proper behaviour (QNX 6 does this): a memory area is only freed when:
– it has been unlinked
AND
– all references to it have been closed, including:
a) all open fds have been closed
b) all mmaps have been munmapped

Under QNX4 it only maintains reference counts for open fds, NOT for
mmaps. So, the memory area will be marked as free (and available for
use by another process) when:
– it has been unlinked
AND
– all open fds to it have been closed
EVEN IF
there are still some mmap() references to it that haven’t been unmapped.


If you don’t use the correct form, the memory that your ptr refers to
could be given back to the OS for other allocation. As a result, you
could end up writing into memory regions owned by another process, thus
causing that other process to fail.
snip off

What if I close(fd) and do NOT shm_unlink(). Is ptr valid then? i.e. is
the following correct:

fd = shmem_open(“memory”…);
ptr = mmap(…);

close(fd);
modify data at ptr

Yes, what you are doing above is valid. The memory is not freed by
the first clause of the rules I gave.

-David

QNX Training Services
dagibbs@qnx.com

Bill Caroselli <Bill@sattel.com> wrote:

The WARNING that you saw is simply saying that if you thought you could use
the same trick on a shared memory block, it won’t work. The memory won’t be
returned to the system unless/untill it is specifically unlink()ed. So, if
you tried to use the same trick as with disk files, you would have a memory
leak.

No, that isn’t what the warning is saying. It is saying that if you
open() the memory, mmap() the memory, shm_unlink() the memory and
close() the fd – but don’t munmap() the memory, you will have a pointer
that you can still use – BUT from Proc’s point of view, the memory
WILL have been marked as free, and WILL be available for reuse. In
other words, it could be allocated to the next process run, add back
to your heap next time your process grows its heap, allocated to some
other process, etc.

-David

QNX Training Services
dagibbs@qnx.com

Ouch! That’s very different. And a lot worse than a memory leak!

I have done a lot with shared memory blocks, fork()ing processes and QNX4 to
get around not having real multi-threadedness. I guess that I’ve just
always done it right and never noticed THIS little buglet.

Thank for clearing that up.


Bill Caroselli - Sattel Global Networks
1-818-709-6201 ext 122



“David Gibbs” <dagibbs@qnx.com> wrote in message
news:9f35c6$dgv$4@nntp.qnx.com

Bill Caroselli <> Bill@sattel.com> > wrote:

The WARNING that you saw is simply saying that if you thought you could
use
the same trick on a shared memory block, it won’t work. The memory
won’t be
returned to the system unless/untill it is specifically unlink()ed. So,
if
you tried to use the same trick as with disk files, you would have a
memory
leak.

No, that isn’t what the warning is saying. It is saying that if you
open() the memory, mmap() the memory, shm_unlink() the memory and
close() the fd – but don’t munmap() the memory, you will have a pointer
that you can still use – BUT from Proc’s point of view, the memory
WILL have been marked as free, and WILL be available for reuse. In
other words, it could be allocated to the next process run, add back
to your heap next time your process grows its heap, allocated to some
other process, etc.

Bill Caroselli <Bill@sattel.com> wrote:

Ouch! That’s very different. And a lot worse than a memory leak!

I have done a lot with shared memory blocks, fork()ing processes and QNX4 to
get around not having real multi-threadedness. I guess that I’ve just
always done it right and never noticed THIS little buglet.

Thank for clearing that up.

No problem. Most of the time, when doing shared memory you just leave
the name around, and that prevents the problem from happening at all.

And, if you don’t leave the name around, you often just keep the fd
around, and you’re still ok.

-David

QNX Training Services
dagibbs@qnx.com