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.
Both liveness and allocations results are wrong if takeStackSampleEvery is set to <=0. Liveness results always report 1 instance of an object being created (for all differenct classes), it is possible to get allocation stack trace for it. Allocation results report multiple instances, but still incorrect, and incorrect byte size. The allocation stack traces are corect (still the action should be disabled, I'll correct this one).
This is not a bug - you should not set takeStackSampleEvery to a value <= 0. If you want to disable the engine getting stack traces, you should set objAllocStackSamplingDepth to <= 0 (as you already correctly do). I am going to fix the engine to treat this correctly now. But takeStackSampleEvery (or rather objAllocStackSamplingInterval, as it is called correctly) is a different thing. It probably should be renamed given our changed semantics to smth. like trackedObjectsInterval. Its primary meaning (for object liveness profiling) is "which objects to track", that is, for which objects to allocate a WeakReference, send the info to the tool, etc. It doesn't make sense to set it to <=0, i.e. to track no objects. And I would disagree with the default value of 1 either, unless I hear any real complaints from customers about the way things currently work, since if 1 is default, memory consumption of many target apps (all these weak refs), as well as of the tool (a table entry for every single target app object) may grow dramatically. For object alloc profiling, objAllocStackSampling interval would be just meaningless with stackSamplingDepth <= 0, but that's not a problem for the engine code. One note about the standard memory profiling UI: it should be changed to allow objAllocStackSamplingInterval to be adjustable even when user chooses not to take stack traces (stack depth is set to <= 0), because of the "tracked objects" thing above. I.e. you may or may not take stack samples for tracked objects, but you have to specify how many you want to track. I realize that the resulting UI may get a bit messy. But, well, if you decided to change the original design about which we never received complaints, you should be prepared to fix the consequences...
Oops.. just realized that for object allocation profiling, objAllocStackSamplingInterval has a meaning too, even when no stack samples are taken - it means objects for which size is reported. So at least the UI is going to be uniform for both object alloc and object liveness profiling.
Verification of old issues.
Closing old issues.
Reverting to the original Target Milestone value changed by mistake. Sorry for inconvenience.