PR6678?

[Stefan Olsson <stefan at noname4us dot com>]

Hi!

I guess that the issue that we currently are facing is related to the 
PR6678 (g++ 3.1 leaks memory when throwing exceptions).

Compling and running the example provided in the PR and adding a 
mtrace() call tells us that everything seems to be ok:
= Start
@ 
/usr/local/lib/libstdc++.so.4:(__cxa_allocate_exception+0x20)[0x40063c50] 
+ 0x804aec8 0x54
@ /usr/local/lib/libgcc_s.so.1:(__deregister_frame+0xaad)[0x400e98ad] + 
0x804af20 0x1c
@ /usr/local/lib/libgcc_s.so.1:(__deregister_frame+0xacb)[0x400e98cb] + 
0x804af40 0x1c
@ /usr/local/lib/libgcc_s.so.1:(__deregister_frame+0xd4f)[0x400e9b4f] - 
0x804af40
@ /usr/local/lib/libgcc_s.so.1:(__deregister_frame+0xaad)[0x400e98ad] + 
0x804af40 0x1690
@ /usr/local/lib/libgcc_s.so.1:(__deregister_frame+0xacb)[0x400e98cb] + 
0x804c5d8 0x1690
@ /usr/local/lib/libgcc_s.so.1:(__deregister_frame+0xd4f)[0x400e9b4f] - 
0x804c5d8
@ /usr/local/lib/libgcc_s.so.1:(__deregister_frame+0xaad)[0x400e98ad] + 
0x804c5d8 0xa4
@ /usr/local/lib/libgcc_s.so.1:(__deregister_frame+0xacb)[0x400e98cb] + 
0x804c680 0xa4
@ /usr/local/lib/libgcc_s.so.1:(__deregister_frame+0xd4f)[0x400e9b4f] - 
0x804c680
@ /usr/local/lib/libstdc++.so.4:(__cxa_free_exception+0x8c)[0x40063d8c] 
- 0x804aec8
@ 
/usr/local/lib/libstdc++.so.4:(__cxa_allocate_exception+0x20)[0x40063c50] 
+ 0x804aec8 0x54
@ /usr/local/lib/libstdc++.so.4:(__cxa_free_exception+0x8c)[0x40063d8c] 
- 0x804aec8
@ 
/usr/local/lib/libstdc++.so.4:(__cxa_allocate_exception+0x20)[0x40063c50] 
+ 0x804aec8 0x54
@ /usr/local/lib/libstdc++.so.4:(__cxa_free_exception+0x8c)[0x40063d8c] 
- 0x804aec8

and so on...

The calls above are the ones placed in libstdc++-v3/libsupc++/eh_alloc.cc.

Despite this, the reported memory usage increases steadily until one 
terminates the program or the machine runs out of memory.

Adding a getrusage() call within the for(;;) loop and inspecting the 
ru_minflt value informs us that we have a rather high (and steadily 
increasing) number of minor page faults - how ever I don't have enough 
knowledge to say if this is the reason or even related to the increase 
in application memory usage.

Any pointers on how to proceed?

Brgds

/Stefan

-- 
In any organization there will always be one person who knows what is going on.

This person must be fired.