Created attachment 116892 [details]
stacktrace

I think I see the problem. libs.findbugs/nbproject/project.properties fails to copy JARs to extra/modules/ext/, e.g.

release.external/findbugs-2.0.0.jar=modules/ext/findbugs-2.0.0.jar

so running it from source does not work, even though installing from an NBM does. (<makenbm> automatically excludes $f when $f.external is included in the fileset, so it is safe to copy the external JAR to the output cluster even when it is not wanted in the *.nbm.)


BTW the various *-license.txt files should not use a Files header unless they are actually covering >1 file. See DevFaqExternalLibraries [1]. Some of the Files header are wrong anyway, e.g. "Files: jsr305-2.0.0".


Also note that "SHA1:..." is not a recognized header for *.external files. Only CRC[32] is checked.


[1] http://wiki.netbeans.org/DevFaqExternalLibraries

Errors like the ones shows in the log are being thrown during tests when the cluster config includes stableuc, and may be contributing to VM crashes in ValidateLayerConsistencyTest and the like.

Very well, I expect the harness&builders to handle this properly and *never* show the jars to the user without a proper license:
http://hg.netbeans.org/jet-main/rev/4dfc80bc3fed

Anyway, I do not think I have seen a related a VM crash - which build failed with a VM crash? Please file bug with results of your investigation against JVM for it.

The nbms-and-javadoc build #8842's ValidateLayerConsistencyTest failed probably because of:
java.lang.ClassCircularityError: org/netbeans/core/NotifyExcPanel
	at org.netbeans.core.NbErrorManager.publish(NbErrorManager.java:94)
	at org.netbeans.core.startup.TopLogging$LookupDel.publish(TopLogging.java:955)
	at java.util.logging.Logger.log(Logger.java:478)
	at java.util.logging.Logger.doLog(Logger.java:500)
	at java.util.logging.Logger.log(Logger.java:589)
	at org.netbeans.JarClassLoader$JarSource.opened(JarClassLoader.java:757)
	at org.netbeans.JarClassLoader$JarSource$1.call(JarClassLoader.java:501)
	at org.netbeans.JarClassLoader$JarSource$1.call(JarClassLoader.java:492)
	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:522)
Caused: java.io.IOException
	at org.netbeans.JarClassLoader$JarSource.callGet(JarClassLoader.java:706)
	at org.netbeans.JarClassLoader$JarSource.getJarFile(JarClassLoader.java:523)
	at org.netbeans.JarClassLoader$JarSource.resource(JarClassLoader.java:558)
	at org.netbeans.Archive.getData(Archive.java:206)
	at org.netbeans.JarClassLoader$JarSource.readClass(JarClassLoader.java:548)
[catch] at org.netbeans.JarClassLoader$Source.getClassData(JarClassLoader.java:351)
	at org.netbeans.JarClassLoader.doLoadClass(JarClassLoader.java:227)
	at org.netbeans.ProxyClassLoader.selfLoadClass(ProxyClassLoader.java:300)
	at org.netbeans.ProxyClassLoader.loadClass(ProxyClassLoader.java:227)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
	at org.netbeans.core.NbErrorManager.publish(NbErrorManager.java:94)
	at org.netbeans.core.startup.TopLogging$LookupDel.publish(TopLogging.java:955)
	at java.util.logging.Logger.log(Logger.java:478)
	at java.util.logging.Logger.doLog(Logger.java:500)
	at java.util.logging.Logger.log(Logger.java:589)
	at org.netbeans.JarClassLoader$JarSource.opened(JarClassLoader.java:757)
	at org.netbeans.JarClassLoader$JarSource$1.call(JarClassLoader.java:501)
	at org.netbeans.JarClassLoader$JarSource$1.call(JarClassLoader.java:492)
	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:522)
	at org.netbeans.JarClassLoader$JarSource.resource(JarClassLoader.java:558)
	at org.netbeans.Archive.getData(Archive.java:206)
	at org.netbeans.JarClassLoader$JarSource.doGetResource(JarClassLoader.java:536)
	at org.netbeans.JarClassLoader$Source.getResource(JarClassLoader.java:339)
	at org.netbeans.JarClassLoader.findResources(JarClassLoader.java:286)
	at org.netbeans.ProxyClassLoader.getResourcesImpl(ProxyClassLoader.java:467)
	at org.netbeans.ModuleManager$SystemClassLoader.getResourcesImpl(ModuleManager.java:569)
	at org.netbeans.ProxyClassLoader.getResources(ProxyClassLoader.java:427)
	at org.openide.util.lookup.MetaInfServicesLookup.search(MetaInfServicesLookup.java:198)
	at org.openide.util.lookup.MetaInfServicesLookup.beforeLookup(MetaInfServicesLookup.java:159)
	at org.openide.util.lookup.AbstractLookup.lookupItem(AbstractLookup.java:426)
	at org.openide.util.lookup.AbstractLookup.lookup(AbstractLookup.java:420)
	at org.netbeans.NetigsoFramework.turnOn(NetigsoFramework.java:209)
	at org.netbeans.ModuleManager.enable(ModuleManager.java:1097)
	at org.netbeans.ModuleManager.enable(ModuleManager.java:916)
	at org.netbeans.core.startup.ModuleList.installNew(ModuleList.java:340)
	at org.netbeans.core.startup.ModuleList.trigger(ModuleList.java:276)
	at org.netbeans.core.startup.ModuleSystem.restore(ModuleSystem.java:294)
	at org.netbeans.core.startup.Main.getModuleSystem(Main.java:169)
	at org.netbeans.core.startup.Main.start(Main.java:305)
	at org.netbeans.core.startup.TopThreadGroup.run(TopThreadGroup.java:123)
	at java.lang.Thread.run(Thread.java:662)

If that is what was referred to as a VM crash, I suggest to fix the NB module system not to be so fragile to cause P1s filed against module/client code.

Integrated into 'main-golden', will be available in build *201203210400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/4dfc80bc3fed
User: Jan Lahoda <jlahoda@netbeans.org>
Log: #209762: according to jglick, using release.** is safe, and it is duty of the harness to ensure that these do not appear on inappropriate places

(In reply to comment #4)
> I expect the harness&builders to handle this properly

You can run the nbm target and see for yourself that just the *.external files are included.


> java.lang.ClassCircularityError: org/netbeans/core/NotifyExcPanel
>     at org.netbeans.core.NbErrorManager.publish(NbErrorManager.java:94)

Right, that is what I am talking about.

> If that is what was referred to as a VM crash

No, that is just an exception; the HotSpot crash followed, and I am guessing it was triggered by the CCE. Unfortunately I am unable to reproduce the CCE, or I would investigate further.


(In reply to comment #2)
> "SHA1:..." is not a recognized header for *.external files.

I guess you missed this note.


BTW you can consider deleting the special license.file handling in build.xml; as per DevFaqExternalLibraries one will be generated automatically according to the external/*-license.txt you are actually using. It will of course not be formatted exactly the same way.

(In reply to comment #6)
> > java.lang.ClassCircularityError: org/netbeans/core/NotifyExcPanel
> >     at org.netbeans.core.NbErrorManager.publish(NbErrorManager.java:94)
> 
> Right, that is what I am talking about.
> 
> > If that is what was referred to as a VM crash
> 
> No, that is just an exception; the HotSpot crash followed, and I am guessing it
> was triggered by the CCE. Unfortunately I am unable to reproduce the CCE, or I
> would investigate further.

So a bug in the NB module system was used as an excuse to file a P1 bug against the FB integration and is going to be ignored.

> (In reply to comment #2)
> > "SHA1:..." is not a recognized header for *.external files.
> 
> I guess you missed this note.

I did not. I know it is not used. What problems does it cause? Shouldn't these problems be fixed at the place they occur rather than workarounded by deleting the line from the .external files?

It also highlights the question: why CRC32 if we were already using SHA1 sum for very similar usecase? Why are we using two different checksums? That appears to be unnecessarily confusing.

(In reply to comment #7)
> So a bug in the NB module system

Or JRE; still TBD.

> was used as an excuse to file a P1 bug

No, actually this was filed before then, since

  ant -f findbugs run

did not work. Crashes in tests were noticed secondarily. Either way it is good this is fixed now.

> I know it is not used. What problems does it cause?

Confusion. It is a bad idea to have lines in source code which look like they do something but in fact do nothing. Other people will copy the idiom expecting it to work and waste time figuring out why it does not until they read the API doc for bug #195041.

> why CRC32 if we were already using SHA1 sum for very similar usecase?

Auto Update uses CRC-32 only. It would be nice to switch to SHA-1 for all purposes in AU, of course; this would be an API RFE in platform.