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.
I recently migrated to NB 7.1.2 and Java 7 (update 4) on Mac OS X Lion 10.7.4 and boy it is unstable! Almost once every two launches, I get one of the following UI problems: - main NB window is blank and there is no way to make its content come back (reset windows does not work, resizing does not work, etc.); it is as if the content was there (clicking randomly on the blank windows seems to trigger actions...) but no way to have it displayed; - the Opening Projects progress bar is stuck at 33%; - the full screen mode is either unvailable or it is but when activated there is no way to go out of it. Unless an update of Java 7 and/or NB 7.1.2 comes out quickly and solves these basic problems, I am seriously considering going back to Java 6 and/or NB 7.1.1. Sad sad sad...
Please attach some screen shots and IDE log and reopen, thanks.
(In reply to comment #0) > I recently migrated to NB 7.1.2 and Java 7 (update 4) on Mac OS X Lion 10.7.4 > and boy it is unstable! > > Almost once every two launches, I get one of the following UI problems: > > - main NB window is blank and there is no way to make its content come back > (reset windows does not work, resizing does not work, etc.); it is as if the > content was there (clicking randomly on the blank windows seems to trigger > actions...) but no way to have it displayed; > > - the Opening Projects progress bar is stuck at 33%; I think you are facing in both cases deadlocks after startup: This issue must be fixed on JDK side: see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7159230 and corresponding NetBeans issues: http://netbeans.org/bugzilla/show_bug.cgi?id=210752 http://netbeans.org/bugzilla/show_bug.cgi?id=210938 http://netbeans.org/bugzilla/show_bug.cgi?id=211378 Can you please verify it's really deadlock by generating thread dump? http://wiki.netbeans.org/GenerateThreadDump (make it easy and run NetBeans from console) > > - the full screen mode is either unvailable or it is but when activated there > is no way to go out of it. Can you please specify what do you mean by ' no way to get out of it'? It should be possible to exit fullscreen by moving mouse on top making menu appear and clicking button like in other native apps? I've noticed that rarely is fullscreen button really missing. This is valid random issue from my POV. > > Unless an update of Java 7 and/or NB 7.1.2 comes out quickly and solves these > basic problems, I am seriously considering going back to Java 6 and/or NB > 7.1.1. Sad sad sad...
Created attachment 119715 [details] Screenshot after launch (blank window) This is what I get after launching NB with the following configuration: Product Version: NetBeans IDE 7.1.2 (Build 201204101705) Java: 1.7.0_04; Java HotSpot(TM) 64-Bit Server VM 23.0-b21 System: Mac OS X version 10.7.4 running on x86_64; UTF-8; en_US (nb) User directory: /Users/garbi/.netbeans/7.1.2 Cache directory: /Users/garbi/.netbeans/7.1.2/var/cache
garbi, please provide us thread dump. Screenshot is not helpful, we need to be sure it's deadlock. See my comment #2. (In reply to comment #3) > Created attachment 119715 [details] > Screenshot after launch (blank window) > > This is what I get after launching NB with the following configuration: > > Product Version: NetBeans IDE 7.1.2 (Build 201204101705) > Java: 1.7.0_04; Java HotSpot(TM) 64-Bit Server VM 23.0-b21 > System: Mac OS X version 10.7.4 running on x86_64; UTF-8; en_US (nb) > User directory: /Users/garbi/.netbeans/7.1.2 > Cache directory: /Users/garbi/.netbeans/7.1.2/var/cache
I would be very happy to provide you with a thread dump but instructions to generate one on http://wiki.netbeans.org/GenerateThreadDump all fail on Mac OS X: - the console option does not work (at least with JDK7u4), - the jps & jstack tools seem to work only until JDK 6, - the StackTrace tool web references lead to non-existence pages, - the VisualVM tool suffers from the same problem as NB (blank window), - the Profile Me Now option is not possible because of NB's blank window. Any idea on how to proceed?
try starting NB from terminal: /Applications/NetBeans/NetBeans\ 7.1.1.app/Contents/Resources/NetBeans/bin/netbeans this should start NB in console, now you should be able to press CTRL + \ to print thread dump into console. Does it work? BTW: how often does this happen when you start NetBeans? Always? Very often? From time to time? Rarely? I've seen this on my MacBook once or twice, so information from you can be very helpful. (In reply to comment #5) > I would be very happy to provide you with a thread dump but instructions to > generate one on http://wiki.netbeans.org/GenerateThreadDump all fail on Mac OS > X: > > - the console option does not work (at least with JDK7u4), > - the jps & jstack tools seem to work only until JDK 6, > - the StackTrace tool web references lead to non-existence pages, > - the VisualVM tool suffers from the same problem as NB (blank window), > - the Profile Me Now option is not possible because of NB's blank window. > > Any idea on how to proceed?
No, CTRL + \ does not work on my machine. I tried to launch NB via the console using both: /Applications/NetBeans/NetBeans\ 7.1.2.app/Contents/MacOS/netbeans and /Applications/NetBeans/NetBeans\ 7.1.2.app/Contents/Resources/NetBeans/bin/netbeans but nothing happens when I issue a CTRL + \, nor when I later send a QUIT signal via the kill command. Hereafter, I put the trace I get in the console. And to answer your question, yes this "blank window" happens quite often on my laptop (MacBook Pro). To solve it, I have to go throughout an arbitrarily long sequence of quit, reset windows, launch, quit, reset windows, etc. And now the trace: hec-170-64:~ garbi$ /Applications/NetBeans/NetBeans\ 7.1.2.app/Contents/MacOS/netbeans May 22 12:34:59 hec-170-64.unil.ch java[12347] <Error>: CGContextGetCTM: invalid context 0x0 May 22 12:34:59 hec-170-64.unil.ch java[12347] <Error>: CGContextSetBaseCTM: invalid context 0x0 May 22 12:34:59 hec-170-64.unil.ch java[12347] <Error>: CGContextGetCTM: invalid context 0x0 May 22 12:34:59 hec-170-64.unil.ch java[12347] <Error>: CGContextSetBaseCTM: invalid context 0x0 May 22 12:35:16 hec-170-64.unil.ch java[12347] <Error>: CGContextGetCTM: invalid context 0x0 May 22 12:35:16 hec-170-64.unil.ch java[12347] <Error>: CGContextSetBaseCTM: invalid context 0x0 May 22 12:35:16 hec-170-64.unil.ch java[12347] <Error>: CGContextGetCTM: invalid context 0x0 May 22 12:35:16 hec-170-64.unil.ch java[12347] <Error>: CGContextSetBaseCTM: invalid context 0x0 May 22 12:35:16 hec-170-64.unil.ch java[12347] <Error>: CGContextGetCTM: invalid context 0x0 May 22 12:35:16 hec-170-64.unil.ch java[12347] <Error>: CGContextSetBaseCTM: invalid context 0x0 ^\
passing to JDK problems. The only idea I have now is that it can be something similar like http://netbeans.org/bugzilla/show_bug.cgi?id=209583 , which should be fixed on JDK side. Can you please try to switch off "automatic graphic switching" in System preferences | Energy saver, and see if you still can reproduce this problem?
Do you mean "Automatically reduce brightness before display goes to sleep" ? I seem no "automatic graphic switching" option in System Preferences > Energy saver.
Also, to answer your other question "Can you please specify what do you mean by ' no way to get out of it'?", I mean that when in full-screen mode in NB, clicking on the blue button on the far right of the menu bar (the one that allows any application to go out of full screen mode) has sometimes no effect at all, so there is no way to switch NB in "normal mode". It is however still possible to switch to another application but NB seems to be stuck in full screen mode. Quitting NB seems to be the only option to make it go out of fullscreen mode.
Ok, you have probably MB Pro model with only one graphic card. In such a case it has nothing to do with mentioned issue #209583. would be helpful if you could try to simulate this with clean user directory. You can achieve that by launching netbeans from command line with parameter e.g. "--userdir /tmp/newusedir". Is it reproducible when trying to start netbeans into this "fresh" environment? (In reply to comment #9) > Do you mean "Automatically reduce brightness before display goes to sleep" ? I > seem no "automatic graphic switching" option in System Preferences > Energy > saver.
Filed issue 212840 and put you on CC for full screen problems, in order to track each problem under separate issue. (In reply to comment #10) > Also, to answer your other question "Can you please specify what do you mean by > ' no way to get out of it'?", I mean that when in full-screen mode in NB, > clicking on the blue button on the far right of the menu bar (the one that > allows any application to go out of full screen mode) has sometimes no effect > at all, so there is no way to switch NB in "normal mode". > > It is however still possible to switch to another application but NB seems to > be stuck in full screen mode. Quitting NB seems to be the only option to make > it go out of fullscreen mode.
Regarding my MB Pro model, it does have two graphics cards, namely an NVIDIA GeForce 9600M GT and a GeForce 9400M. Yet in the "System Preferences > Energy Saver" panel I still do not see any "automatic graphic switching" option. What I can do, however, is switch graphics card manually, by choosing either "Better battery life" or "Higher Performance". At the moment, I am using "Better battery life". Anyway, I will try to reproduce the problem with a clean user directory and keep you posted.
I see, so probably 9400M (with shared memory) maps to "Better battery life" while "Higher Performance" enables 9600GT. Would be also interesting to know if this issue can happen while you are using higher performance graphic. (In reply to comment #13) > Regarding my MB Pro model, it does have two graphics cards, namely an NVIDIA > GeForce 9600M GT and a GeForce 9400M. > > Yet in the "System Preferences > Energy Saver" panel I still do not see any > "automatic graphic switching" option. What I can do, however, is switch > graphics card manually, by choosing either "Better battery life" or "Higher > Performance". At the moment, I am using "Better battery life". > > Anyway, I will try to reproduce the problem with a clean user directory and > keep you posted.
Okay, I understand: my MB Pro is a mid-2009 model and the "Automatic graphics switching" only works from mid-2010 and later MB Pro models. I will manually switch to "Higher Performance" and see if I can reproduce the problem.
I was able to reproduce the blank window problem when my MP Pro was in "Higher Performance" graphics mode as well. Also, I was finally able to perform a ThreadDump using VisualVM (which was miraculously not affected by the "blank window" syndrome while NB was); I will upload these thread dumps in a minute. Interestingly, right after the first thread dump, NB went crazy in its CPU usage, eating up to 140% of my two cores (while the windows stayed blank). So I quit and restarted it, but CPU usage was again going crazy. So I performed a second thread dump while the CPU was being used massively. I will also upload the trace in the console after the thread dump, as it was repeatedly displaying a new message ("Profiler Agent: 250 classes cached"). I assume this is related to the use of VisualVM but since I am not 100% sure, I put this trace anyway. So the three files I will upload are: - threaddump-1337845339639.tdump : before cpu usage went crazy - trace-1337845339639.txt : trace in the console - threaddump-1337845745992.tdump : while cpu usage was crazy
Created attachment 119797 [details] thread dump when facing blank screen problem, before cpu usage went crazy
Created attachment 119798 [details] thread dump when facing blank screen problem, while cpu usage is crazy
Created attachment 119799 [details] trace in the console after performing a thread dump
Created attachment 119800 [details] thread dump when "Opening Projects" is stuck at 33% (but windows is NOT blank)
I just uploaded a thread dump of NB when the "Opening Projects" bar is stuck at 33% (but in absence of the blank window problem). In this case, it is not possible to quit NB normally, i.e., one has to kill it from outside the application. Also, I noticed the following: since in "Higher Performance" graphics mode, doing a "Reset Windows" in NB and restarting it seems to solve the "blank window" problem, whereas making a window floating (e.g., the Output window or the Task window) and restarting NB seems to cause the problem. I tried these sequences about 3-4 times and the observed effects have been consistent so far.
Thanks for further information! This attachment (i.e. threaddump "Opening projects" contains deadlock, but in j2ee area (which does not seem to be JDK related. Therefore i filed on you behalf issue 212935). (In reply to comment #20) > Created attachment 119800 [details] > thread dump when "Opening Projects" is stuck at 33% (but windows is NOT blank)
(In reply to comment #21) Ok, so just to make it clear, can you summarize some steps that lead to demonstation of this problem on your Mac? (Please start from scratch, with fresh userdir). We will try to reproduce on our Mac. Also please attach IDE's messages.log file when you reproduce blank windows (you can find it in /Users/garbi/.netbeans/7.1.2/var/log), just to be sure there's no exception from window system. Inspecting threaddumps during "blank window" unfortunately did not pointed at any problem, AWT is just waiting for events. Thanks in advance. > Also, I noticed the following: since in "Higher Performance" graphics mode, > doing a "Reset Windows" in NB and restarting it seems to solve the "blank > window" problem, whereas making a window floating (e.g., the Output window or > the Task window) and restarting NB seems to cause the problem. I tried these > sequences about 3-4 times and the observed effects have been consistent so far.
As requested, here goes the sequence that causes the problem, starting from a fresh userdir: 1. Launch NetBeans Command line: ./netbeans --userdir /tmp/newusedir 2. In NetBeans, open the Output window Menu Bar: Window > Output > Output 3. Make the Output window float Right-click on Output window's name > Float 4. Quit NetBeans Menu Bar: NetBeans > Quit 5. Launch NetBeans 6. PROBLEM: BLANK WINDOW! I also found a workaround that seems to work whatever graphics card I am using: 1. Reset windows: Top Menu Bar: Window > Reset Windows 2. Quit NetBeans 3. Launch NetBeans 4. PROBLEM FIXED!
Thanks! Now I'm able to reproduce the problem on my Mac. Stando, can you take a look?
This is a JDK bug. When some window is floating during window system startup the main window does not paint anything. But it does react to mouse and keyboard events (e.g. tooltips are showing, editing works etc). The following errors are present in the log when this happens: May 31 15:07:22 dhcp-prague08-second-floor-10-163-21-197.cz.oracle.com java[95075] <Error>: CGContextGetCTM: invalid context 0x0 May 31 15:07:22 dhcp-prague08-second-floor-10-163-21-197.cz.oracle.com java[95075] <Error>: CGContextSetBaseCTM: invalid context 0x0 May 31 15:07:22 dhcp-prague08-second-floor-10-163-21-197.cz.oracle.com java[95075] <Error>: CGContextGetCTM: invalid context 0x0 May 31 15:07:22 dhcp-prague08-second-floor-10-163-21-197.cz.oracle.com java[95075] <Error>: CGContextSetBaseCTM: invalid context 0x0
I found two possible work arounds in NetBeans code: Option 1: Do not set apple.awt.brushMetalLook=true client property on main window's root pane. (It's used to get native-like look of the main window) Option 2: Show main window first and then its child floating JDialogs. But I still can't provide reproducible code in a plain Swing app. Another problem with non-modal JDialog windows is that their location is not independent. When their parent JFrame is moved to a new location, the floating JDialogs move as well. This problem is reproducible in a plain Swing app and it works fine in JDK 1.6
> But I still can't provide reproducible code in a plain Swing app. We need to go with a workaround in our code. The following option sounds like the least disturbing: > Option 2: Show main window first and then its child floating JDialogs. --- > Another problem with non-modal JDialog windows is that their location is not > independent. When their parent JFrame is moved to a new location, the floating > JDialogs move as well. This problem is reproducible in a plain Swing app and it > works fine in JDK 1.6 File a separate issue. This should be reported to JDK.
core-main d23e6b5cd158
Integrated into 'main-golden', will be available in build *201206060001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/d23e6b5cd158 User: S. Aubrecht <saubrecht@netbeans.org> Log: #212590 - show main window first then child dialogs to avoid problems with JDK 7 on Mac