Discussion:
Shared Memory Problem - no space at /dev/shm causes SIGBUS
(too old to reply)
z***@gmail.com
2005-12-16 22:47:47 UTC
Permalink
I know this sounds like an old-familiar problem , but after reading the
documentation and posts - i still can't get it right...

i'm creating a shared-memory using the shm_open+ftruncate+mmap .

When i have enought available space on my /dev/shm , everything worx
fine . but , when i don't have enought space - all the functions
returns a valid values , but when i tried to access the memory - i got
SIGBUS (Bus Error) .

I can even see the file , using "ls" , and i can access the file
properties with "fstat" (with it's correct size) , but when i try to
"cat" it's contents , i get "No space left on device".

In my production-app , i can check the disk-size before creating the
memory, but i would expect that the ftruncate or the shm_open to fail ,
am i wrong ?

thnx,
zvika
Roger Leigh
2005-12-17 12:27:55 UTC
Permalink
Post by z***@gmail.com
I know this sounds like an old-familiar problem , but after reading the
documentation and posts - i still can't get it right...
i'm creating a shared-memory using the shm_open+ftruncate+mmap .
When i have enought available space on my /dev/shm , everything worx
fine . but , when i don't have enought space - all the functions
returns a valid values , but when i tried to access the memory - i got
SIGBUS (Bus Error) .
In my production-app , i can check the disk-size before creating the
memory, but i would expect that the ftruncate or the shm_open to fail ,
am i wrong ?
When you open the file and call ftruncate, you have created a file
with a "hole" in it (see also lseek(2)). That is, your file does not
have any disk blocks on disk allocated to it, even though you set the
file length to a defined size. This means that if you mmap(2) the
file, any subsequent read or write to this memory will cause a SIGBUS,
due to there being no backing store.

I think (but may be wrong) that the best way to make this work is to
write(2) zeros to the file to ensure that every page is allocated.
You'll notice that write(2), unlike ftruncate(2), can return ENOSPC as
an error code.

There may be a more efficient way to accomplish this, in which case I
would also be keen to know it.


Regards,
Roger

- --
Roger Leigh
Printing on GNU/Linux? http://gimp-print.sourceforge.net/
Debian GNU/Linux http://www.debian.org/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
Nix
2005-12-17 22:27:34 UTC
Permalink
Post by Roger Leigh
There may be a more efficient way to accomplish this, in which case I
would also be keen to know it.
Catch the SIGBUS :)
--
`I must caution that dipping fingers into molten lead
presents several serious dangers.' --- Jearl Walker
Roger Leigh
2005-12-17 23:53:38 UTC
Permalink
Post by Nix
Post by Roger Leigh
There may be a more efficient way to accomplish this, in which case I
would also be keen to know it.
Catch the SIGBUS :)
If I was to lseek() and write() a page in the sigbus handler, would the
offending instruction be retried correctly after the handler returned?

I guess the other issue with this approach is you also need a
semaphore to prevent the cooperating processes from zeroing a page as
the other tries to use it. You also need to be prepared to run out of
disk space at any moment.


Regards,
Roger

- --
Roger Leigh
Printing on GNU/Linux? http://gimp-print.sourceforge.net/
Debian GNU/Linux http://www.debian.org/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
z***@gmail.com
2005-12-18 09:54:25 UTC
Permalink
Hi Everyone,
Thanks for great replies !!

First - I know i can catch the SIGBUS , but i was looking for elegant
solution .

Now, the write() before mmap works great !!!! , if there's not enough
space available space , the first write() returns error .

THANKS !!!

by the way :
1. i thought that my "memset(ptr,0,size)" is just like the write ...
isn't it ?
2. just to be sure - it is still use MEMORY , right ? no disk operation
will be taken, right ?
3. is the shared-memory always goes to /dev/shm ? (maybe i can test
the available space ...)

thnx again,
zvika
Darren Salt
2005-12-18 22:23:49 UTC
Permalink
I demand that ***@gmail.com may or may not have written...

[snip; /dev/shm]
Post by z***@gmail.com
2. just to be sure - it is still use MEMORY , right ? no disk operation
will be taken, right ?
Not necessarily. If it's a tmpfs mount (which is likely), it can use swap
space.
--
| Darren Salt | nr. Ashington, | d youmustbejoking,demon,co,uk
| Debian, | Northumberland | s zap,tartarus,org
| RISC OS | Toon Army | @
| Kill all extremists!

Eagles soar, but weasels aren't sucked into jets.
Nix
2005-12-19 07:09:04 UTC
Permalink
Post by Darren Salt
[snip; /dev/shm]
Post by z***@gmail.com
2. just to be sure - it is still use MEMORY , right ? no disk operation
will be taken, right ?
Not necessarily. If it's a tmpfs mount (which is likely), it can use swap
space.
i.e., it's just like any other memory operation. :)
--
`I must caution that dipping fingers into molten lead
presents several serious dangers.' --- Jearl Walker
Loading...