Bug 62919

Summary: EXCEPTION_ACCESS_VIOLATION in getMethodNamesForJMethodIds
Product: profiler Reporter: Jiri Sedlacek <jis>
Component: BaseAssignee: Tomas Hurka <thurka>
Status: VERIFIED FIXED QA Contact: issues <issues.netbeans.org>
Priority: P2 CC: bleonard, gsporar, pbouche
Version: 5.xKeywords: RELNOTE, VISUALVM
Target Milestone: 6.x   
Hardware: All   
OS: All   
Issue Type: DEFECT Exception Report:
Attachments: error log
error log
error log
Fatal Error Log (Windows)
hs_err_pid5776.log occurred during get snapshot (memory)
RC1 Crash, under JDK 1.5.0_06
Yet another.... :(
SIGSEGV on Linux of same crash, with 1.5.0_08-b03
Profiled Application output with JDK 1.5.0_06-b05
Error report with JDK 1.5.0_06-b05
Profiler message.log with JDK 1.5.0_06-b05
Profiled NetBeans messages.log with JDK 1.5.0_06-b05
Profiled Application output with JDK 1.5.0_12-b04
Error report with JDK 1.5.0_12-b04
Profiler message.log with JDK 1.5.0_12-b04

Description Jiri Sedlacek 2005-08-24 09:34:22 UTC
Reported by the user:

Unexpected Signal : 10 occurred at PC=0xFEF21754
Function=[Unknown. Nearest: JVM_RaiseSignal+0x53040]
Current Java thread:
        at com.sun.tools.profiler.server.ProfilerServer.handleClientCommand
        at com.sun.tools.profiler.server.ProfilerServer.listenToClient
        at com.sun.tools.profiler.server.ProfilerServer.run
Dynamic libraries:
0x10000         /xauser1.v4902/xacct/smm/mfeldman/profiler/jfluid-
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-
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-
0xfebd0000      /xauser1.v4902/xacct/smm/mfeldman/profiler/jfluid-
0xfeb90000      /xauser1.v4902/xacct/smm/mfeldman/profiler/jfluid-
0xff040000      /xauser1.v4902/xacct/smm/mfeldman/profiler/jfluid-
0xfeb00000      /xauser1.v4902/xacct/smm/mfeldman/profiler/lib/deployed/jdk142/s
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-
0xfe820000      /xauser1.v4902/xacct/smm/mfeldman/xacct/Shared/libxacct_native_s
0xfe2e0000      /usr/ucblib/libucb.so.1
0xfe2b0000      /usr/lib/libelf.so.1
0xb3a80000      /xauser1.v4902/xacct/smm/mfeldman/xacct/Shared/libdb_java-3.3-
0xfbea0000      /usr/lib/libresolv.so.2
Heap at VM Abort:
 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 
# Please refer to the file for further information.
JVM_OnLoad called...
Comment 1 Jiri Sedlacek 2005-08-24 09:35:10 UTC
Created attachment 24171 [details]
error log
Comment 2 Jiri Sedlacek 2005-08-24 09:35:41 UTC
Created attachment 24172 [details]
error log
Comment 3 Jiri Sedlacek 2005-08-24 09:36:18 UTC
Created attachment 24173 [details]
error log
Comment 4 iformanek 2005-10-25 11:34:26 UTC
*** Issue 64770 has been marked as a duplicate of this issue. ***
Comment 5 iformanek 2005-10-25 11:34:36 UTC
*** Issue 65711 has been marked as a duplicate of this issue. ***
Comment 6 iformanek 2005-10-25 11:38:42 UTC
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 
3. click on the Basic Arithmetic example in the browser
4. click Take Snapshot
Comment 7 iformanek 2005-10-25 11:39:31 UTC
Created attachment 26309 [details]
Fatal Error Log (Windows)
Comment 8 iformanek 2005-10-26 13:44:19 UTC
*** Issue 62793 has been marked as a duplicate of this issue. ***
Comment 9 iformanek 2005-11-23 12:17:06 UTC
*** Issue 68295 has been marked as a duplicate of this issue. ***
Comment 10 iformanek 2006-01-03 14:00:24 UTC
Very probably fixed in M12
Comment 11 jchristi 2006-01-16 19:24:10 UTC
Got this using RC1.

hotspot crash file attached.
Comment 12 jchristi 2006-01-16 19:25:51 UTC
Created attachment 28411 [details]
hs_err_pid5776.log occurred during get snapshot (memory)
Comment 13 jchristi 2006-01-17 05:30:31 UTC
Created attachment 28414 [details]
RC1 Crash, under JDK 1.5.0_06
Comment 14 Tomas Hurka 2006-01-17 14:31:39 UTC
To jchristi:
We were not able to reproduce it. Are you able to reproduce it? Can you provide steps how to reproduce it? 
Comment 15 jchristi 2006-01-17 15:11:37 UTC
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.
Comment 16 jchristi 2006-01-17 19:55:03 UTC
Created attachment 28424 [details]
Comment 17 jchristi 2006-01-17 20:53:23 UTC
Created attachment 28425 [details]
Yet another.... :(
Comment 18 Tomas Hurka 2006-01-18 10:21:45 UTC
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.  
Comment 19 Tomas Hurka 2006-01-18 10:51:53 UTC
One additional note. Can you try to run your application with 
to see if it fixes the issue or not. Thanks.
Comment 20 Tomas Hurka 2006-09-14 12:02:29 UTC
*** Issue 84655 has been marked as a duplicate of this issue. ***
Comment 21 jchristi 2006-09-14 15:20:30 UTC
Created attachment 33952 [details]
SIGSEGV on Linux of same crash, with 1.5.0_08-b03
Comment 22 Tomas Hurka 2006-09-15 09:27:35 UTC
*** Issue 84112 has been marked as a duplicate of this issue. ***
Comment 23 Tomas Hurka 2006-09-26 10:35:48 UTC
*** Issue 85679 has been marked as a duplicate of this issue. ***
Comment 24 Jiri Sedlacek 2006-11-28 07:26:44 UTC
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.
Comment 25 pbouche 2007-03-29 12:52:38 UTC
*** 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?
Comment 26 Tomas Hurka 2007-03-29 13:57:56 UTC
We should try to solve it in NetBeans Profiler 6.0. 
Comment 27 Alexander Kouznetsov 2007-08-29 17:21:52 UTC
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
- 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
Comment 28 Alexander Kouznetsov 2007-08-29 17:23:51 UTC
Created attachment 47729 [details]
Profiled Application output with JDK 1.5.0_06-b05
Comment 29 Alexander Kouznetsov 2007-08-29 17:24:30 UTC
Created attachment 47730 [details]
Error report with JDK 1.5.0_06-b05
Comment 30 Alexander Kouznetsov 2007-08-29 17:25:02 UTC
Created attachment 47731 [details]
Profiler message.log with JDK 1.5.0_06-b05
Comment 31 Alexander Kouznetsov 2007-08-29 17:25:42 UTC
Created attachment 47732 [details]
Profiled NetBeans messages.log with JDK 1.5.0_06-b05
Comment 32 Alexander Kouznetsov 2007-08-29 17:27:09 UTC
Created attachment 47733 [details]
Profiled Application output with JDK 1.5.0_12-b04
Comment 33 Alexander Kouznetsov 2007-08-29 17:27:54 UTC
Created attachment 47734 [details]
Error report with JDK 1.5.0_12-b04
Comment 34 Alexander Kouznetsov 2007-08-29 17:28:32 UTC
Created attachment 47735 [details]
Profiler message.log with JDK 1.5.0_12-b04
Comment 35 Jiri Sedlacek 2007-10-30 17:02:56 UTC
*** Issue 120402 has been marked as a duplicate of this issue. ***
Comment 36 joe_h5 2007-11-02 15:34:59 UTC
*** Issue 120908 has been marked as a duplicate of this issue. ***
Comment 37 Tomas Hurka 2007-11-07 10:35:08 UTC
Changing target milestone to dev, since NetBeans 6.0 is in high resistance mode.
Comment 38 Tomas Hurka 2008-02-29 11:21:00 UTC
*** Issue 128637 has been marked as a duplicate of this issue. ***
Comment 39 J Bachorik 2008-03-25 11:06:59 UTC
Requesting waiver.
This bug is highly dependent on the JVM used. 
A viable workaround exists - use "-Xnoclassgc" option to avoid this problem.
Comment 40 Tomas Hurka 2008-10-11 08:51:40 UTC
*** Issue 149848 has been marked as a duplicate of this issue. ***
Comment 41 Tomas Hurka 2009-04-21 14:53:22 UTC
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

Comment 42 Quality Engineering 2009-04-25 07:30:17 UTC
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
Comment 43 matusdekanek 2009-06-09 09:27:02 UTC
verified on both scenarios
By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo