ctor_copy_dtor test allocates ridiculous amounts of memory

[Zack Weinberg]

I have a computer with 256Mb of real RAM, and ctor_copy_dtor.cc blows
past that and chews up most of 1G of swap.

This trace is with draconian resource limits applied:

$ strace ./ctor_copy_dtor.st-exe 
execve("./ctor_copy_dtor.st-exe", ["./ctor_copy_dtor.st-exe"], 
	[/* 33 vars */]) = 0
fcntl(0, F_GETFD)                       = 0
fcntl(1, F_GETFD)                       = 0
fcntl(2, F_GETFD)                       = 0
personality(PER_LINUX)                  = 0
geteuid()                               = 1000
getuid()                                = 1000
getegid()                               = 1000
getgid()                                = 1000
getpid()                                = 21550
brk(0)                                  = 0x8083e20
brk(0x8083e58)                          = 0x8083e58
brk(0x8084000)                          = 0x8084000
brk(0x8085000)                          = 0x8085000
old_mmap(NULL, 1073745920, PROT_READ|PROT_WRITE, 
	 MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
brk(0x48086000)                         = 0x8085000
old_mmap(NULL, 1073745920, PROT_READ|PROT_WRITE, 
	 MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
brk(0x48086000)                         = 0x8085000
old_mmap(NULL, 1073745920, PROT_READ|PROT_WRITE, 
	 MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
brk(0x48086000)                         = 0x8085000
old_mmap(NULL, 1073745920, PROT_READ|PROT_WRITE, 
	 MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
brk(0x48086000)                         = 0x8085000
_exit(0)                                = ?

Here's a gdb backtrace from that first mmap call.

#0  0x8054920 in mmap ()
#1  0x805112b in chunk_alloc ()
#2  0x8050c5c in malloc ()
#3  0x8074631 in std::__malloc_alloc_template<0>::allocate (__n=1073741832)
    at stl_alloc.h:124
#4  0x80742f7 in std::allocator<char>::allocate (this=0xbffffa94, 
    __n=1073741832) at stl_alloc.h:616
#5  0x8073e7e in std::basic_string<char, std::char_traits<char>,
				   std::allocator<char> >
		    ::_Rep::_S_create (__capacity=1073741819,
				       __alloc=@0xbffffa94)
    at string.tcc:369
#6  0x80739ce in std::basic_string<char, std::char_traits<char>, 
				   std::allocator<char> >
		    ::_S_construct (__n=1073741819, __c=65 'A',
				    __a=@0xbffffa94)
    at string.tcc:165
#7  0x8073589 in std::basic_string<char, std::char_traits<char>,
				   std::allocator<char> >
		    ::basic_string (this=0xbffffab4, __n=1073741819,
				    __c=65 'A', __a=@0xbffffa94)
    at string.tcc:222
#8  0x8072462 in test01 ()
    at 21-strings/ctor_copy_dtor.cc:94
#9  0x8072e1b in main ()
    at 21_strings/ctor_copy_dtor.cc:179

Listing in frame 8:

92        // Build a maxsize-1 lengthed string consisting of all A's
93        try {
94          std::string str03(csz01 - 1, 'A');
95          VERIFY( str03.size() == csz01 - 1 );
96          VERIFY( str03.size() <= str03.capacity() );
97        }              

where csz01 has been initialized to str01.max_size().  Flipping
through basic_string.h, it looks like that's a constant equal to
one-quarter the max virtual address space - 1GB in this case.

My question to you, then, is - is that a sensible upper limit?  And is
it sensible to actually create a string of that size during testing?

zw