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 211811 - NetBeans May Lock-up On Start With JDK 7 U4
Summary: NetBeans May Lock-up On Start With JDK 7 U4
Status: RESOLVED DUPLICATE of bug 210752
Alias: None
Product: platform
Classification: Unclassified
Component: JDK Problems (show other bugs)
Version: 7.2
Hardware: PC Windows Vista
: P2 normal (vote)
Assignee: Antonin Nebuzelsky
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-26 21:37 UTC by MackSix
Modified: 2012-05-02 10:45 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
npss snapshot (315.22 KB, application/octet-stream)
2012-04-26 21:37 UTC, MackSix
Details
startup log (1.34 MB, text/plain)
2012-04-26 21:38 UTC, MackSix
Details
messages.llog file (45.74 KB, text/plain)
2012-04-26 21:38 UTC, MackSix
Details
thread dump (40.29 KB, text/plain)
2012-05-02 09:31 UTC, MackSix
Details
Another thread dump (30.68 KB, text/plain)
2012-05-02 09:46 UTC, MackSix
Details

Note You need to log in before you can comment on or make changes to this bug.
Description MackSix 2012-04-26 21:37:36 UTC
Created attachment 118829 [details]
npss snapshot

1) Start NetBeans with a Java project already open.
2) As soon as you see the main menu bar (File, Edit, View, ...), hover the mouse cursor over "File" and then move it across Edit and continue across all menu items and back again. Keep moving back and forth across the menu options while startup scanning is taking place.

NetBeans locks up.


Product Version: NetBeans IDE Dev (Build 201204260400)
Java: 1.7.0_04; Java HotSpot(TM) Client VM 23.0-b21
System: Windows Vista version 6.0 running on x86; Cp1252; en_US (nb)

See attached snapshot.npss, logfile.xml. messages.log
Comment 1 MackSix 2012-04-26 21:38:17 UTC
Created attachment 118830 [details]
startup log
Comment 2 MackSix 2012-04-26 21:38:34 UTC
Created attachment 118831 [details]
messages.llog file
Comment 3 Marian Mirilovic 2012-04-27 11:45:54 UTC
reassign to performance team for further evaluation
Comment 4 MackSix 2012-05-01 20:16:19 UTC
This also happens if I am quick to open a project immediately on startup.

I have also seen it happen when I was quick to right click on a project in the Project Windows upon startup, but is not always reproducible each time.
Comment 5 Petr Cyhelsky 2012-05-02 04:23:24 UTC
there seems to be a deadlock involving RepositoryUpdater.worker
 

"AWT-EventQueue-1" - Thread t@40
    java.lang.Thread.State: BLOCKED
	at sun.awt.PostEventQueue.noEvents(SunToolkit.java:2104)
	- waiting to lock <1b7bd81> (a sun.awt.PostEventQueue) owned by "RepositoryUpdater.worker" t@54
	at sun.awt.SunToolkit.isPostEventQueueEmpty(SunToolkit.java:577)
	at java.awt.EventQueue.detachDispatchThread(EventQueue.java:1048)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:103)

   Locked ownable synchronizers:
	- None

and

"AWT-Windows" - Thread t@24
    java.lang.Thread.State: BLOCKED
	at sun.awt.PostEventQueue.postEvent(SunToolkit.java:2128)
	- waiting to lock <1b7bd81> (a sun.awt.PostEventQueue) owned by "RepositoryUpdater.worker" t@54
	at sun.awt.SunToolkit.postEvent(SunToolkit.java:529)
	at sun.awt.windows.WComponentPeer.postEvent(WComponentPeer.java:844)
	at sun.awt.windows.WToolkit.eventLoop(Native Method)
	at sun.awt.windows.WToolkit.run(WToolkit.java:299)
	at java.lang.Thread.run(Thread.java:722)

and

"RepositoryUpdater.worker" - Thread t@54
    java.lang.Thread.State: WAITING
	at sun.misc.Unsafe.park(Native Method)
	- waiting to lock <e282dd> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) owned by "AWT-EventQueue-1" t@40
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
	at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:214)
	at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:290)
	at java.awt.EventQueue.postEventPrivate(EventQueue.java:235)
	at java.awt.EventQueue.postEvent(EventQueue.java:221)
	at sun.awt.PostEventQueue.flush(SunToolkit.java:2116)
	at sun.awt.SunToolkit.flushPendingEvents(SunToolkit.java:563)
	at java.awt.EventQueue.postEvent(EventQueue.java:220)
	at java.awt.EventQueue.invokeLater(EventQueue.java:1188)
	at javax.swing.SwingUtilities.invokeLater(SwingUtilities.java:1287)
	at org.netbeans.modules.progress.spi.Controller.runImmediately(Controller.java:217)
	at org.netbeans.modules.progress.spi.Controller.displayNameChange(Controller.java:200)
	at org.netbeans.modules.progress.spi.InternalHandle.requestDisplayNameChange(InternalHandle.java:333)
	at org.netbeans.api.progress.ProgressHandle.setDisplayName(ProgressHandle.java:211)
	at org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task._run(RepositoryUpdater.java:5115)
	at org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task.access$4800(RepositoryUpdater.java:4820)
	at org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task$2$1.run(RepositoryUpdater.java:5065)
	at org.netbeans.modules.parsing.impl.RunWhenScanFinishedSupport.performScan(RunWhenScanFinishedSupport.java:97)
	at org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task$2.call(RepositoryUpdater.java:5061)
	at org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task$2.call(RepositoryUpdater.java:5057)
	at org.netbeans.modules.masterfs.filebasedfs.utils.FileChangedManager.priorityIO(FileChangedManager.java:168)
	at org.netbeans.modules.masterfs.providers.ProvidedExtensions.priorityIO(ProvidedExtensions.java:360)
	at org.netbeans.modules.parsing.impl.Utilities.runPriorityIO(Utilities.java:72)
	at org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task.run(RepositoryUpdater.java:5057)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
	at java.util.concurrent.FutureTask.run(FutureTask.java:166)
	at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1452)
	at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2032)
Comment 6 Tomas Hurka 2012-05-02 07:55:12 UTC
Since it looks like a deadlock, can you please attach plain thread dump. Thanks.
Comment 7 Tomas Zezula 2012-05-02 08:56:36 UTC
Does not seem to have something in common with parsing.api.
The lock is not hold by RU but by PostEventQueue.
Please attach whole thread dump.
Comment 8 MackSix 2012-05-02 09:31:08 UTC
Created attachment 118952 [details]
thread dump
Comment 9 Tomas Zezula 2012-05-02 09:36:44 UTC
Thanks for thread dump.
Comment 10 MackSix 2012-05-02 09:45:39 UTC
(In reply to comment #9)
> Thanks for thread dump.

I have another thread dump, this one looks different to me. See attached.
Comment 11 MackSix 2012-05-02 09:46:01 UTC
Created attachment 118955 [details]
Another thread dump
Comment 12 Tomas Zezula 2012-05-02 09:48:20 UTC
The case is the same sun.awt.SunToolkit.
Thanks!
Comment 13 MackSix 2012-05-02 09:51:51 UTC
(In reply to comment #12)
> The case is the same sun.awt.SunToolkit.
> Thanks!

I see, I just don't know how to read it. Thank you.
Comment 14 Antonin Nebuzelsky 2012-05-02 10:45:39 UTC

*** This bug has been marked as a duplicate of bug 210752 ***