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.
[ BUILD # : rc0 ] [ JDK VERSION : 1.7 ] I downloaded and set up solaris 11 11/11 in a Virtual Box environment. as root: next, I installed jdk 7.0 update 1 next, I installed NetBeans 7.1 rc0 that we've been asked to test. as myself, I started NetBeans, and the ide came up as expected. I then activated the 'ide','java se', 'java web and EE' options, and said 'yes' to the question about installing junit. (was junit earlier?) I then clicked on the 'services' tab, and clicked to expand the 'servers', at which point the cursor became the busy indicator, and the ide became unresponsive. I brought up the terminal window from which I started NetBeans and hit CTRL-C. I then restarted NetBeans, and navigated again to the same place, and got the same result.
please use control-\ to generate a thread dump so we can see where the ide is running into trouble.
Created attachment 113352 [details] startup + thread dump after clicking to expand 'servers'
http://hg.netbeans.org/web-main/rev/3e04a4c2b60e Please try the next dev build that includes this code change to verify that it addresses this issue so we can push the fix into the release71 branch.
Integrated into 'main-golden', will be available in build *201111220600* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/3e04a4c2b60e User: vince kraemer <vkraemer@netbeans.org> Log: #205319 : deadlock when creating a local personal domain on solaris or other platforms where some files in a domain are not readable.
I have tested the fix (in the daily dev build), and it does indeed appear to fix the issue. thank you! best regards, peter.
this is deadlock is in code that was added to address http://netbeans.org/bugzilla/show_bug.cgi?id=184674
The fix seems to be good for 7.1. Though I would recommend some more investigation - the GFInstanceProvider code/lifecycle seems to be really deadlock prone. I'm not sure about the CommonServerSupport lock in getDomainsRoot method. Is it guarding some state? Perhaps it is just making the domain initialization atomic (or both). If this is the case rescheduling to another thread actually breaks such principle.
I reviewed the fix but code is too complex to give a definitive answer. I agree with what PetrH said - posting domain creation into separate thread will avoid this deadlock but I would think it also breaks contract of getDomainsRoot(), no? The deadlock is limited only to the scenario where domain being copied was created under root privileges and is unreadable for regular user as described in issue 184674. Alternative solution would be to revert fix for issue 184674 and reopen it - it has 15 duplicates and existed since 6.9 so total number of impacted users is small. On the other hand because this deadlock is limited only to this scenario the fix Vince is proposing is safe and can be integrated into 7.1 - nobody else apart from users in this scenario is impacted if there is an additional issue with it.
http://hg.netbeans.org/releases/rev/3197a272e915
Integrated into 'releases' Changeset: http://hg.netbeans.org/releases/rev/3197a272e915 User: vince kraemer <vkraemer@netbeans.org> Log: #205319 : deadlock when creating a local personal domain on solaris or other platforms where some files in a domain are not readable.
Verified by reporter in build 2011-12-05_11-21-34.
*** Bug 199259 has been marked as a duplicate of this bug. ***
this is again happening with 7.2.
(In reply to comment #13) > this is again happening with 7.2. Please provide info about the build where you see this (from the About box) and thread dump if you can. Please verify that the steps you took match those in the initial description. If they are different, please provide them...
Tomas, please verify that your recent changes for the stackoverflow are not coming into play here.
OK. They were not pushed into main repository yet. But when comparing stack traces this looks completely different. Is it possible to reproduce this in some less complicated way? I would like to avoid installing VirtualBox + Solaris.
the VirtualBox Solaris install was used in the original bug report to verify that the issue was happening on other than Windows, I believe. I am currently seeing this issue on Windows 7 x64 with JDK 7u3 x64.
I was trying to reproduce it on my trunk build without any success. Please can you test this scenario with last netbeans build from http://bertram-tst.netbeans.org:8080/job/web-main/7126/ ? This build already contains bug fix that addressed issue in Services :: Servers menu. I wanted to reproduce this myself but it works fine for me. :(
I downloaded and tried out the version you indicated. however: what I got ended up behaving the same. here is what I did: 1. when asked, accept the junit download. 2. use netbeans64 binary to start netbeans (contained in the zip). 3. once the ide initially comes up, go into the plugins menu and enable the following already installed options: java SE, base IDE, web applications. 4. once they have been installed, open the following sub windows from the main toolbar's 'window' item: projects, files, services. 5. click on the 'servers' item. it will show that there is nothing there. 6. right click on it, and choose 'add server' 7. proceed to add a local domain instance of glassfish 3.1.2 located somewhere on your machine. 8. at this point, I got an error report dialog that came up, and it got registered as ide slowness. 9. shut down the ide. 10. start the ide. 11. click on 'services' 12. click to expand 'servers' 13. get the never ending hourglass and 'please wait'. note: I really have no idea which jdk this is using, since it was executed via the contents of the .zip download, and not set up using the installer that is normally used. and: since there's no installer, how do I clean up the install history stuff so that next time it won't find any remnants of having been running?
note: this issue is currently occurring on Windows 7 x64. I have not tried it using the VirtualBox hosted Solaris x86 environment lately. I have installed jdk 7u3 x64 on this computer, so I am hopeful this is what it was using when I ran the previously mentioned details.
(In reply to comment #18) > I was trying to reproduce it on my trunk build without any success. Please can > you test this scenario with last netbeans build from > http://bertram-tst.netbeans.org:8080/job/web-main/7126/ ? > > This build already contains bug fix that addressed issue in Services :: Servers > menu. I wanted to reproduce this myself but it works fine for me. :( should this be available in daily build 201203230400 ? I have downloaded and tried this also on a windows 2008 r2 x64 with jdk 7u3 and it is still behaving badly. ie: expand 'servers' and get the 'Please Wait' forever.
(In reply to comment #21) > I have downloaded and tried this also on a windows 2008 r2 x64 with jdk 7u3 and > it is still behaving badly. ie: expand 'servers' and get the 'Please Wait' > forever. Guys if you are still able to reproduce the issue please attach couple of thread dumps (http://wiki.netbeans.org/GenerateThreadDump) generated when the IDE is in "waiting forever" state.
when I click on the included link for how to generate the dump, I get a page indicating a MySQL error.
Database error A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: (SQL query hidden) from within function "MediaWikiBagOStuff::_doinsert". MySQL returned error "1114: The table 'objectcache' is full (localhost)".
Created attachment 117707 [details] thread dump using latest version. here is a thread dump of NetBeans 201204021038 exhibiting the same 'waiting forever' behavior.
Thank you fore the dump. Analysing this I see a typical school example of deadlock: Thread tid=0x0000000006d16800 ----------------------------- Holds 0x00000000f905bb28 Waiting for 0x00000000f95185e0 Thread tid=0x0000000006d0b800 ----------------------------- Holds 0x00000000f917a900 Holds 0x00000000f99d9908 Holds 0x00000000f95185e0 Holds 0x00000000f9518b60 Holds 0x00000000f9519de8 Waiting for 0x00000000f905bb28 So we have cycle in 0x00000000f95185e0 and 0x00000000f905bb28 lock requests. Cause is again typical school example of wrong locking pattern (those two locks are requested in reverse order): * 0x00000000f905bb28 first and 0x00000000f95185e0 second in tid 0x0000000006d16800 - org.netbeans.modules.j2ee.deployment.impl.ServerRegistry.init requested 0x00000000f905bb28 - org.netbeans.modules.glassfish.common.GlassfishInstanceProvider.getPrelude requested 0x00000000f95185e0 * 0x00000000f95185e0 first and 0x00000000f905bb28 second in tid 0x0000000006d0b800 - org.netbeans.modules.glassfish.common.GlassfishInstanceProvider.getEe6 requested 0x00000000f95185e0 - org.netbeans.modules.j2ee.deployment.impl.ServerRegistry.getServerInstance requested 0x00000000f905bb28 We have to rewerse order of locking in one of the code paths to fix this issue.
To fix this issue I modified both getEe6() and getPrelude() in GlassfishInstanceProvider class to use double checked locking and to use two independent locks instead of locking on the whole class. Method initialized() was changed to use those two locks instead of GlassfishInstanceProvider class locking too.
Also added @SuppressWarnings("LeakingThisInConstructor") to constructor to remove this warning. It's annoying and we know what we are doing. :)
changeset: 218701:722614006deb user: Tomas Kraus <TomasKraus@netbeans.org> date: Tue Apr 03 14:43:54 2012 +0200 files: glassfish.common/src/org/netbeans/modules/glassfish/common/GlassfishInstanceProvider.java description: Bug 205319 - IDE hangs after fresh install upon click to expand Servers pushing to https://TomasKraus:***@hg.netbeans.org/web-main/ remote: added 3 changesets with 1 changes to 1 files Here is fix. Please try to verify this fix when build with this fix will be ready.
Netbeans with this fis are available on http://bertram2.netbeans.org:8080/job/web-main/7271/ Please verify if problem is solved or not. I was unable to reproduce it in my development environment.
Created attachment 117763 [details] thread dump using NetBeans-dev-web-main-7271-on-20120403-full.zip it's still giving me the endless hourglass.... try again! regards, peter
I removed one issue but looke like there is problem even with lassfishInstanceProvider.getEe6 itself being called twice. I'll give it one more try.
Created attachment 118002 [details] dump using ctrl+break using netbeans dev build 201204080400 dump using ctrl+break using netbeans dev build 201204080400
*** Bug 210902 has been marked as a duplicate of this bug. ***
Tomas, I had to revert your changeset as it was causing another P1: changeset: 219455:1cb303917a69 parent: 218759:722614006deb user: David Konecny <dkonecny@netbeans.org> date: Wed Apr 11 12:08:01 2012 +1200 summary: Backed out changeset 722614006deb It is in web-main now.
I forgot to say that the original fix caused issue 210741.
Created attachment 118114 [details] possible fix for original deadlock Tomas is the synchronization on init code really needed? I think this change could fix the original issue without introducing SOE. I quickly tested the basic use cases (register/uregister/deploy/start/stop) and it seems to work ok. Though I'm not a GF plugin expert.
*** Bug 209916 has been marked as a duplicate of this bug. ***
changeset: 219483:fa7930503972 user: Tomas Kraus <TomasKraus@netbeans.org> date: Wed Apr 11 16:31:57 2012 +0200 files: glassfish.common/src/org/netbeans/modules/glassfish/common/GlassfishInstanceProvider.java description: Bug# 205319 - IDE hangs after fresh install upon click to expand 'servers' Bug# 210741 - InstanceCreationException caused by bug# 205319 fix. Removed deadlock condition in org.netbeans.modules.glassfish.common.GlassfishInstanceProvider and org.netbeans.modules.j2ee.deployment.impl.ServerRegistry
Peter pointed me to one theoretical deadlock conditions when using [CountDownLatch].await() when waiting for first thread to finish initialization: * thread A: calls ServerRegistry.init() and get "ServerRegistry" Lock calls GlassfishInstanceProvider.getEe6(...) but is not first and is suspended in await() * thread B: calls GlassfishInstanceProvider.getEe6(...) and is the first one so it goes trough new GlassfishInstanceProvider(...) and ee6Provider.init() ee6Provider.init() calls ServerRegistry.getServerInstance(...) and ServerRegistry.getServerInstance(...) is requesting "ServerRegistry" Lock. But this lock is hild by thread A which is waiting in await() for thread B. We decided to modify this fix to call <some>Provider.init() outside synchronized block and to remove CountDownLatch. changeset: 219600:ae6cb02f6d83 user: Tomas Kraus <TomasKraus@netbeans.org> date: Wed Apr 11 17:08:09 2012 +0200 files: glassfish.common/src/org/netbeans/modules/glassfish/common/GlassfishInstanceProvider.java description: Bug# 205319 - IDE hangs after fresh install upon click to expand 'servers' Bug# 210741 - InstanceCreationException caused by bug# 205319 fix. Previos attempt to fix deadlock may not work so using more conservative fix.
New fix attempt is being built on http://bertram2.netbeans.org:8080/job/web-main/7350/ so please test it to see if it resolved your issue.
Seems to be resolved. I tested the basic use cases (expand/add/start/stop/delete) with the build artifact from job #7350. I was unable to reproduce the issue, i.e., the server section expanded without any problems. (In reply to comment #41) > New fix attempt is being built on > http://bertram2.netbeans.org:8080/job/web-main/7350/ so please test it to see > if it resolved your issue.
Thank you for feedback. Closing this issue.
I tried the indicated build, and indeed, it does appear to not suffer the issue for me. best regards!
*** Bug 212935 has been marked as a duplicate of this bug. ***