[Bug general/3915] New: Memory leakage

[Bug general/3915] New: Memory leakage

[mcvet at redhat dot com]

Opening on a sizeable program with debuginfo and source, and then attempting to 
step and run through it steadily increases the memory footprint of FryskGui.

Starting at around 100M on x86_64 when the SourceWindow first opens, and 
increasing around .5M per step.

-- 
           Summary: Memory leakage
           Product: frysk
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: general
        AssignedTo: frysk-bugzilla at sourceware dot org
        ReportedBy: mcvet at redhat dot com
                CC: mcvet at redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=3915

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug general/3915] Memory leakage

[mcvet at redhat dot com]

------- Additional Comments From mcvet at redhat dot com  2007-01-24 15:53 -------
Created an attachment (id=1519)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=1519&action=view)
Screenshot of Gnome system monitor


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=3915

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug general/3915] Memory leakage

[rmoseley at redhat dot com]

------- Additional Comments From rmoseley at redhat dot com  2007-02-02 21:34 -------
Here are more observations on memory usage by the source window.  These results
were taken using "top" on a 2GHz P4 with 1GB of memory running FC5 with kernel
2.6.18-1.2257.fc5.  Of particular interest were the memory readings provided by
"top" for its Virtual, Resident and Shared columns.

The scenario is this:  I activated Frysk and took a measurement, then brought up
the source window and took a measurement and then stepped the program 10 times
taking two memory measurements after each step, with ~2 minutes between
measurements. An interesting phenomena was observed which is the reason 2
measurements were taken between each step.  It turns out there is a significance
difference between the virtual memory measurment right after the "step" and the
virtual memory measurement ~2 minutes after the step, which I suppose can be
attributed to GC(garbage collection).

The measurement taken immediately after the step was often 2-3 MB higher than
the measurement taken ~2 minutes later for the same step.  Here is a table of
the measurements:

   Virtual Memory        Resident     Shared
 after  ~2 min. later
 137MB     same             40          23       Initial startup of Frysk UI
 139MB     same             41          23       Showing debug process list
 155MB     152MB            44          25       Activated source window
 156MB     153MB            44          25       after 1 step
 158MB     155MB            45          25       after 2 steps
 160MB     157MB            45          25       after 3 steps
 161MB     158MB            45          25       after 4 steps       
 163MB     160MB            45          25       after 5 steps
 165MB     162MB            46          26       after 6 steps
 167MB     164MB            46          26       after 7 steps
 168MB     165MB            46          26       after 8 steps
 170MB     167MB            47          26       after 9 steps
 172MB     169MB            47          26       after 10 steps
 
 I also ran the test a different way by just doing 10 steps as quickly as I
could.  The initial virtual memory jumped to 192MB but fell back to 169MB within
2 minutes, the same as the memory measurement for step 10 above.
 
 Another phenomema I observed is that when the source window is exited, the
memory measured the last time stays the same, it does not go away unless all of
frysk is exited.  On top of that, if another source window is activated with the
same source code the memory useage jumps by another 4 MB over the last reading.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=3915

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug general/3915] Memory leakage

[mcvet at redhat dot com]

------- Additional Comments From mcvet at redhat dot com  2007-02-07 14:48 -------
Created an attachment (id=1541)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=1541&action=view)
finalize() log file

A quick initial assessment shows that StackFrame.java, FrameCursor.java, and
the private class UnwindArgs in StackTraceCreator.java never seem to get
collected, while other objects associated with stepping do. 

The attached file is a log of finalize() calls from a variety of classes, some
from the DOM, Dwfl and DwflLine.

StackFrame is a pure Java file, FrameCursor and UnwindArgs have native
bindings; the DOM classes are pure Java and the Dwfl classes have native
bindings.

Failure to reach the finalize() for UnwindArgs means that native clean-up
functions like unw_destroy_addr_space are not called.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=3915

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug general/3915] Memory leakage

[mcvet at redhat dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|mcvet at redhat dot com     |
OtherBugsDependingO|                            |1633, 3346
              nThis|                            |
         AssignedTo|frysk-bugzilla at sourceware|mcvet at redhat dot com
                   |dot org                     |
             Status|NEW                         |ASSIGNED


http://sourceware.org/bugzilla/show_bug.cgi?id=3915

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug general/3915] Memory leakage

[mcvet at redhat dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |4042


http://sourceware.org/bugzilla/show_bug.cgi?id=3915

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.