Bug 219962 - Strange things happens
Strange things happens
Status: RESOLVED FIXED
Product: debugger
Classification: Unclassified
Component: Java
7.3
All All
: P2 (vote)
: 7.3
Assigned To: Martin Entlicher
issues@debugger
http://netbeans.org/projects/profiler...
EXCEPTIONS_REPORT
: PERFORMANCE
: 196492 218984 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-12 06:29 UTC by Chiana
Modified: 2013-06-20 16:09 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
stacktrace (2.42 KB, text/plain)
2012-10-12 06:29 UTC, Chiana
Details
Path to GC root (1.50 KB, text/plain)
2012-10-31 17:10 UTC, Tomas Hurka
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Chiana 2012-10-12 06:29:46 UTC
Build: NetBeans IDE Dev (Build 201210110002)
VM: Java HotSpot(TM) 64-Bit Server VM, 23.3-b01, Java(TM) SE Runtime Environment, 1.7.0_07-b11
OS: Windows 7

User Comments:
Chiana: This is the result of trying a new package for the first time, one thing I did notice is that none of the errors occuring actually exist. My guess is that this is caused by the debugger. It had similar behaviour as a previous error I reported where the debugger gradually went into some uncertain state when trying to expand a few tables, that is the system went into really high gear requiring it to actually use it's cooling fan, also noted it was using exessive amount of ram (approx 4 Gig).
Will now reboot and then try this again




Stacktrace: 
java.lang.OutOfMemoryError: GC overhead limit exceeded
   at com.sun.tools.javac.code.Scope.<init>(Scope.java:113)
   at com.sun.tools.javac.code.Scope$ErrorScope.<init>(Scope.java:737)
   at com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:2212)
   at com.sun.tools.javac.code.Symbol.complete(Symbol.java:422)
   at com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:833)
   at com.sun.tools.javac.jvm.ClassReader.loadClass(ClassReader.java:2413)
Comment 1 Chiana 2012-10-12 06:29:48 UTC
Created attachment 125821 [details]
stacktrace
Comment 2 Chiana 2012-10-12 06:47:57 UTC
So, I did find the cause of this. It was actually an assignment to a null pointer. Examin the following

private ThreadData[] pool=new ThreadData[INITIAL_POOL_SIZE];

and then in the constructor

for (int i=0;i<INITIAL_POOL_SIZE;i++) {
  pool[i].thread=new WorkerThread(i);
  pool[i].thread.start();
}
As you can see I did forgot to create the "pool[i]", this is an error, but then again, it should not cause 5-6 "just not related" exceptions from the debugger.
Comment 3 Dusan Balek 2012-10-12 07:16:57 UTC
Could you please post the generated heap dump? Thanks.
Comment 4 Chiana 2012-10-12 07:32:22 UTC
I tried to reproduce this with the following class that is similar in structure but somewhat smaller (B-) to the one that fails.
public static class Debug {
    static Debug d=new Debug();
    public static void test() {
      
    }
    private class LInt {
      Thread a;
    }
    private LInt[] I=new LInt[10];
    
    Debug(){
      for (int i=0;i<10;i++) {
        I[i].a=new Thread(new Runnable() {

          @Override
          public void run() {
          }
        });
        I[i].a.start();
      }
    }
  }
 
and the calling Debug.test() to start it, but it works as it should.
The heapdumps are on it's way, currently beeing compressed as it is a big chunk of data.
Comment 5 Chiana 2012-10-12 09:35:02 UTC
Heapdump delayed. Will post link as soon as available.
Comment 6 Chiana 2012-10-15 12:57:42 UTC
Dumps uploaded to hudson...
Comment 7 Dusan Balek 2012-10-18 12:48:56 UTC
Unfortunately, it seems that your upload was not successful :-(

Started by user Chiana
Building remotely on upload-node
Copying file to ./heap_dump
FATAL: channel is already closed
hudson.remoting.ChannelClosedException: channel is already closed
	at hudson.remoting.Channel.send(Channel.java:483)
	at hudson.remoting.ProxyOutputStream.doClose(ProxyOutputStream.java:183)
	at hudson.remoting.ProxyOutputStream.close(ProxyOutputStream.java:147)
	at hudson.remoting.RemoteOutputStream.close(RemoteOutputStream.java:118)
	at hudson.FilePath.copyFrom(FilePath.java:707)
	at hudson.model.FileParameterValue$1.setUp(FileParameterValue.java:109)
	at hudson.model.Build$RunnerImpl.doRun(Build.java:131)
	at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:429)
	at hudson.model.Run.run(Run.java:1367)
	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
	at hudson.model.ResourceController.execute(ResourceController.java:88)
	at hudson.model.Executor.run(Executor.java:145)
Caused by: java.io.IOException: Unexpected termination of the channel
	at hudson.remoting.Channel$ReaderThread.run(Channel.java:1030)
Caused by: java.io.EOFException
	at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2553)
	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1296)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350)
	at hudson.remoting.Channel$ReaderThread.run(Channel.java:1024)

Is it possible to upload it to some alternative location? Thanks and sorry for an inconvenience.
Comment 8 Chiana 2012-10-24 11:20:53 UTC
I think it succeeded this time, build #79 in hudson.
Started by user anonymous
Building remotely on upload-node
Copying file to ./heap_dump
[upload] $ /bin/sh -xe /tmp/hudson1020646864153618562.sh
+ mv heap_dump heap_dump.zip
+ set +e
+ zip -qT heap_dump.zip
+ ERROR_CODE=3
+ set -e
+ '[' 3 '!=' 0 ']'
+ mv heap_dump.zip heap_dump
+ zip -m heap_dump.zip heap_dump
  adding: heap_dump (deflated 0%)
++ md5sum heap_dump.zip
++ cut -d ' ' -f1
+ MD5PRINT=e73c135f4bb0b8221beebdc20189ff5d
+ mv heap_dump.zip 219962_2012-10-24_04-06-40_e73c135f4bb0b8221beebdc20189ff5d.zip
[DEBUG] Skipping watched dependency update; build not configured with trigger: upload #79
Finished: SUCCESS
Comment 9 Tomas Hurka 2012-10-30 17:40:41 UTC
Heap dump is available at <http://netbeans.org/projects/profiler/downloads/download/Heapdumps/heapdump-219962.zip>
Comment 10 Petr Cyhelsky 2012-10-31 16:37:55 UTC
*** Bug 218984 has been marked as a duplicate of this bug. ***
Comment 11 Tomas Hurka 2012-10-31 17:08:10 UTC
There are 8 instances of  SymTab.
Instance #1, #2, #3, #4, #6, #7 are referenced from org.netbeans.modules.debugger.jpda.projects.EditorContextImpl. See attached path to GC root. Re-assiging to debugger.
Comment 12 Tomas Hurka 2012-10-31 17:10:33 UTC
Created attachment 126882 [details]
Path to GC root
Comment 13 Martin Entlicher 2012-11-12 16:57:11 UTC
There are three staled entries in the WeakHashMap. The length of the associated ReferenceQueue is 3. We need to expunge the staled entries somehow, since WeakHashMap does not do it automatically :-(
Comment 14 Martin Entlicher 2012-11-13 16:32:35 UTC
Fixed by changeset:   239791:9bb864527e30
http://hg.netbeans.org/core-main/rev/9bb864527e30
Comment 15 Quality Engineering 2012-11-15 02:46:02 UTC
Integrated into 'main-golden', will be available in build *201211150001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/9bb864527e30
User: mentlicher@netbeans.org
Log: #219962: An active implementation of weak hash map is used to hold the source handles. The entries are removed automatically as soon as they are freed by GC.
Comment 16 Jan Lahoda 2013-06-20 16:09:39 UTC
*** Bug 196492 has been marked as a duplicate of this bug. ***


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