PR# 5315 Estudio memory leaks revealed by Solaris Modular Debugger

Problem Report Summary
Submitter: prestoat2000
Category: EiffelStudio
Priority: Medium
Date: 2005/07/26
Class: Bug
Severity: Serious
Number: 5315
Release: 5.6.1122
Confidential: No
Status: Analyzed
Environment: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030625 SunOS 5.9 Generic_118558-10 sun4u sparc SUNW,Sun-Blade-1000
Synopsis: 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 for more details.

        % setenv UMEM_DEBUG default
        % setenv UMEM_LOGGING transaction
        % setenv LD_PRELOAD
        % which estudio
        % mdb /home/eiffel/Eiffel5.6.1122/studio/spec/solaris-sparc/bin/estudio
        Loading modules: [ ]
        > ::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:`exit+0x34:    ta        8
        mdb: You've got symbols!
        Loading modules: [ ]
        > ::findleaks
        0201a548       2 03dfb7e8`g_malloc0+0x2c
        02015a48       1 02bb6f78`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)
To Reproduce
See above.
Problem Report Interactions
From:prestoat2000    Date:2009/08/31    Download   
To increase the limit to 30, use

   setenv UMEM_DEBUG "audit=30,contents,guards"

For more details:

   man umem_debug

From:manus_eiffel    Date:2009/08/31    Status: Analyzed    Download   
I've redone the test with 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?

From:manus_eiffel    Date:2006/09/01    Download   
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.

From:prestoat2000    Date:2006/08/31    Download   
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.

From:prestoat2000    Date:2005/11/11    Download