Conference turris::decladebug

932.0. "Memory leak with multiple runs" by BHAJEE::KONRAD (pour des nouvelles aventures) Tue Apr 22 1997 11:39

Apparently ladebug has a memory leak, which can be demonstrated
as follows:

Machine:
OSF1 majestix.rto.dec.com V4.0 464 alpha, 128 MB RAM, 1 CPU

Compiler:
cxx  (cxx)
DEC C++ V5.5-003 on Digital UNIX (Alpha)

Program:
#include "stdio.h"

main (int argc, char *argv[])
{
    printf ("hello, world\n");
}

Compiler call:
cxx -g2 hello.cxx -o hello

Ladebug call:
ladebug hello

Then iterate:
- compile
- ladebug: run

Ladebug memory usage (each line one iteration,
output of :ps -o "rssize,pmem,vsize,majflt,minflt,pid,ppid,ucomm"):
 RSS %MEM   VSZ MAJFLT MINFLT   PID  PPID COMMAND
5.0M  4.0 12.5M      0    953 31521 29956 ladebug
5.8M  4.6 13.3M      0   1359 31521 29956 ladebug
6.4M  5.1 14.0M      0   1826 31521 29956 ladebug
7.1M  5.6 14.7M      0   2341 31521 29956 ladebug
...

As can be seen, each loading of "hello world" eats about
0.7-0.8 MB virtual memory.

The result of this behaviour with bigger programs are very
long loading times and finally heap space exhaustion.

Attached you will find to dumps produced by ladebug after
memory exhaustion.

Greetings

WR



Subject: 
   Date: 
       Thu, 10 Apr 1997 17:25:49 GMT


(ladebug) load aif_test
Reading symbolic information ...Internal Error: out of memory
Heap exhausted with 131727360 bytes.

Ladebug Debugger Version 4.0-23 caught signal "Segmentation fault" (11).
This is an unexpected condition and may indicate the presence of a defect.
If you wish to report this, please include the stack trace that follows.
Diagnostic stack trace ...
0x12387b7c
0x1220e07c
0x242bb548
0x242bb73c
0x12210e00
0x125adcfc
0x125ab37c
0x125adb7c
0x242bb714
0x12210f34
0x125adcfc
0x125ab37c
0x125adb7c
0x24330e48
0x123af3f0
0x1242489c
0x124f5fd0
0x1243d094
0x1244babc
0x1244ac04
0x1244cff8
0x12449934
0x1243cce4
0x1244b8cc
0x1244ac04
0x1244cff8
0x12449934
0x1243a5c8
0x1244bb0c
0x1244ac04
0x1244cff8
0x12449934
0x1243a5c8
0x1244bb0c
0x1244ac04
0x1244cff8
0x12449934
0x124423ac
0x1243ca2c
0x12439f38
0x12439984
0x1243915c
0x12437fa0
0x1254dfe4
0x124dbae0
0x123a7d58
0x123a7f9c
0x12382cfc
0x12225018
0x1222896c
0x12384420
0x12212c88
0x1223cb88
0x1220e35c
0x122138d0
0x1220238c
0x121fee1c
end of diagnostic stack trace.

Thanks for reporting the problem.

I noticed that you are using ladebug 4.0-23 which is quite old - the current
released version in 4.0-35. We have made quiet a few improvements since 4.0-23.
Would you please that debugger a try and let us know what happens.

Also, realize that when you do multiple loads in to the same debugger session,
you are basically loading the same program multiple times - ie., the symbol
table information is loaded multiple times. (It is on our list to optimize
this and only load the redundant symbol tables once, but is not there today).

If your program is large, reading the symbol table can use lot of memory
and hence running out of memory error.

From .0, you mention that you want to do:

>> Then iterate:
>> - compile
>> - ladebug: run

For this you don't really need to use the 'load' command. Issuing the 'run'
command will pick up the new changed binary and in that case replace the 
symbol table information instead of adding to existing one.

If you really have to do multiple 'load', then perhaps you could increase
the data size using ulimit commands.

Hope this helps.
shamim

Thank you for the quick response. I'll upgrade to the new version and inform you
about the results

-conny