This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 59086 - Stack-trace for memory leaks should be reversed
Summary: Stack-trace for memory leaks should be reversed
Status: NEW
Alias: None
Product: profiler
Classification: Unclassified
Component: Base (show other bugs)
Version: 5.x
Hardware: All All
: P2 blocker (vote)
Assignee: issues@profiler
Depends on:
Reported: 2005-05-20 03:36 UTC by _ gtzabari
Modified: 2009-05-25 21:03 UTC (History)
0 users

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description _ gtzabari 2005-05-20 03:36:44 UTC
Currently when using the profiler to look for memory leaks the "class name"
column displays a list of types of objects that are allocated and if you "Show
Allocations Stack Traces" on it it displays a tree where the parent is the class
constructor of the allocated object and the children lead up to the top of the
call-stack leading to that constructor call.

This is very unintuitive. When I'm looking for memory leaks, I want to be able
to drill from the top-down, not from the bottom-up. I want to look at the
call-stack from the top-level methods, then find out which of their children
methods allocate the most amount of memory. I don't care what kind of object is
being leaked as much as which method allocated those objects in the first place.

Right now I find the profiler almost useless for memory leak detection. It takes
way too long to get at the data I'm looking for.

What do you think?
Comment 1 iformanek 2005-06-03 13:41:51 UTC
Let me see if I understand correctly what you mean.
There are two possible approaches:
1. once you determine which objects are leaking, you would like to see their 
allocation call stacks in a forward way

2. you would like to have a view similar to CPU Call Tree, displaying 
information about amount of memory allocated in each method (instead of CPU 

If 1. is what you mean, could you explai a bit more why the reverse graph is 
less useful?
Comment 2 _ gtzabari 2005-06-03 16:45:48 UTC
I don't remember how the CPU usage looked like so I will try explaining without it.

Think about it this way:

most programs are going to be leaking char[] or byte[] simply because these are
the most widely used low-level variable types so listing them as the top leaks
is kinda useless.

It is very rare (in my mind) that telling me what *kind* of variable is leaking
is going to help me actually fix the leak. What is useful for me is to know
*where* it is being leaked from. Usually you end up finding defective
code-blocks which need fixing. byte[] might be allocated perfectly fine in one
block but wrong in another which is why listing the allocation type is irrelevant.

I hope this clarifies my view. Anyway, if you take a look at OptimizeIT's memory
view they list it this way.
Comment 3 Tomas Hurka 2009-04-08 12:55:56 UTC
Milestone cleanup: future->next