"No space left on device" error using SystemV shared memory
ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
"No space left on device" error using SystemV shared memory
Hi everyone,
I am using SystemV shared memory and semaphores to let some processes exchange information.
I've used shmget function to create a shared memory area, shmat to attach it to each process, then shmdt and shmctl to detach and deallocate the memory I've used; as for semaphores, I've used semget and semctl.
The problem is, after I've launched the program 8-9 times apparently without problems, when I try to execute the program semget returns an error: no space left on device. What leaves me astonished is the fact that I've actually detached AND released all of the memory I've used, by calling shmdt in each process and shmctl in main process, and by using semctl only in main process.
Does anyone have any idea ???
I'm getting pretty messed up with that program, so please help me!!
The problem you describe is not with shared memory, because you say the error occurs with semget(), which is concerned with semaphores, not shared memory. You probably have a semaphore leak.
In your description, you say that you delete all the shared memory, but do you delete all semaphores that you use?
That would be something to double-check.
Also, to help you figure this out, do this at the command line:
Code:
ipcs -a
man ipcs
Hope this helps.
Last edited by wjevans_7d1@yahoo.co; 07-07-2007 at 11:38 AM.
Hi wjevans!
First of all thank you for answering my post, I really appreciated your help!
I run my program a few times, then checked the ipc status with ipcs (that's REALLY useful ).
The output shows that each semaphore I've used in my program still exists!! Not only, I've also discovered that even shared memory areas aren't deallocated when the program is terminated: they're still in the list provided by ipcs, with 0 processes attached to them.
Basically, detachment is successful, but shared memory isn't really deallocated. Any idea?
This is how I call shmget, shmat, shmctl (to deallocate when detachment is done) and shmdt:
Since ipcs reports no precess is attached to shared segments, I suppose there's some kind of problem with shmctl...
As for semaphores, there's no need to attach/deattach, so I just call a
coord_mutex = semget (IPC_PRIVATE, 1, IPC_CREAT | S_IRUSR | S_IWUSR );
when program begins, then call
semctl (coord_mutex, 1, IPC_RMID, arg);
before the last process of the program exits.
I've done what you suggested, and solved the problems with shared memory segments: the semctl was to be called BEFORE any detachment...
Unfortunately, the problem with semaphores remains: I've tried running a program like the one you've posted, and everything is ok. ipcs shows the semaphore is allocated, then deallocated when the process is terminated.
I thought the reason why semaphores were not deallocated was the fact that I did not use the flag SEM_UNDO when doing a wait or a signal: I thought there could be a process waiting on a waiting queue of that semaphore which blocked the deallocation, but then when I tried using SEM_UNDO nothing changed.
I really haven't got the faintes idea of what is wrong with my program...
I hesitate to suggest this, partly because I know you've already thought of it and are already working on it, but:
If all else fails, have you thought of taking a destroyable copy of your program and ripping out chunks of it one at a time, testing it each time, as it becomes more and more like your (well-behaved) semaphore test program, until it works, and then focusing on what you ripped out that fixed the problem?
A lot of work, but sometimes that's the only thing that will work.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.