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 214947 - Code coverage run in AWT
Summary: Code coverage run in AWT
Status: RESOLVED DUPLICATE of bug 244996
Alias: None
Product: contrib
Classification: Unclassified
Component: Codecoverage (show other bugs)
Version: 7.2
Hardware: PC Linux
: P2 normal with 2 votes (vote)
Assignee: issues@contrib
: 232303 (view as bug list)
Depends on:
Reported: 2012-06-28 20:52 UTC by everflux
Modified: 2014-07-28 06:42 UTC (History)
8 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

self profiling while netbeans was reacting sluggish (19.26 KB, application/octet-stream)
2012-06-28 20:52 UTC, everflux
Sluggishness in RC1 (36.64 KB, application/octet-stream)
2012-06-29 21:04 UTC, everflux
self profiling of 20 seconds showing 13,3 seconds spent in reference handler (68.41 KB, image/png)
2012-06-29 21:04 UTC, everflux
Thread dump (rc1) (28.75 KB, text/plain)
2012-06-29 21:08 UTC, everflux
jvisualvm sampler result (threads) (101.93 KB, image/png)
2012-06-29 21:11 UTC, everflux
jvisualvm sampler result (methods) (153.80 KB, image/png)
2012-06-29 21:12 UTC, everflux
Opening code coverage report page leading to high cpu load (34.16 KB, application/octet-stream)
2012-07-01 16:31 UTC, everflux
.npss file attached from NetBeans (1.71 MB, application/x-npss)
2013-07-25 00:33 UTC, alied

Note You need to log in before you can comment on or make changes to this bug.
Description everflux 2012-06-28 20:52:25 UTC
[ BUILD # : 201206280002 ]
[ JDK VERSION : 1.7.5 ]

I have a maven based project and worked on it for about an hour. While doing
that I switched the git branch externally, ran unit tests and made small edits.
I tested the code coverage feature as well.
Netbeans was at some point very slow to react and used one of my cores
I will attach a short self sampler file to this issue.
Memory usage was about 600mb, I got an information that background compilation
was disable due to low memory about 10 minutes ealier and clicked on the
garbage collect button.

I used jvisualvm to diagnose the issue further - the AWT Thread was using
nearly most cpu time of all.
Perhaps this is a Linux/Nvidia/Gnome/JDK issue instead?
Comment 1 everflux 2012-06-28 20:52:49 UTC
Created attachment 121520 [details]
self profiling while netbeans was reacting sluggish
Comment 2 everflux 2012-06-29 20:57:13 UTC
I was experiencing the same problem with Netbeans RC1. It is nearly unusable with response times in the range of 400 ms (scrolling in text!) to 1 second (clicking a button).
Attached a new self profile. (I wonder why there is no UI gesture captured, since I scrolled and clicked some stuff)
Comment 3 everflux 2012-06-29 21:04:09 UTC
Created attachment 121583 [details]
Sluggishness in RC1
Comment 4 everflux 2012-06-29 21:04:34 UTC
Created attachment 121584 [details]
self profiling of 20 seconds showing 13,3 seconds spent in reference handler
Comment 5 everflux 2012-06-29 21:08:48 UTC
Created attachment 121586 [details]
Thread dump (rc1)
Comment 6 everflux 2012-06-29 21:11:36 UTC
Created attachment 121587 [details]
jvisualvm sampler result (threads)
Comment 7 everflux 2012-06-29 21:12:00 UTC
Created attachment 121588 [details]
jvisualvm sampler result (methods)
Comment 8 everflux 2012-06-29 21:23:30 UTC
I managed to get into a usable state again by selecting "code coverage -> clear results".
All sluggishness went away, and looking at jvisualvm the RequestProcessor$ method stopped eating cpu time. (There was only then an increase in the time when I started interacting with Netbeans again, f.e. scrolling. If I did nothing, the time usage stopped. This was *not* the case previously, even without doing anything one core was completely blocked.)

I way to reproduce the CPU usage (but not the sluggishness) is to open a java class after running code coverage, showing the red and green areas which are covered by tests, then clicking "clear" on the button below the editor.

After that the requestprocessor starts taking cpu time even when no action in the ide happens.
After clicking "done" the cpu usage drops again.

I can only speculate that leaving this running for a couple of hours it starts to accumulate.
Comment 9 jwcone 2012-07-01 07:22:08 UTC
I am also seeing high CPU usage and experience sluggishness (using NB 7.1.2, in my case) on Linux.  Doesn't seem to matter if I run it under JDK 1.7 or 1.6.  My project isn't using the code coverage feature.
Comment 10 David Strupl 2012-07-01 16:12:09 UTC
Can you please post step by step what you did WRT code coverage feature? I mean how did you invoke and on what project etc. Simply step by step I did this this and after that this. Thanks.
Comment 11 everflux 2012-07-01 16:29:27 UTC
Maven based project (can not share it, sorry)

- start netbeans, the project is opened automatically.
- clean and build (reconfigured to invoke "clean package" phases, thus skipping verify and install)
- then right click on the project, select "code coverage -> show report..."

The report is opened, shows "no data -- have you run your code yet?"
After that the CPU usage is high, but netbeans is still mostly responsive.

(I notice that "checking for external changes" is in "suspended" state after that. I assume that netbeans detects the high cpu usage and tries to avoid more load.)

CPU usage was still high when the reports view was not the active tab.

In this case I could solve the problem by clicking "done" on the reports tab.

I will add a self profile with opening the reports view.
Comment 12 everflux 2012-07-01 16:31:27 UTC
Created attachment 121633 [details]
Opening code coverage report page leading to high cpu load
Comment 13 everflux 2012-07-01 16:41:25 UTC
The CPU usage is gone when I hit "Run All Tests" on the report page. It reappears after clicking "Clear Results".
Comment 14 Petr Cyhelsky 2012-07-10 11:20:34 UTC
It seems that most time is spent in native painting code like sun.java2d.loops.FillRect.FillRect[native] perhaps some optimization is needed in offscreen painting of the code coverage results, especially because there can be many many rows off the screen. The problem seems to lie in generic code coverage support, not in the specific maven instance - reassigning to generic code coverage support.
Comment 15 everflux 2012-10-08 14:51:00 UTC
Still happens in Netbeans 7.3.
- Open maven project
- clean and build
- rightclick, code coverage, show report
- hit button "clear results"
Now: High CPU load (on one core)

Click on "run all tests"
When tests are finished the CPU load is gone.
Comment 16 everflux 2012-11-03 09:20:29 UTC
Can be reproduced with Netbeans 7.3 beta 2 (201211020750) 
Still only when no code coverage report is available to be shown!
For example: 
Open coverage report, click "clear all results" -> CPU starts to burn cycles.
Click "run all tests", when finished the load vanishes.
Click on "clear all results", load reappears.
Comment 17 Petr Jiricka 2013-02-08 13:52:17 UTC
> The problem seems to lie in generic code coverage support, not in the specific maven instance > - reassigning to generic code coverage support.

The problem is that contrib/codecoverage category is not on the bug dashboard so this can fall off the radar. maven.coverage module is a part of the standard distribution. So where should it be assigned?
Comment 18 Jiri Kovalsky 2013-02-26 14:14:16 UTC
I think this is assigned correctly. We just don't have any maintainer of this module. Any volunteer? :)
Comment 19 everflux 2013-06-20 10:16:43 UTC
I am offering a bounty for the guy who fixes this issue. (Would a beer or grand ice cream do?)
Comment 20 alied 2013-07-21 01:49:51 UTC
*** Bug 232303 has been marked as a duplicate of this bug. ***
Comment 21 alied 2013-07-25 00:33:51 UTC
Created attachment 137743 [details]
.npss file attached from NetBeans

.npss file
Comment 22 everflux 2013-12-17 10:54:26 UTC
Is this hard to fix? (Could someone point out what has to be done in general, so I could look into the code myself or another netcat volunteer?)
Comment 23 everflux 2014-07-21 13:16:27 UTC
Is is fix for this targeted for 8.0.1 ?
Comment 24 Martin Entlicher 2014-07-28 06:42:34 UTC
Probably fixed by issue #244996. Please verify.

*** This bug has been marked as a duplicate of bug 244996 ***