You can't mix ftruncate() and shm_ctl():
- ftruncate() is used to set the size of "ordinary" shared memory objects
- shm_ctl() is used to set the size of "special" shared memory objects

shm_ctl() is a one-time operation to set up a special shared memory object:
- if its size has already been set by ftruncate(), shm_ctl() will fail
- if it has already been initialised by a previous shm_ctl() call, a 2nd
   shm_ctl() will fail

Your code should work if you remove the ftruncate() call.

Also, be aware that by default these global mappings are protected so that
only those processes that mmap() the object can access the global mapping.
This requires updating L1 page table entries on context switches to change
the access protections. You can avoid this cost by using one of these flags
along with the SHMCTL_GLOBAL:
- SHMCTL_PRIV: mapping is visible to all processes, but only processes with
   I/O privilege (ie. used ThreadCtl) can access it; other processes will
   get a sigsegv on an attempted access
- SHMCTL_LOWERPROT: mapping is visible and accessible to all processes.

If you don't use either of these flags, ou may need to create and mmap() the
global object _before_ you call ThreadCtl() to work around a problem where
the memmgr doesn't record the protection status for the mmap() because the
ThreadCtl() causes all mappings to be locked - this invokes a slightly
different code path which is missing the code to indicate that the global
mapping needs to be manipulated on context switches...

Comments on your observations are below:

Andrew Golovnia wrote:
> Hi!
> 
> I do some experiments with organization of shmem in ARM (xScale pxa255) 
> in QNX 6.3.2.
> 
> My current task is to allocate in process as much memory as it's possible.
> As soon as application address space in ARM limited by 32M and maximal 
> malloc()able block is about 15Mb, I'm trying my best with shared memory.
> 
> So reading 
> http://www.qnx.com/developers/docs/6.3.2/neutrino/prog/arm_memory.html
> I found that my problem can be solved by using global shmem. :-)
> 
> So, I wrote an small test application (see attach).
> I have problem with understanding the behavior of QNX under my tests...
> 
> My system says:
> # pidin info
> CPU:ARM Release:6.3.0  FreeMem:46Mb/64Mb BootTime:Jan 01 00:00:00 UTC 1970
> Processor1: 1761946886 pxa250 399MHz
> 
> 1. Lats say I want to allocate 33 Mb of shmem...
> 
> When I set SHMEM_SIZE = (33 * 1024 * 1024) my program prints following:
> SHMEM allocation test.
> shm_open() -> fd = 3 OK
> ftruncate() -> r = 0 OK
> shm_ctl() -> r = -1 Function not implemented

Your ftruncate() created an ordinary 33MB object so the shm_ctl() fails.

> mmap() -> shmem = 0xFFFFFFFF Not enough memory

The mmap() fails because an ordinary shared memory object is mapped into
the process address space, but it cannot fit.

> Code address:  &main() = 0x00100940
> Data address:  &fd     = 0x00101DC4
> Stack address: &shmem  = 0x000FFCE0
> Shmem address: shmem   = 0xFFFFFFFF
> Memsetting... <SIGSEGV>
> 
> Shmem block is created but not mapped in address space!
> # ls -l /dev/shmem
> total 67584
> nrwxrwxrwx  3 root      0          34603008 Mar 18 15:53 big_memory_block
> 
> Why if it's possible to map (according to docs) more than 32 Mb of 
> physical RAM, it's impossible to map such amount of shared RAM?

You can only map more than 32MB into the "global address space".
Your ftruncate() call created an ordinary shared memory object that will
be mapped into the process address space, NOT the global address space.

> 2. When I set SHMEM_SIZE to 18 or 16 Mb system can't map it globally too!
> 
> 3. When I set SHMEM_SIZE in 5 Mb memory is mapped successfully, but I 
> see different behavior of C library when I change an...