You need to log in before you can comment on or make changes to this bug.
Reported by the user: Unexpected Signal : 10 occurred at PC=0xFEF21754 Function=[Unknown. Nearest: JVM_RaiseSignal+0x53040] Library=/xauser1.v4902/xacct/smm/mfeldman/profiler/jfluid- jdk/jre/lib/sparc/client/libjvm.so Current Java thread: at com.sun.tools.profiler.server.system.Stacks.getMethodNamesForJMethodIds(Native Method) at com.sun.tools.profiler.server.ProfilerInterface.getMethodNamesForJMethodIds (ProfilerInterface.java:325) at com.sun.tools.profiler.server.ProfilerServer.handleClientCommand (ProfilerServer.java:634) at com.sun.tools.profiler.server.ProfilerServer.listenToClient (ProfilerServer.java:424) at com.sun.tools.profiler.server.ProfilerServer.run (ProfilerServer.java:275) Dynamic libraries: 0x10000 /xauser1.v4902/xacct/smm/mfeldman/profiler/jfluid- jdk/jre/bin/java 0xff370000 /usr/lib/libthread.so.1 0xff3fa000 /usr/lib/libdl.so.1 0xff280000 /usr/lib/libc.so.1 0xff3a0000 /usr/platform/SUNW,Sun-Fire-V490/lib/libc_psr.so.1 0xfec00000 /xauser1.v4902/xacct/smm/mfeldman/profiler/jfluid- jdk/jre/lib/sparc/client/libjvm.so 0xff230000 /usr/lib/libCrun.so.1 0xff210000 /usr/lib/libsocket.so.1 0xff100000 /usr/lib/libnsl.so.1 0xff1c0000 /usr/lib/libm.so.1 0xff0e0000 /usr/lib/libsched.so.1 0xff0c0000 /usr/lib/libmp.so.2 0xff070000 /xauser1.v4902/xacct/smm/mfeldman/profiler/jfluid- jdk/jre/lib/sparc/native_threads/libhpi.so 0xfebd0000 /xauser1.v4902/xacct/smm/mfeldman/profiler/jfluid- jdk/jre/lib/sparc/libverify.so 0xfeb90000 /xauser1.v4902/xacct/smm/mfeldman/profiler/jfluid- jdk/jre/lib/sparc/libjava.so 0xff040000 /xauser1.v4902/xacct/smm/mfeldman/profiler/jfluid- jdk/jre/lib/sparc/libzip.so 0xfeb00000 /xauser1.v4902/xacct/smm/mfeldman/profiler/lib/deployed/jdk142/s olaris-sparc/libprofilerinterface.so 0xfe9e0000 /usr/lib/librt.so.1 0xfe9c0000 /usr/lib/libaio.so.1 0xfe9a0000 /usr/lib/libmd5.so.1 0xfe870000 /xauser1.v4902/xacct/smm/mfeldman/profiler/jfluid- jdk/jre/lib/sparc/libnet.so 0xfe820000 /xauser1.v4902/xacct/smm/mfeldman/xacct/Shared/libxacct_native_s parc_SunOS.so 0xfe2e0000 /usr/ucblib/libucb.so.1 0xfe2b0000 /usr/lib/libelf.so.1 0xb3a80000 /xauser1.v4902/xacct/smm/mfeldman/xacct/Shared/libdb_java-3.3- sparc-SunOS.so 0xfbea0000 /usr/lib/libresolv.so.2 Heap at VM Abort: Heap PSYoungGen total 470976K, used 992K [0xb5800000, 0xd5800000, 0xd5800000) eden space 4352K, 22% used [0xb5800000,0xb58f8528,0xb5c40000) from space 466624K, 0% used [0xb5c40000,0xb5c40000,0xd23f0000) to space 53312K, 0% used [0xd23f0000,0xd23f0000,0xd5800000) PSOldGen total 36096K, used 31359K [0xd5800000, 0xd7b40000, 0xf5800000) object space 36096K, 86% used [0xd5800000,0xd769fdd8,0xd7b40000) PSPermGen total 22016K, used 12289K [0xf5800000, 0xf6d80000, 0xf9800000) object space 22016K, 55% used [0xf5800000,0xf6400778,0xf6d80000) Local Time = Wed Aug 24 10:12:06 2005 Elapsed Time = 659 # # JFluid Virtual Machine Error : 10 # Error ID : 4F530E43505002F8 01 # Please report this error to Mikhail.Dmitriev@sun.com # # Java VM: JFluid Client VM 1.4.5 (based on Java HotSpot(TM) VM) (1.4.2_04-b05 mixed mode) # space 4352K, 23% used space 466624K, 0% used space 53312K, 0% used space 36096K, 86% used space 22016K, 55% used# An error report file has been saved as hs_err_pid15438.log. # Please refer to the file for further information. # JVM_OnLoad called...
Created an attachment (id=24171) [details] error log
Created an attachment (id=24172) [details] error log
Created an attachment (id=24173) [details] error log
*** Issue 64770 has been marked as a duplicate of this issue. ***
*** Issue 65711 has been marked as a duplicate of this issue. ***
This error is easily reproducible. 1. create a web application TomcatJSPExample 2. run the profiler using Profile Main Project, select memory profiling, "Record Object Creation Only" and "Record Stack Traces for Allocations" 3. click on the Basic Arithmetic example in the browser 4. click Take Snapshot
Created an attachment (id=26309) [details] Fatal Error Log (Windows)
*** Issue 62793 has been marked as a duplicate of this issue. ***
*** Issue 68295 has been marked as a duplicate of this issue. ***
Very probably fixed in M12
Got this using RC1. hotspot crash file attached.
Created an attachment (id=28411) [details] hs_err_pid5776.log occurred during get snapshot (memory)
Created an attachment (id=28414) [details] RC1 Crash, under JDK 1.5.0_06
To jchristi: We were not able to reproduce it. Are you able to reproduce it? Can you provide steps how to reproduce it? Thanks.
I can easily reproduce it with our software running on top of JBoss running when a load has been placed on it (its fairly busy). Unfortunately I cannot send you our code. I will attempt to create an easily reproducable case, but it seems that I've seen this error for so long and seem to consistently have it happen at least 50% the time when I try to take a memory snapshot on a busy system, that Sun would have been able to come up with a busy app server test system for you that you should be able to get this to happen fairly regularly. This bug is pretty much the biggest problem that will cause many developers to not be able to use the profiler on anything than on little programs and not on full scale app server configurations... you loose alot of time (and patience) when you have been collecting for hours and then go to take a snapshot, and your whole JDK comes crashing down.
Created an attachment (id=28424) [details] Crash
Created an attachment (id=28425) [details] Yet another.... :(
Believe me, that we are doing maximum to find out what is wrong. I myself spent large part of yesterday with this issue, but without being able to reproduce it, it is very hard to fix it. If you can help us find out how to reproduce it that will be very welcomed.
One additional note. Can you try to run your application with -Xnoclassgc to see if it fixes the issue or not. Thanks.
*** Issue 84655 has been marked as a duplicate of this issue. ***
Created an attachment (id=33952) [details] SIGSEGV on Linux of same crash, with 1.5.0_08-b03
*** Issue 84112 has been marked as a duplicate of this issue. ***
*** Issue 85679 has been marked as a duplicate of this issue. ***
From a mailing list: I don't have any instructions to reproduce this issue that aren't already there. But from that duplicate issue page (http://www.netbeans.org/issues/show_bug.cgi?id=62919) I tried thurka's suggestion of running my app with -Xnoclassgc. And "record stack trace for allocations" no longer results in an EXCEPTION_ACCESS_VIOLATION. Halleljuah! I still don't understand how this works, but perhaps it's worth noting that I am making heavy use of Jython in my app, and I am under the impression that Jython makes heavy use of dynamically-generated classes. So, maybe it stands to reason that there will be a lot of Jython-made, dynamically-generated classes up for garbage collection. See, I noticed that if I tried to take a snapshot of my app before I run any Jython in it, there was never a problem.
*** from mailing list: I then tried the suggestion of thurka to disable loaded classes garbage collection via -Xnoclassgc (see the log for issue 62919). So no class that was ever loaded via the JVM is garbage collected. Now it works fine. Hallelujah! When I try to get a snapshot without -Xnoclassgc the following message is printed into the console from the Profiler Agent: Profiler Agent Warning: Invalid declaringClass obtained from jmethodID Profiler Agent Warning: mId = 05CBDFDA, *mId = 0 Profiler Agent Warning: dCl = 06696344, *dCl = 1379252248 This is a consistent picture. The application I am profiling emitts a lot of dynamically generated classes and this seems to be the problem. When trying to get a stack trace and trying to get a method signature from a jmethodID for a dynamically emitted class which has been gargabe collected there seems to lie the problem (I am completely speculating because I really don't know what happens behing the scenes). Maybe JVMTI does not handle dynamically generated classes rightly? What does the Profiling Agent do when a "normal" class is garbage collected but later on a snapshot needs to be taken?
We should try to solve it in NetBeans Profiler 6.0.
Reproduced with JDK 1.5.0_06-b05 and JDK 1.5.0_12-b04. Was not able to reproduce with 1.6.0_02-b06. Steps to reproduce with JDK 1.5.0 - Use NetBeans IDE Dev (Build 200708270000) (Java EE) with clean userdir, having specified JDK 1.5 and removed "-J-XX:+UseConcMarkSweepGC -J-XX:+CMSClassUnloadingEnabled -J-XX:+CMSPermGenSweepingEnabled" flags - Perform Calibration - Run another instance of IDE with customized clean userdir and parameters for direct attach like in the following command "C:\Program Files\NetBeans 6.0 200708270000\bin\nb.exe" --userdir C:\Work\Temp\NBHome "-J-agentpath:C:\Program Files\NetBeans 6.0 200708270000\profiler2\lib\deployed\jdk15\windows\profilerinterface.dll=C:\Program Files\NetBeans 6.0 200708270000\profiler2\lib,5140" - Perform Attach Profiler action for External Application Memory Allocation Profiling, each 100 objects, Record stack traces, Local Direct Attach to Application. - Open VM Telemetry Overview window - Wait till the profiled IDE fully start - In profiled IDE invoke New Project - Select Enterpise Category, Enterprise Application - Click Next - Click Finish - Switch to profiler and perform take snapshot operations consequently until new created project is fully opened in profiled IDE (close generated snapshots to avoid OutOfMemoryError) - RESULT: Profiled IDE crashes with the following ... Profiler Agent Warning: Invalid declaringClass obtained from jmethodID Profiler Agent Warning: mId = 0CFEBDAA, *mId = 527741 Profiler Agent Warning: dCl = 02CF8DDC, *dCl = 570403152 # # An unexpected error has been detected by HotSpot Virtual Machine: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6d7dcf39, pid=2600, tid=1436 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_12-b04 mixed mode) # Problematic frame: # V [jvm.dll+0x9cf39] # # An error report file with more information is saved as hs_err_pid2600.log ...
Created an attachment (id=47729) [details] Profiled Application output with JDK 1.5.0_06-b05
Created an attachment (id=47730) [details] Error report with JDK 1.5.0_06-b05
Created an attachment (id=47731) [details] Profiler message.log with JDK 1.5.0_06-b05
Created an attachment (id=47732) [details] Profiled NetBeans messages.log with JDK 1.5.0_06-b05
Created an attachment (id=47733) [details] Profiled Application output with JDK 1.5.0_12-b04
Created an attachment (id=47734) [details] Error report with JDK 1.5.0_12-b04
Created an attachment (id=47735) [details] Profiler message.log with JDK 1.5.0_12-b04
*** Issue 120402 has been marked as a duplicate of this issue. ***
*** Issue 120908 has been marked as a duplicate of this issue. ***
Changing target milestone to dev, since NetBeans 6.0 is in high resistance mode.
*** Issue 128637 has been marked as a duplicate of this issue. ***
Requesting waiver. This bug is highly dependent on the JVM used. A viable workaround exists - use "-Xnoclassgc" option to avoid this problem.
*** Issue 149848 has been marked as a duplicate of this issue. ***
Should be fixed in profiler-main comparing with https://thurka:***@hg.netbeans.org/profiler-main searching for changes changeset: 127893:da8a184e6af0 user: Tomas Hurka <thurka@netbeans.org> date: Tue Apr 21 15:47:22 2009 +0200 summary: bugfix #62919, avoid System.gc() in getMethodNamesForJMethodIds() - it does not help to prevent JVM crash changeset: 127894:ffa56307b7b3 user: Tomas Hurka <thurka@netbeans.org> date: Tue Apr 21 15:51:25 2009 +0200 summary: bugfix #62919, do not invoke client.getMethodNamesForJMethodIds() in MemoryResultsSnapshot - method signatures for methodIds are already available in JMethodIdTable.getDefault() - this prevents calling getMethodNamesForJMethodIds for methods, which were garbage collected a long time ago and which can cause JVM crash
Integrated into 'main-golden', will be available in build *200904250201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/da8a184e6af0 User: Tomas Hurka <thurka@netbeans.org> Log: bugfix #62919, avoid System.gc() in getMethodNamesForJMethodIds() - it does not help to prevent JVM crash
verified on both scenarios
