PR# 5315 Estudio memory leaks revealed by Solaris Modular Debugger

There are still memory leaks in estudio (many may be in Vision2).  I would really like to see them all eliminated.  To reproduce using the Solaris Modular
Debugger (mdb), mimic the following session on Solaris
("%" is shell prompt and ">" is mdb prompt).
See http://access1.sun.com/techarticles/libumem.html for more details.

        % setenv UMEM_DEBUG default
        % setenv UMEM_LOGGING transaction
        % setenv LD_PRELOAD libumem.so.1
        % which estudio
        /home/eiffel/Eiffel5.6.1122/studio/spec/solaris-sparc/bin/estudio
        % mdb /home/eiffel/Eiffel5.6.1122/studio/spec/solaris-sparc/bin/estudio
        Loading modules: [ libc.so.1 ]
        > ::sysbp _exit
        > ::run
        mdb: fork detected: follow (p)arent or (c)hild? c   [follow child]
        mdb: target forked child process 21475 (debugger following child)
        mdb: execve detected: (f)ollow new program or (s)top? f  [follow]
        (At this point, estudio comes up.  Exercise everything:
        class and feature formats, debugger compiler, diagrams, etc.
        Then exit estudio).
        mdb: stop on entry to _exit
        mdb: target stopped at:
        libc.so.1`exit+0x34:    ta        8
        mdb: You've got symbols!
        Loading modules: [ ld.so.1 libumem.so.1 ]
        > ::findleaks
        CACHE     LEAKED   BUFCTL CALLER
        0201a548       2 03dfb7e8 libglib-2.0.so.0.600.5`g_malloc0+0x2c
        02015a48       1 02bb6f78 libglib-2.0.so.0.600.5`g_malloc0+0x2c
        ----------------------------------------------------------------------
        Total      15 buffers, 5472 bytes
        > 03dfb7e8::bufctl_audit        [Part before "::" is from BUFCTL column]
        (Shows stack trace where leaked memory was allocated)

See above.

To increase the limit to 30, use

   setenv UMEM_DEBUG "audit=30,contents,guards"

For more details:

   man umem_debug

I've redone the test with 6.5.8.524 and found more leaks but some are due to the fact that the GC does not always call `dispose' on all objects (e.g. objects still reachable from a once), and sometime it is related to the internationalization underlying C code we are using.

David, the callstack they provide is always limited to 15 entries. Do you know how to increase this?

You can download the PorterPackage from the same location where you downloaded EiffelStudio 5.7.63005. In the package you have the F_code and TRANSLAT file. So you could even recompile the compiler in debug mode.

Do you have the TRANSLAT file for 5.7.63005?  I would like to track
down the memory leaks reported by the Solaris modular debugger but
I can't get a useful stack trace without the TRANSLAT file.