tests/Polyhedron/memory1 not workin on Mac OS X
Dear Dominique and Jack,
can you please try the following on your machines? My guess is that you will not see the "bad_alloc caught" output from a.out, in which case the question becomes:
Why isn't setrlimit working on Mac OS X?
All the best,
Roberto
$ cat bug.cc #include <new> #include <cstring> #include <cerrno> #include <sys/types.h> #include <sys/time.h> #include <sys/resource.h> #include <unistd.h> #include <iostream> #include <cstdlib>
#define LIMIT(WHAT) \ do { \ if (getrlimit(WHAT, &t) != 0) { \ std::cerr << "getrlimit failed: " << strerror(errno) << std::endl; \ exit(1); \ } \ t.rlim_cur = bytes; \ if (setrlimit(WHAT, &t) != 0) { \ std::cerr << "setrlimit failed: " << strerror(errno) << std::endl; \ exit(1); \ } \ } while (0)
void limit_memory(unsigned long bytes) { struct rlimit t; // Limit heap size. LIMIT(RLIMIT_DATA); // Limit resident set size. LIMIT(RLIMIT_RSS); // Limit mapped memory (brk + mmap). //LIMIT(RLIMIT_VMEM); // Limit virtual memory. LIMIT(RLIMIT_AS); }
int main() try { limit_memory(10000); (void) new char[20000]; std::cout << "no exception thrown" << std::endl; } catch (std::bad_alloc) { std::cout << "bad_alloc caught" << std::endl; } catch (...) { std::cout << "unknown exception thrown" << std::endl; } $ g++ -W -Wall bug.cc $ a.out bad_alloc caught $
Dear Roberto,
can you please try the following on your machines?
The result is:
[ibook-dhum] f90/bug% a.out no exception thrown
Now looking at the man page for setrlimit, I see:
... RLIMIT_CORE The largest size (in bytes) core file that may be created.
RLIMIT_CPU The maximum amount of cpu time (in seconds) to be used by each process.
RLIMIT_DATA The maximum size (in bytes) of the data segment for a process; this defines how far a program may extend its break with the sbrk(2) system call.
RLIMIT_FSIZE The largest size (in bytes) file that may be created.
RLIMIT_MEMLOCK The maximum size (in bytes) which a process may lock into memory using the mlock(2) function.
RLIMIT_NOFILE The maximum number of open files for this process.
RLIMIT_NPROC The maximum number of simultaneous processes for this user id.
RLIMIT_RSS The maximum size (in bytes) to which a process's resident set size may grow. This imposes a limit on the amount of physical memory to be given to a process; if memory is tight, the system will prefer to take memory from pro- cesses that are exceeding their declared resident set size.
RLIMIT_STACK The maximum size (in bytes) of the stack segment for a process; this defines how far a program's stack segment may be extended. Stack extension is performed automatically by the system. ... 4th Berkeley Distribution June 4, 1993 4th Berkeley Distribution
apparently no RLIMIT_VMEM nor RLIMIT_AS. Note that on one of our AMD Linux box I see:
... RLIMIT_AS The maximum size of the process's virtual memory (address space) in bytes. This limit affects calls to brk(2), mmap(2) and mremap(2), which fail with the error ENOMEM upon exceeding this limit. Also automatic stack expansion will fail (and generate a SIGSEGV that kills the process when no alternate stack has been made available). Since the value is a long, on machines with a 32-bit long either this limit is at most 2 GiB, or this resource is unlimited.
RLIMIT_CORE Maximum size of core file. When 0 no core dump files are created. When nonzero, larger dumps are truncated to this size.
RLIMIT_CPU CPU time limit in seconds. When the process reaches the soft limit, it is sent a SIGXCPU signal. The default action for this sigâ nal is to terminate the process. However, the signal can be caught, and the handler can return control to the main program. If the process continues to consume CPU time, it will be sent SIGXCPU once per second until the hard limit is reached, at which time it is sent SIGKILL. (This latter point describes Linux 2.2 and 2.4 behaviour. Implementations vary in how they treat processes which continue to consume CPU time after reaching the soft limit. Portable applications that need to catch this signal should perform an orderly termination upon first receipt of SIGXCPU.)
RLIMIT_DATA The maximum size of the process's data segment (initialized data, uninitialized data, and heap). This limit affects calls to brk() and sbrk(), which fail with the error ENOMEM upon encountering the soft limit of this resource.
RLIMIT_FSIZE The maximum size of files that the process may create. Attempts to extend a file beyond this limit result in delivery of a SIGXFSZ signal. By default, this signal terminates a process, but a process can catch this signal instead, in which case the relevant sysâ tem call (e.g., write(), truncate()) fails with the error EFBIG.
RLIMIT_LOCKS A limit on the combined number of flock() locks and fcntl() leases that this process may establish. (Early Linux 2.4 only.)
RLIMIT_MEMLOCK The maximum number of bytes of virtual memory that may be locked into RAM using mlock() and mlockall().
RLIMIT_NOFILE Specifies a value one greater than the maximum file descriptor number that can be opened by this process. Attempts (open(), pipe(), dup(), etc.) to exceed this limit yield the error EMFILE.
RLIMIT_NPROC The maximum number of processes that can be created for the real user ID of the calling process. Upon encountering this limit, fork() fails with the error EAGAIN.
RLIMIT_RSS Specifies the limit (in pages) of the process's resident set (the number of virtual pages resident in RAM). This limit only has effect in Linux 2.4 onwatrds, and there only affects calls to madvise() specifying MADVISE_WILLNEED.
RLIMIT_STACK The maximum size of the process stack, in bytes. Upon reaching this limit, a SIGSEGV signal is generated. To handle this signal, a process must employ an alternate signal stack (sigaltstack(2)).
RLIMIT_OFILE is the BSD name for RLIMIT_NOFILE. ... Linux 2003-11-28 GETRLIMIT(2)
i.e., no RLIMIT_VMEM either.
Thanks for the answers.
Dominique.
PS. I'll do the tests with different compilers during the week-end.
Dominique Dhumieres wrote:
can you please try the following on your machines?
The result is:
[ibook-dhum] f90/bug% a.out no exception thrown
So that is the problem. Do you know what may be an appropriate forum where to ask why this program does not work as expected on Mac OS X?
Now looking at the man page for setrlimit, I see:
... RLIMIT_CORE The largest size (in bytes) core file that may be created.
RLIMIT_CPU The maximum amount of cpu time (in seconds) to be used by each process. RLIMIT_DATA The maximum size (in bytes) of the data segment for a process; this defines how far a program may extend its break with the sbrk(2) system call. RLIMIT_FSIZE The largest size (in bytes) file that may be created. RLIMIT_MEMLOCK The maximum size (in bytes) which a process may lock into memory using the mlock(2) function. RLIMIT_NOFILE The maximum number of open files for this process. RLIMIT_NPROC The maximum number of simultaneous processes for this user id. RLIMIT_RSS The maximum size (in bytes) to which a process's resident set size may grow. This imposes a limit on the amount of physical memory to be given to a process; if memory is tight, the system will prefer to take memory from pro- cesses that are exceeding their declared resident set size. RLIMIT_STACK The maximum size (in bytes) of the stack segment for a process; this defines how far a program's stack segment may be extended. Stack extension is performed automatically by the system.... 4th Berkeley Distribution June 4, 1993 4th Berkeley Distribution
apparently no RLIMIT_VMEM nor RLIMIT_AS. Note that on one of our AMD Linux box I see:
OK, but:
- the line mentioning RLIMIT_VMEM is commented out in the program; - if the program compiles, it means that RLIMIT_AS is indeed defined; - RLIMIT_RSS and RLIMIT_DATA should do the trick, but they do not.
PS. I'll do the tests with different compilers during the week-end.
Great. All the best,
Roberto
participants (2)
-
dominiq＠lps.ens.fr -
Roberto Bagnara