Bug 232667 - Switching between Java forms, Source, Design, and History views causes "coupling errors" and dump files
Switching between Java forms, Source, Design, and History views causes "coupl...
Status: NEW
Product: java
Classification: Unclassified
Component: Source
7.4
All All
: P2 (vote)
: 8.0
Assigned To: Svata Dedic
issues@java
: REGRESSION
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-14 01:28 UTC by MackSix
Modified: 2014-04-09 20:41 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
:


Attachments
log directory (zip) (219.24 KB, application/zip)
2013-07-14 01:28 UTC, MackSix
Details

Note You need to log in before you can comment on or make changes to this bug.
Description MackSix 2013-07-14 01:28:06 UTC
Created attachment 137084 [details]
log directory (zip)

Any Java GUI Forms open in the Editor will cause a "coupling error" and Windows.class.dump files in the log directory. This also happens when switching between Source, Designer and History views. 

See attached log directory in zip file for log file and dump files.

This does not occur in 7.3.1 so it is regression.

This will take up a lot of hard drive space in a short time if someone is working with the GUI Editor.

Product Version: NetBeans IDE 7.4 Beta (Build 201307092200)
Java: 1.7.0_25; Java HotSpot(TM) 64-Bit Server VM 23.25-b01
Runtime: Java(TM) SE Runtime Environment 1.7.0_25-b16
System: Windows 7 version 6.1 running on amd64; Cp1252; en_US (nb)

Product Version: NetBeans IDE Dev (Build 201307122300)
Java: 1.7.0_25; Java HotSpot(TM) 64-Bit Server VM 23.25-b01
Runtime: Java(TM) SE Runtime Environment 1.7.0_25-b16
System: Windows 7 version 6.1 running on amd64; Cp1252; en_US (nb)
Comment 1 Jan Lahoda 2013-07-14 12:42:11 UTC
My first though when I saw this was that the IDE's quality must be totally awesome if just writing whatever to the log directory is a filled as P1.

Anyway, even if I would agree that regression == P1 (which, frankly, I don't), I somehow fail to see how this fits the definition ("Regression in functionality or performance"). I.e. what *functionality* regressed? Any measurement of something slowing down? Regarding eating up disk space, there is a limit on the number of the dump files for each name, so the maximum disk space consumed in this case is about 40MB.

Overall, with the recent outbreak of bugs that basically say "there is something in var/log or messages.log", I am starting to worry about testability of the IDE (and due to this about the long-term quality). Generally, the logs are intended to help debugging a problem, but may not themselves present a real user visible problem, and may sometimes be produced in a situation that is ultimately unfixable. So, if the logs as such will continue to be filled as high priority bugs, I think it is likely that the logs will be silenced, which will make testing way harder: a reproducible test case will be required in many more cases than its now. Interestingly, not even this report provides correct steps to reproduce (at very least, by far not every form produces the dump for me - create a new "empty" JPanel form, for example).

Also, there is at most one Window.dump produced for me switching between the tabs. Producing more dumps may (or may not) be sign of a more serious problem, but is likely to remain unfixed, unless I can reproduce.
Comment 2 MackSix 2013-07-14 13:22:15 UTC
It should read: 

Any Java GUI Forms open in the Editor and Clicking the tabs to switch between forms in the editor will cause a "coupling error" and
Windows.class.dump files in the log directory. This also happens when switching
between Source, Designer and History views.

I may have inadvertently hit some keys or something that removed part of the paragraph.
Comment 3 Jan Lahoda 2013-08-30 08:11:17 UTC
Caused by current use of ct.sym - the coupling does not match the unresolvable types correctly.
Comment 4 theshadow27 2014-04-09 20:03:13 UTC
Changing to P3: In 8.0, and 201404090001, on stock settings / fresh userdir, I get a Window.class.dump for each GUI Builder Window opened, and changing between source and design. Alone, this is not serious, but it does prevent other dump files from being written when the var folder fills up (which might hide other issues). It is not P4. 

If this is a known issue w/JDK 1.7.0 src.zip, there should be an explicit test to see if 'java.awt.Window' is being dumped, and redirect the exception to messages.log, to prevent the 153kb from being written to disk many times per second.


For the record, the error is always the same:

Coupling error:
class file jar:file:/Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home/lib/ct.sym!/META-INF/sym/rt.jar/java/awt/Window.class
source file jar:file:/Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home/src.zip!/java/awt/Window.java

. . . entire source code of Window.class . . .

----- Trees: -------------------------------------------------------
VARIABLE: allWindows
METHOD: getAllWindows
METHOD: getAllUnblockedWindows
----- Stack trace: ---------------------------------------------
com.sun.tools.javac.util.CouplingAbort
	at org.netbeans.modules.java.source.TreeLoader.loadTreeFor(TreeLoader.java:225)
	at com.sun.tools.javac.code.Symbol$ParamSymbol.getSimpleName(Symbol.java:1341)
	at com.sun.tools.javac.code.Symbol$ParamSymbol.getSimpleName(Symbol.java:1308)
	at org.netbeans.modules.java.navigation.ElementScanningTask.createHtmlHeader(ElementScanningTask.java:316)
	at org.netbeans.modules.java.navigation.ElementScanningTask.element2description(ElementScanningTask.java:259)
	at org.netbeans.modules.java.navigation.ElementScanningTask.addMembers(ElementScanningTask.java:227)
	at org.netbeans.modules.java.navigation.ElementScanningTask.runImpl(ElementScanningTask.java:146)
	at org.netbeans.modules.java.navigation.ElementScanningTask.run(ElementScanningTask.java:104)
	at org.netbeans.modules.java.navigation.ElementScanningTask.run(ElementScanningTask.java:85)
	at org.netbeans.modules.java.source.JavaSourceAccessor$CancelableTaskWrapper.run(JavaSourceAccessor.java:298)
	at org.netbeans.modules.parsing.impl.TaskProcessor.callParserResultTask(TaskProcessor.java:568)
	at org.netbeans.modules.parsing.impl.TaskProcessor$CompilationJob.run(TaskProcessor.java:744)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
	at java.util.concurrent.FutureTask.run(FutureTask.java:262)
	at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1423)
	at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2033)
Comment 5 theshadow27 2014-04-09 20:41:27 UTC
This is more serious than I thought - The Window.class.dump is written for EVERY source code modification to a Form Designer class, regardless if or if not the file is saved. Saving the file (after modification) also causes a dump. 


@jlahoda I am raising this to P2 on the following basis:

* performance - Significant scalability problem (writes 153kb for *every* edit until the folder fills up at 255 files, which is 38mb of wasted space)

* other - Affects another developer's progress (consumes all .dump files in short order, preventing development/debugging of other modules)


Steps to reproduce:

1) Install 8.0, or the latest dev build (using 201404090001). Fresh userdir

2) New maven project -> Java Application -> all defaults 

3) [Projects window, mavenproject1 -> Source Packages] New -> jFrame form

4) It should open in the "Design" view 

5) [Palette -> Swing Controls -> JLabel] -> Drag anywhere in the blank form

6) Save (ctrl-s) while still in "Design"

7) Switch to "Source" view. ** WRITES Window.class.dump **

8) Place cursor in the comment above the class. 

9) Press enter (or spacebar, or any letter).  ** WRITES Window.class.dump **
9a) wait a second for previous .dump file write to finish. 
9b) goto step 9, unless you are satisfied 

10) Save (ctrl-s)  ** WRITES Window.class.dump **
10a) go to step 9


For each .dump there is also this in messages.log:


    Coupling error:
    class file: jar:file:/Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home/lib/ct.sym!/META-INF/sym/rt.jar/java/awt/Window.class
    source file: jar:file:/Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home/src.zip!/java/awt/Window.java
    VARIABLE: allWindows
    METHOD: getAllWindows
    METHOD: getAllUnblockedWindows

And after 255 (yes, I pressed spacebar once per second 260 times):

    WARNING [org.netbeans.modules.java.source.TreeLoader]: Dump could not be written. Either dump file could not be created or all dump files were already used. Please check that you have write permission to '/Users/theshadow/Library/Application Support/NetBeans/dev/var/log/' and clean all *.dump files in that directory.


This shows that other dump files will not be written out due to this issue.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo