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.

Bug 183696 - Never ending exceptions in messages.log
Summary: Never ending exceptions in messages.log
Status: RESOLVED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Module System (show other bugs)
Version: 6.x
Hardware: PC Linux
: P3 normal (vote)
Assignee: Jaroslav Tulach
URL:
Keywords:
: 185046 190302 (view as bug list)
Depends on: 185135
Blocks:
  Show dependency tree
 
Reported: 2010-04-08 10:16 UTC by Maros Sandor
Modified: 2010-09-27 20:28 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Repeating exception stack trace (1.99 KB, text/plain)
2010-04-08 10:17 UTC, Maros Sandor
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Maros Sandor 2010-04-08 10:16:41 UTC
Messages log file eventually filled all my free disk space (112 GB) with the attached exception repeating over and over several times per second. I checked the file it is referring to and it exists and it is valid.
Comment 1 Maros Sandor 2010-04-08 10:17:19 UTC
Created attachment 96883 [details]
Repeating exception stack trace
Comment 2 Jesse Glick 2010-04-08 13:02:58 UTC
I can tune the logging to stop printing duplicates: core-main #9f4af4a727ae

As to the actual cause, I am not sure - ZipExceptions are thrown with no useful diagnostics, and the JRE team has been resistant to changing this, purportedly for security reasons. My best guess is that you have run out of file descriptors:

http://wiki.netbeans.org/FaqScanningAndIndexingPerformanceHints#File_Descriptor_Limit_On_UNIX

You can also try setting org.netbeans.JarClassLoader.limit_fd to something greater than the default of 300. When the system FD limit is low, tuning this is tricky because it has to be high enough to avoid closing and reopening JARs, while low enough to not run out of descriptors especially during classpath scanning.

Yarda knows more about the cache system and might be able to diagnose this exception.
Comment 3 Jaroslav Tulach 2010-04-13 06:29:16 UTC
Might be improved by core-main#13ea26c1e814
Comment 4 Jesse Glick 2010-04-13 17:38:43 UTC
Backing out in core-main #7818933f12df since this causes ArchiveTest to fail due to a deadlock:

Testsuite: org.netbeans.ArchiveTest
Apr 13, 2010 1:30:53 PM org.netbeans.JarClassLoader$JarSource$1 call
WARNING: Error opening /space/src/nb/main/o.n.bootstrap/build/test/unit/work/o.n.A/testWrongClassPathElement/install/platform/modules/ext/non-existent.jar retry: 1
java.util.zip.ZipException: error in opening zip file
        at java.util.zip.ZipFile.open(Native Method)
        at java.util.zip.ZipFile.<init>(ZipFile.java:114)
        at java.util.jar.JarFile.<init>(JarFile.java:133)
        at java.util.jar.JarFile.<init>(JarFile.java:112)
        at org.netbeans.JarClassLoader$JarSource$1.call(JarClassLoader.java:465)
        at org.netbeans.JarClassLoader$JarSource$1.call(JarClassLoader.java:458)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at org.netbeans.JarClassLoader$JarSource.getJarFile(JarClassLoader.java:487)
[...]

Full thread dump Java HotSpot(TM) Server VM (16.0-b13 mixed mode):
[...]
"main" prio=10 tid=0x08f71000 nid=0x509a waiting on condition [0xb6b4e000]
   java.lang.Thread.State: WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0xad44e070> (a java.util.concurrent.FutureTask$Sync)
        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:905)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1217)
        at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:218)
        at java.util.concurrent.FutureTask.get(FutureTask.java:83)
        at org.netbeans.JarClassLoader$JarSource.callGet(JarClassLoader.java:647)
        at org.netbeans.JarClassLoader$JarSource.doCloseJar(JarClassLoader.java:667)
        - locked <0xad442c38> (a java.util.HashMap)
        at org.netbeans.JarClassLoader$JarSource.access$000(JarClassLoader.java:391)
        at org.netbeans.JarClassLoader$JarSource$1.call(JarClassLoader.java:475)
        at org.netbeans.JarClassLoader$JarSource$1.call(JarClassLoader.java:458)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at org.netbeans.JarClassLoader$JarSource.getJarFile(JarClassLoader.java:487)
[...]
Comment 5 Quality Engineering 2010-04-14 04:42:13 UTC
Integrated into 'main-golden', will be available in build *201004140201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/13ea26c1e814
User: Jaroslav Tulach <jtulach@netbeans.org>
Log: #183696: Try to close few JARs to workaround the I/O handles limit
Comment 6 Jaroslav Tulach 2010-04-23 11:07:05 UTC
Let's try again: core-main#c53fe6198271
Comment 7 Quality Engineering 2010-04-24 05:29:06 UTC
Integrated into 'main-golden', will be available in build *201004240200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/6b9d573f618e
User: Jaroslav Tulach <jtulach@netbeans.org>
Log: Let's try once again to fix #183696 by refining 13ea26c1e814.
Comment 8 Jaroslav Tulach 2010-04-27 15:27:18 UTC
*** Bug 185046 has been marked as a duplicate of this bug. ***
Comment 9 Jaroslav Tulach 2010-09-27 20:28:15 UTC
*** Bug 190302 has been marked as a duplicate of this bug. ***