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.
Profiler 070515 NetBeans IDE Dev (Build 070516) 1.6.0; Java HotSpot(TM) Client VM 1.6.0-b105 Windows XP version 5.1 running on x86 ru_RU (nb); Cp1251 I encountered several times the following situation: profiler throws OOME (due to large amount of profiling data) which is shown only in logs, but doesn't inform user about that in the proper way: instead of displaying a message that there are not enough memory, it shows a message that "Profiled application doesn't respond". So the user may be spending time trying to get the profiled application responding while the root problem is OOME in profiler. Steps to reproduce: - Download FindBugs 1.1.3 (http://easynews.dl.sourceforge.net/sourceforge/findbugs/findbugs-1.1.3.zip) - Run FindBugs with Java 6.0 - Perform Dynamic Attach to FindBugs with customized Analyze Performance task: Entire Application, Profile All Classes, enabled Profile Threads Started after entering any of root methods option, enabled Threads - In FindBugs create New Project using all JAR files from <NBInstallDir>/profiler2/modules folder - Press Finish. This will cause FindBugs to perform Analysis - RESULT: OOME is thrown in Profiler, but "The profiled application doesn't respond" message is shown. Exception in thread "Thread-10" java.lang.OutOfMemoryError: Java heap space at com.sun.tools.profiler.results.EventBufferResultsProvider.dataReady(EventBufferResultsProvider.java:66) at com.sun.tools.profiler.ProfilerClient.readAndProcessProfilingResults(ProfilerClient.java:1064) at com.sun.tools.profiler.ProfilerClient.access$2200(ProfilerClient.java:54) at com.sun.tools.profiler.ProfilerClient$ServerListener.handleServerCommand(ProfilerClient.java:1663) at com.sun.tools.profiler.ProfilerClient$ServerListener.run(ProfilerClient.java:1599) Moreover, the profiled application gets frozen when this exception is thrown.
The main reason for OOME was usage of an unbounded queue for incomming data. In order not to block the profiler application (ProfilerServer) the client part tries to store the incomming profile data in a queue to process them later if there is no enough CPU power to process them as they come. This can lead to an ever-growing queue of raw data and exhausting the heap. This has been fixed in the NB profiler some time ago - now the queue is bounded and after reaching the upper bound it blocks the server part until a significant part of the incoming data has been processed. As for catching the OOME and displaying a custom message - this might be pretty tricky because the OOME is thrown when the heap is depleted; and so there might be not enough memory left to create fancy GUI showing the user that the OOME happened. He must go to the logs and find it there.
Described steps to reproduce don't lead to OOME. Can't reproduce to verify.
Verified with Beta1