why different signals send to programs that exceeded memory limit set by setrlimit()?
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.
why different signals send to programs that exceeded memory limit set by setrlimit()?
hi all!
i'm having a problem with setrlimit() under linux.
if i used setrlimit(RLIMIT_AS) to set a hard ceiling of virtual memory usage first, then request memory more than that, shouldn't i receive a signal like SIGSEGV?
first i tried the command ulimit in bash, which acted as if i called setrlimit(). i tried 3 programs that overflowed the memory limit i set. i though all the programs would be terminated by a SIGSEGV. but the pascal program received SIGKILL; the C++ program got SIGABRT; the C program, SIGSEGV.
i though there maybe something different between setrlimit() and ulimit, so i wrote a program in C++, fork() first, setrlimit() then execv() in the child, and wait(&status) in the parent. but i got the same result.
i was wondering why these could happen, and could anyone tell me how could i deal with them? i mean, how can i judge that the program exited abnormally because it exceed memory limit?
thx in advance.
Last edited by lonelycorn; 09-03-2010 at 06:16 AM.
well to be honest , i've not experimented with what you're doing so far , however from what i assuming you're doing
your only hope is to write a wrapper class that encapsulates the signal receiving operation
btw your example is kinda vague you need to provide lots more of info regarding your actual goal that you're trying to accomplish , sometimes things can be solved using much easier techniques ...
sorry i didn't make it clear. my words may be somewhat ambiguous. but thx for your reply.
let me make it clear.
my program was trying to inspect the memory usage of other programs. i mean, execute a program and collect info about its memory usage. of course there is a limit on memory, just in case.
my program would give a summary of memory usage if the program executed successfully within the limit i set, or give a warning like "memory limit exceeded" if not.
first i used fork() to create a child process.
in the child process i used setrlimit(RLIMIT_AS) to set the soft and hard ceiling, then execv() the external program;
the parent process would check the child's memory usage via /proc/<pid>/statm every 10ms. if the child had exited (either normally or abnormally), the parent would use waitpid() to get the status of the child process. then use WEXITSTATUS() and WTERMSIG() to get the exit status and the signal that terminated the child.
i thought the signal would be SIGSEGV if the program overflowed the memory limit, but in fact, SIGKILL for pascal programs, SIGABRT for c++ programs, SIGSEGV for c programs.
how could this happen?
Last edited by lonelycorn; 09-03-2010 at 06:17 AM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.