Possible GCC bug ? (stack mem leak)

[Jean-François GOBBERS <jfgobbers@xxxxxxxxx>]

Hi,

I hope the following is no known matter! I checked the various GCC 
lists, but didn't find anything similar.

Compiling and executing the code below shows that the first loop (in 
doLoop1) produces a slow memory leak on the stack, while the second one 
(in doLoop2) behaves correctly!

Should this be related to a GCC bug (wrong code) or rather to some 
personal misinterpretation of the ISO C++ standard ?

Tested on Slackware 10.1, using:
- GCC 3.3.4
- GCC 3.3.6
- GCC 3.4.4
All GCC were compiled this way (`gcc -v`):
Configured with: ../gcc-3.X.X/configure --prefix=/usr --enable-shared 
--enable-threads=posix --enable-__cxa_atexit --disable-checking 
--with-gnu-ld --verbose --target=i486-slackware-linux 
--host=i486-slackware-linux
Thread model: posix

----------------------------------------------------------

#include <exception>
#include <iostream>

using namespace std;

struct MyObject {
	// Note: no leak if this operator is NOT defined
	MyObject& operator = ( const MyObject& ) { return *this; }
};

static MyObject getObject() {
	throw exception();
}

static void showApproxStackAddr() {
	int i;
	cerr << hex << (unsigned int)&i << dec << endl;
}

static void doLoop1() { // LEAKING!
	for ( int i = 0 ; i < 4 ; i++ ) {
		showApproxStackAddr();
		try {
			MyObject obj;
			obj = getObject();
		}
		catch ( exception& ) {
		}
	}
}

static void doLoop2() { // NOT LEAKING!
	for ( int i = 0 ; i < 4 ; i++ ) {
		showApproxStackAddr();
		try {
			MyObject obj = getObject();
		}
		catch ( exception& ) {
		}
	}
}

int main() {
	cerr << "--------" << endl; doLoop1(); // LEAK
	cerr << "--------" << endl; doLoop2(); // NO LEAK!!!
	return 0;
}

----------------------------------------------------------

Notes:
- the leak is always 8 bytes per loop, and doesn't seem to be related to 
the size of the exception being throw, or to the size of the object 
being initialized (of type MyObject).
- suppressing the copy operator of the MyObject struct, also suppresses 
the leak!
- changing the compile flags doesn't change anything. No optimizer 
problem here!
- when increasing the number of loops to > 2^20, the process finally 
gets a segfault, as the stack size is limited here to 8MB, which is a 
normal behaviour in case of a memory leak on the stack.


Thanks for your comments on this!

JF


--
Jean-Francois GOBBERS
e-Mail: jfgobbers@xxxxxxxxx