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.
Product Version: NetBeans IDE Dev (Build 201510020002) Java: 1.8.0_60; Java HotSpot(TM) 64-Bit Server VM 25.60-b23 Runtime: Java(TM) SE Runtime Environment 1.8.0_60-b27 System: Linux version 3.19.0-28-generic running on amd64; UTF-8; en_US (nb) User directory: /home/tkruse/.netbeans/dev Cache directory: /home/tkruse/.cache/netbeans/dev I have a maven based java project with multiple classes with main methods, the classes contain other classes or interfaces. The profiler does not collect data reliably. It seems related to a combination of - selected main class for the project - whether classes are explicitly configured to be profiled
Created attachment 156492 [details] sample project
Steps to reproduce - open sample project - clock on profile button in toolbar -> profiler window opens - click on profile button below toolbar in profiler window -> netbeans asks which main class to run - select one, run it If data is shown (I can not recall if that worked on the first run for me) select the other class in the project explorer, right click, "profile class", click on profile button in profiler window -> class is executed, no data shown. If this works for you, open one of the sample classes, place cursor on class name, right click and from context menu "profile..." select "class". Now run the profiler -> data is shown. Select other class from project explorer. right click, "profile file" and execute the profiler -> no data shown (expected), select the settings/gears icon in the profiler window (most right in the window mini toolbar), change "selected classes" to "all classes" or "project classes", run profiling session -> no data shown. Change to "project classes", execute profiler session -> no data shown.
Works fine on my side. Please note that Profile Class just sets up the profiler to profile code of that class, it doesn't change the project main class. To me it looks like you've set up the profiler to profile class A but the project is actually configured to run class B. Once you make sure that the project runs the class selected for profiling (Project Properties | Run | Main Class), you'll start getting the data.
Exact reproduction steps with Product Version: NetBeans IDE Dev (Build 201510050002) Java: 1.8.0_60; Java HotSpot(TM) 64-Bit Server VM 25.60-b23 Runtime: Java(TM) SE Runtime Environment 1.8.0_60-b27 System: Linux version 3.19.0-30-generic running on amd64; UTF-8; en_US (nb) User directory: /home/tkruse/.netbeans/dev Cache directory: /home/tkruse/.cache/netbeans/dev * open project * select profile project, use Trampoline2Demo as main class * initial calibration is performed * data is shown, great * open Trampoline2Demo * Right click on Trampoline2Demo, Profile, "Profile class" * run profiler -> data is shown, great * Use settings to go back to "all classes" * Run profile -> no data
Created attachment 156517 [details] screencast showing the problem
On second though I added Thread.sleep - then I get data collected again with all classes. I assume that the sampler does not get results since the sample project is too small. This does not explain why it consistently worked at first and only broke when I first selected the 'profile class' mode and switched back. If this is indeed the root cause, I would expect from a user perspective to have an alert box like 'no data was collected in sampling mode, try instrumented mode or choose an application that runs longer' instead of netbeans hanging there with the output window of the maven build.
I am sorry, but I am not able to reproduce it. Did you start with clean userdir? Did you write all the steps?
Which step can you not reproduce? I tried it on two machines, one had a clean userdir, the other not. Both machines intel, one 2 cores plus hyperthreading, the other 8 cores plus hyperthreading. Both latest Java 8u60 and latest Netbeans nightly with the new profiler.
(In reply to everflux from comment #8) > Which step can you not reproduce? I am following those steps in 'comment 4' and it works for me.
If you cross check it with the video attachment I added, you can confirm that you get data in the last step? That would mean that there is actually a bug and I did not have false assumptions about how to use the profiler. (sampling mode of too short application)
(In reply to everflux from comment #10) > If you cross check it with the video attachment I added, you can confirm > that you get data in the last step? Yes, I do get the data.
What can I do to complete the bug report?
(In reply to everflux from comment #12) > What can I do to complete the bug report? Please start with clean userdir and document all the steps. If this is not possible, provide full video, so we can extract the steps to reproduce this issue ourself.
Created attachment 156556 [details] screencast, clean userdir, showing problem (<2 min)
steps: - profile project (works) - profile single class (works) - switch back to profile all classes / project classes (no data)
(In reply to everflux from comment #14) > Created attachment 156556 [details] > screencast, clean userdir, showing problem (<2 min) Thanks for the screencast. The missing part in your steps is the following item: Click on 'Do not show this messages again' checkbox in 'The profiled application has finished execution.' Next time, it would be great if you can provide exact steps and do not leave out some of them - even if they look unimportant.
Oh my... I wasn't even aware of that click, otherwise I would have included it. Sorry that I made this bug report such a bad experience. Thanks for taking it seriously and looking into it! If I can provide any additional help/information let me know.
To workaround this issue, you can reset 'Do not show again' confirmations in Profiler preferences (Options/Java/Profiler/General). This way you will get the dialog back. The confirmation dialog will keep profiler application live longer so that profiler will get profiled data.
(In reply to everflux from comment #17) > Oh my... I wasn't even aware of that click, otherwise I would have included > it. Sorry that I made this bug report such a bad experience. > > Thanks for taking it seriously and looking into it! > If I can provide any additional help/information let me know. Thanks, I think we have all the information to reproduce the problem.