[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[off-topic] setrlimit()/C++ new() seg fault



Hi,

I've been experimenting with limiting the amount of memory available to
a process by setting its data segment resource limit from within the
process by using setrlimit().  I've been testing if this technique
would work by attempting to allocate more memory on the heap than the
limit set in setrlimit() call.  Unfortunately, I get a seg fault in the
standard C++ library (gcc 2.95.2 on a "potato" box).

I'm not very familiar with the behavior of setrlimit() so please let me
know if I'm doing something silly.

Here is the test program:

// -----------------------------------------------------
#include <sys/time.h>
#include <sys/resource.h>
#include <unistd.h>
#include <cstdio>
#include <cerrno>

#include <new>

#include <iostream>

int
main (int, char *[])
{
  struct rlimit r;

  r.rlim_cur = 1000;
  r.rlim_max = 10000;

  if (::setrlimit (RLIMIT_DATA, &r) != 0)
    ::perror ("setrlimit");

  int *b = 0;

  try
    {
      b = new int[500000000L];
  
      delete [] b;
    }
  catch (std::bad_alloc)
    {
      std::cout << "caught bad_alloc exception" << endl;

      return 0;  // Success
    }

  std::cerr << "Allocated more than what should be available." << endl;

  return 1;  // Failure
}
// -----------------------------------------------------

Here is back trace from the core dump:

#0  0x4003e7f1 in exception::what () from /usr/lib/libstdc++-libc6.1-2.so.3
#1  0x4003e937 in exception::what () from /usr/lib/libstdc++-libc6.1-2.so.3
#2  0x4003e9b5 in exception::what () from /usr/lib/libstdc++-libc6.1-2.so.3
#3  0x4003f14c in __frame_state_for () from /usr/lib/libstdc++-libc6.1-2.so.3
#4  0x4003da98 in __throw () from /usr/lib/libstdc++-libc6.1-2.so.3
#5  0x4003f4fd in __builtin_new () from /usr/lib/libstdc++-libc6.1-2.so.3
#6  0x4003f66f in __builtin_vec_new () from /usr/lib/libstdc++-libc6.1-2.so.3
#7  0x80489af in main ()
#8  0x400937a2 in __libc_start_main () from /lib/libc.so.6

Any ideas?

Thanks in advance for any suggestions.
-Ossama
-- 
Ossama Othman <othman@cs.wustl.edu>
Center for Distributed Object Computing, Washington University, St. Louis
58 60 1A E8 7A 66 F4 44  74 9F 3C D4 EF BF 35 88  1024/8A04D15D 1998/08/26


Reply to: