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.
Attached is the screen shot of the problem. I noticed this because when I select the lower entry the focus will "automatically" put back up on the upper entry.
Created attachment 27008 [details] bug (Profiler M10, NB5 Beta 2)
Oh btw, it is an "Analyze Performance" on "Entire Application" with Filter "Exclude Java Core Classes"
Thanks for the report. Could you please attach the CPU snapshot with double entries so we can analyze the cause? If possible, please provide sample code which reproduces this bug.
Attached is the source for reproducing the problem and the snapshot taken as requested. To reproduce the problem, profile the application as described above; open and "Live Results" window, then on the main application JFrame repeatly click on the upper "Add" button until you see the 2 "getElementAt(int)" results come up in the rank.
Created attachment 27009 [details] CPU snapshot
Created attachment 27010 [details] source files to reproduce the problem
It seems there is missing the MainPanel.java in the attached archive.
oh... sugar attached the wrong file - thx for reminding ;) *try again*
Created attachment 27111 [details] hopefully the correct source files
I can reproduce the problem, thanks for providing the sample app. The problem seems to be that the method is tracked under two different jMethodIDs, still have to investigate why this is happening. Adjusting the priority to reflect the seriousness of the issue.
Further investigation shows that: - the problem happens with all 3 instrumentation schemes - the root cause of the problem is the fact that the getElementAt method is for some reason instrumented twice - once as a root and once as a regular method. The two instrumentations call into profiler agent separately, resulting in two different records for the method.
The very root cause of this issue is the fact that the method in the implementation has a different return type than int prototype in the interface (String vs. Object). The profile engine does not treat this correctly if the method is also a root and would instrument the method twice. Since the constellation of things leading to this is rare, and the resulting behavior is not erroneous in a fatal way, lowering the priority to P3. We will not fix this in 1.0, since the fix is not trivial. Will fix in the second release.
thanks for identifying the root cause - although covariant return type has only started its life in Tiger, the use of it could become rather common - e.g. Object.clone() maybe a workaround or even a warning jogged down somewhere in 1.0 would be desirable.
assigned for reevaluation on the trunk
changing component