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 167501 - NB unresponsive (25% cpu, heap full)
Summary: NB unresponsive (25% cpu, heap full)
Status: RESOLVED INVALID
Alias: None
Product: editor
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker with 1 vote (vote)
Assignee: issues@editor
URL:
Keywords: PERFORMANCE
Depends on:
Blocks:
 
Reported: 2009-06-23 03:56 UTC by jn
Modified: 2009-08-21 08:15 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
output of jstack (24.19 KB, text/plain)
2009-06-23 04:05 UTC, jn
Details
messages.log file (244.52 KB, text/plain)
2009-06-24 03:07 UTC, jn
Details

Note You need to log in before you can comment on or make changes to this bug.
Description jn 2009-06-23 03:56:54 UTC
This is for NB 6.7 RC 3.  I am using a quad core system on Windows XP, with Java 1.6.0_13.

I have marked this as a P1 because NetBeans freezes and becomes completely unresponsive for me.  My only recourse is to
kill the app, and sometimes I must delete the cache dir before restarting (or the problem recurs).

While using NetBeans, I notice that the CPU often jumps to 25% and stays there for a long time.  I suspect this may be
related to classpath scanning.

While this CPU utilization is occurring, under some circumstances (when? I don't know) the memory consumption will grow
quickly to fill the allocated heap space.  At that point (with the CPU still pegged at 25% and the heap full), the
application will become unresponsive.  The NB UI does not respond, and the windows "close" widget in the upper right
does not cause the application to close.  I am forced to terminate the process.  Often when this happens and I terminate
the process and restart NetBeans, the heap will grow very quickly (within 1 minute) to the allocated heap size and the
same problem occurs.  If the problem recurs in this way, I am able to clear the problem by terminating the app and
deleting NetBeans' cache dir.

I was initially running with the default heap size (NB was taking 512MB).  I tweaked the conf file to use 800MB instead,
but that didn't relieve the problem -- the heap usage grew to 800MB and the app froze again.

My setup:  Java Free-Form Project, about 2500 source files (with 84 jar dependencies), about 215 test files (with the
same 84 jar dependencies, plus dependency on source files dir).  The code is proprietary and can't be shared.
Comment 1 jn 2009-06-23 04:05:25 UTC
Created attachment 83905 [details]
output of jstack
Comment 2 jn 2009-06-24 03:07:22 UTC
Created attachment 83970 [details]
messages.log file
Comment 3 Marian Mirilovic 2009-06-24 11:45:55 UTC
reassign to editor for evaluation
Comment 4 Vitezslav Stejskal 2009-06-24 15:26:57 UTC
It looks like there was a refactoring task running and it was compiling some java sources. I'm not sure why was it
running or for how long. Was there any visual indication of some background activity in the IDE (eg progress bar,
hourglass cursor, etc)? Could you also create several successive threaddumps during the IDE activity and attach them
here? It would be good to have a reproducible usecase, eg. to know what operation or user action triggers the IDE
activity. We could then try to simulate the problem locally on some other project. Thanks
Comment 5 Jiri Prox 2009-08-19 15:26:18 UTC
Unfortunately there is no feedback from reported, I'm afraid that without requested info we cannot do anything about it,
since we weren't able to reproduce it, Closing as Invalid for now.

Feel free to reopen and provide requested info if it is still reproducible
thanks
Comment 6 jn 2009-08-21 08:15:16 UTC
Well for the record, this still occurs for me (with the same frequency, which means occasionally), in 6.7.1.  It's a
pretty severe problem -- the entire IDE locks up and I have to kill the process and blow away the cache.  I just don't
have a whole lot of time to help you guys diagnose/reproduce it.  I don't really think it makes sense to close a bug
that's reproducible, just because *you* can't reproduce it.  The issue exists.