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.
When I configure an application with the following -agentpath:/opt/netbeans-6.0beta2/profiler2/lib/deployed/jdk15/linux/libprofilerinterface.so=/opt/netbeans-6.0beta2/profiler2/lib,5140 setting for the profiler I'm able to connect the netbeans 6 beta2 profiler to it but it: - reports an error: ibprofilerinterface.so: undefined symbol: JVM_DumpHeap (see below) - and in netbeans I'm not able to make snapshots. I'm running the profiler for performance analysis with the default settings. OS: Ubuntu 7.04 JDK 1.5.0_09-b03 (for the application that is being profiled) JDK for netbeans: 1.6.0_01 Profiler Agent: Initializing... Profiler Agent: Options: >/opt/netbeans-6.0beta2/profiler2/lib,5140< Profiler Agent: Initialized succesfully Profiler Agent: Waiting for connection on port 5140 (Protocol version: 8) Profiler Agent: Established local connection with the tool /opt/netbeans-6.0beta2/profiler2/lib/deployed/jdk15/linux/libprofilerinterface.so: undefined symbol: JVM_DumpHeap Profiler Agent: Redefining 100 classes at idx 0, out of total 403 Profiler Agent: Redefining 100 classes at idx 100, out of total 403 Profiler Agent: Redefining 100 classes at idx 200, out of total 403 Profiler Agent: Redefining 100 classes at idx 300, out of total 403 Profiler Agent: Redefining 3 classes at idx 400, out of total 403
The "undefined symbol: JVM_DumpHeap" comment should be just a debug output. What snapshots are you not able to take - cpu/memory profiling data or heap dump?
undefined symbol: JVM_DumpHeap is just debug output. Please attach whole message.log and descibe what you did and what did not work. Thanks.
As requested some more information, I also did some more testing which changes the issue a bit. I'm attempting to locate a performance bottleneck in some code. For this a created a unit test that targets the area in which the problem is. I use maven to build/execute the unit tests etc from the cmdline so in order to be able to conn ect the netbeans profiler to the running application the surefire plugin config in the pom.xml is modified as follows: <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <configuration> <trimStackTrace>false</trimStackTrace> <forkMode>once</forkMode> <argLine>-Xms256m -Xmx256m -XX:NewRatio=2 -XX:MaxPermSize=256m -agentpath:/opt/netbeans-6.0beta2/profiler2/lib/deployed/jdk15/linux/libprofilerinterface.so=/opt/netbeans-6.0beta2/profiler2/lib,5140</argLine> </configuration> </plugin> The particular unit test is then kicked off from the cmdline with: mvn -Dtest=AttributeCopierSpeedTest test On the Netbeans side I choose: Profiler/Attach Profiler CPU/Analyze performance Entire application / no quick filter click the "Attach" button Netbeans profiler now connects to running application and if I click "live results" I get results in the "live results" window. Now I would like to take a snapshot to be able to analyze the calltree and see where the problem originates. When the unit test finishes NetBeans asks if I wnat to take a snapshot, pressing "yes" leaves the maven process (with the unit test hanging) and no snapshot results show up in netbeans. This was with "Entire application" being pro filed. When I narrowed down the code being profiled by setting a "root method" and specifying a filter such that only my own packages are included, I was able to create a snapshot when the unit test was running, and also when the application completed. So apparently there are some limitations on the number of classes/methods that can be instrumented. If I narrow the scope down using the root method and filter it works. Then I analyzed the call tree (I'll attached an image to this issue later and the snapshot.nps). The call tree shows a recursive invocation of org.ossj.tck.util.BaseCBEManagedEntityValueImpl....setDescribedEntityCharacterizedBy method. This recursion goes down really deep (hundreds of recursions) and that's not right. This is not a recursive method and, so the call stack seems to be mixed up here. This class is generated using cglib at runtime. Could that be the source of the problem? Is it a problem for instrumentation that classes are generated at runtime using cglib?
Created attachment 52305 [details] Image of call stack
Created attachment 52307 [details] Snapshot file
Changing target milestone to dev, since NetBeans 6.0 is in high resistance mode.
I filed : http://www.netbeans.org/issues/show_bug.cgi?id=145933 So I can not check now this case.
Please provide any update on this issue. Thanks.
I eventually managed to work around this by limiting the number of classes to be inspected.
Target milestone cleanup.
Milestone cleanup: future->next
May I remove the incomplete keyword? As far as I understand, the requested messages.log is not here, but I would say it is not needed, as there already is a workaround.