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 77543 - Reset Results Profiling Point is ignored?
Summary: Reset Results Profiling Point is ignored?
Status: RESOLVED FIXED
Alias: None
Product: profiler
Classification: Unclassified
Component: Base (show other bugs)
Version: 6.x
Hardware: PC Windows XP
: P3 blocker (vote)
Assignee: issues@profiler
URL:
Keywords:
Depends on:
Blocks: 79229
  Show dependency tree
 
Reported: 2006-06-07 21:24 UTC by _ gsporar
Modified: 2007-06-25 15:19 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
sample application (26.98 KB, application/octet-stream)
2007-04-05 17:20 UTC, _ gsporar
Details

Note You need to log in before you can comment on or make changes to this bug.
Description _ gsporar 2006-06-07 21:24:09 UTC
This is similar to what I reported in
http://www.netbeans.org/issues/show_bug.cgi?id=77537, but different.  In this
situation, the snapshot is being taken, but it appears that the reset results
profiling point is being ignored. 

Running NB 6.0 QBuild from 2006-05-31 on JDK5u5, using the sample application
and instructions that are attached to
http://www.netbeans.org/issues/show_bug.cgi?id=77542, the reset results
profiling point seems to not be working.  In other words, on the instances when
I avoid the crash that is reported in
http://www.netbeans.org/issues/show_bug.cgi?id=77542, the end result I see is
not correct.  The snapshot gets taken at line 63 of PrimeCalculator.java, but
when I open that snapshot it shows information from when the program started up.
 The method I'm interested in (where the reset and snapshot profiling points are
located in PrimeCalculator.java) runs on its own thread and I see results from
*all* threads.

An additional indicator is that in the "Profiling Points" window in the
lower-right hand corner of the IDE, the entry for the reset results profiling
point does not have anything in its "Result" column.  Shouldn't it have some
sort of indication that the profiling point was reached and therefore results
have been reset?
Comment 1 Maros Sandor 2006-06-12 15:22:06 UTC
I cannot reproduce it. It either crashes or results are reset properly. please
reopen if it happens with newest daily build and provide step by step
instructions. I improved usability so that Reset Results point now shows the
time it reset results.
Comment 2 Jiri Sedlacek 2007-03-22 14:04:22 UTC
Could you please check if the problem is still valid after Profiling Points 
reimplementation?
Comment 3 _ gsporar 2007-04-05 17:18:19 UTC
Well, I *guess* it's correct now, although I'm not really sure.  Things
certainly work *much* better than they did last summer when I opened this IZ.  :-)

I have attached the latest version of the project, if you want to see what
things look like now.  I set a Reset Results profiling point at line 45 of
PrimeCalculator.java and then a Take Snapshot profiling point at line 81 of
PrimeCalculator.java.  

I then did CPU profiling with "entire application" and "profile all classes" and
"use profiling points" selected.  I put in 1000000 as the value in the
application and clicked the Calculate button three times.

I got three snapshots, which is correct.  When I open the snapshots, though, all
of them include not only the thread on which the code ran, they also include the
event handler thread.  It doesn't seem like to me the event handler thread
should be listed, but perhaps I'm not understanding something here....
Comment 4 _ gsporar 2007-04-05 17:20:09 UTC
Created attachment 40511 [details]
sample application
Comment 5 Jiri Sedlacek 2007-06-25 15:19:54 UTC
I've found out that for some reason PrimeNumbers.actionPerformed() at line 215 is being called from the EventQueue 
during computing of the prime numbers by separate thread. In fact these two threads are both running at the same time 
and that's why you can see them in the snapshot.

I'll close this issue as the Reset Results profiling point seems to be processed correctly. Please file a separate 
issue if you think that the behavior describe above is a bug (but it seems to be behaving this way even without 
profiling).

Fixed by Profiling Points reimplementation.