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.
Whenever I make a profile for my project, which is a very large codebase with very large files and deeply recursive, I get *huge* log files in my .netbeans/5.5.1/var/log. I just ran a profile last night and ended up with 125GB log file and a 31GB log file. Yes, that is gigabytes! This has happened to me before too. I don't have the log files any more because I had to get rid of them because they where causing issues for other users on the system. Next time this happens I'll try to get a snippet of what is being logged before I remove the files.
Wow that is a huge file. We are not aware of any periodic or useless logging from profiler. Maybe there is thread dump which is repeated over and over. Anyway it is important to get part of your log. You don't need to wait to have a few gigabyte log - check the size earlier. I believe if you compress or zip such log file it will be significantly smaller and you can attach it to the issue. Lowering priority to P3 - it looks like that this is not general issue.
*** Issue 107864 has been marked as a duplicate of this issue. ***
Looks like it is printing out extremely many messages like: *** Profiler engine warning: critical: stack integrity violation on method exit. *** methodId on simulated stack top: 34036, received methodId (should match) = 1268 *** Please report this problem to feedback@profiler.netbeans.org
I ran the profiler for about 1 minute and got a 33MB log file.
Ok, so problem is not big log file, but this error message. Please provide some way how to reproduce it.
few hundreds kilobytes from beginning of var/log/messages.log will be also useful.
I'm not sure how to tell you to reproduce the problem since this is a large proprietary codebase that I'm profiling. I do get a warnings when I start up saying that more than 64K methods have been instrumented and some methods will not be instrumented. When I try to instrument from a root though the profiler just crashes on me so I always end up having to do full profiles. I have had other problems related to this codebase though with other parts of the system because of pervasive internal netbeans use of characters to hold offsets and after instrumentation, some of the methods might be bigger than would be allowed by a 2 byte offset. I really think there are 2 critical issues here: 1. It shouldn't be possible to generate 125GB log files (independent of anything else) ever! 2. The profiler error: ** Profiler engine warning: critical: stack integrity violation on method exit. *** methodId on simulated stack top: 34049, received methodId (should match) = 1281 and similar error messages that I'm receiving.
Created attachment 44278 [details] Here is some of the log file
You really do not want to profiler more than 64K methods and with this huge codebase you do not want to profile entire application. It will create too much overhead. You should limit scope of profiling by either filtering out JDK and library classes and/or using root methods. Issue with log file cannot be solved by profiler, since there is a lot of other code, which logs into log file. Looking at 'stack integrity violation on method ' methodId in hex, you will get 0x84F4 0x04F4 - are you using 'Exact Call Tree, Sampled Timing' ? If so, this is known problem (issue #83820) probably caused by bug in HotSpot compiler.
1. I'm using exact call tree and timings but part of the bug seems like it might be related to issue #8382 2. I always do filter out JDK class calls. 3. Like I said before, it is impossible for me to run the profiler instrumenting from roots, because that crashes the not just Netbeans but the the JVM itself! # An unexpected error has been detected by Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00002aaaab57cace, pid=28969, tid=1090754880 # # Java VM: Java HotSpot(TM) 64-Bit Server VM (1.6.0-b105 mixed mode) # Problematic frame: # V [libjvm.so+0x45eace] # # An error report file with more information is saved as hs_err_pid28969.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp #
Created attachment 44280 [details] JVM error log -- I've submitted this to sun
Just to note, profiling the entire appilcation seems to work fine (except for the extreme slowdown from all the exception handling and logging and the *huge* log files themselves). I have a decent machine with 4 processors and 16GB of memory and my _JAVA_OPTIONS allows Java heaps to grow to 12GB. So overhead really isn't an issue for me.
according to the messages.log attached to this issue you are trying to profile your application using 'Exact Call Tree, Sampled Timing' - (this is 'cpuProfilingType = 1' entry - which means you use sampled timing; if you had used exact timing the cpuProfiling would have been of value 0) thus setting this issue as a duplicate of the issue #83820 *** This issue has been marked as a duplicate of 83820 ***
This is not a duplicate. Only a portion of this bug is a duplicate. The other point about throttling of message is extremely valid. The profiler, under this circumstance, is abusing the services of the general logging mechanism. A profiler should never, ever, ever, ever cause a dozen people at my workplace to halt work becuase it causes the system to fill up all the available diskspace with 150GB+ worth of log files in a very short timee.
Once Issue 83820 will be fixed the logfile won't grow this way. Moreover, there is a simple workaround for now to use exact call tree and timing. For these reasons changing the priority to P3. In general, logfile is a way for IDE modules to log important actions/settings/states and it's absolutely OK to log all these things. If the IDE provides logging facility, it should also control logfile behavior incl. size, there's no way how to do this from the modules. So it seems to me that this should be rather an ENHANCEMENT for logging support of the IDE than a DEFECT in profiler.
There is not a simple workaround, because I have to use sample calling with very large sample times to get to the piece of code in any sort of reasonable time. My appilcation preforms a lot of work that takes a very long time, so I use sample timing at very large sample rate until I get to the part that I want to sample, then set it to exact timings. I can't use profiling from root because that crashes the JVM which I've described already. This issue will also creep up in any similar types of profiler bugs as well. Having, Netbeans have the ability to cause critical work-stoppages because of the refusal to put in some simple throttling to prevent logging abuses just seems incredibly silly and almost negligent. The need for throttling is bigger than just bug 83820.
Every module which logs its events may cause exactly the same problem, not just the profiler. It would be silly to implement proprietary "throttling" in each module separately. At the profiler side the best we can do is to fix all the bugs causing enormous logging. I definitely agree with you that some mechanism to (for example) define maximum logfile size to prevent problems like this would be useful. To make some kind of summary: - there is a "stack integrity violation on method exit" bug tracked by Issue 83820 - will be fixed for 6.0 - there is a bug preventing you from using Part of Application mode, according to your comment already submitted to Sun - there is a general problem with the logfile eventually consuming all the disk space, currently happens because of Issue 83820 - at the profiler side we will do our best to decrease logging and fix this Issue 107865, then we can search for some more general solution for logging as such
That sounds exactly right 8-).
This issue might be more appropriately moved under the logging component or a sub-issue of this bug maybe. Having some sort of message throttling/limiting in the most general place possible will most likely have the greatest chance of defeating similar sorts of critical failures in the future.
I created issue 108814 to address the general logging issues.
the bug causing the logging problem was resolved by issue #83820 the logger throttling is being discussed in issue #108814 closing this issue as fixed; there is nothing more to be done in profiler
This issue doesn't seem to be fixed. Please consider resolving it as wontfix.
The issue is fixed. Profiler no longer creates huge log file.
There is an issue 115164 which can probably lead to creation of a huge log file. Marking as verified according to your comment.