Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 197404 - deadlock involving annotations and hints
deadlock involving annotations and hints
Product: editor
Classification: Unclassified
Component: Parsing & Indexing
PC Windows XP
: P1 (vote)
: 7.0
Assigned To: Tomas Zezula
Depends on:
  Show dependency treegraph
Reported: 2011-04-04 15:42 UTC by err
Modified: 2011-04-08 09:24 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT

thread dump of deadlock (34.61 KB, text/plain)
2011-04-04 15:42 UTC, err

Note You need to log in before you can comment on or make changes to this bug.
Description err 2011-04-04 15:42:30 UTC
Created attachment 107479 [details]
thread dump of deadlock

I entered Ctrl-space, got the searching/waiting... one line popup. Didn't go away. ESC dismissed. Tried again, still wouldn't complete. Decided to save file and exit IDE. hang. Set to P2 since edits were lost.

The following can be seen in the attached thread dump

Found one Java-level deadlock:
  waiting to lock monitor 0x0ba996cc (object 0x19d31620, a org.netbeans.modules.parsing.impl.TaskProcessor$InternalLock),
  which is held by "OpenIDE-request-processor-4"
  waiting to lock monitor 0x047205f4 (object 0x16db1290, a,
  which is held by "AnnotationHolder"

Product Version: NetBeans IDE 7.0 RC1 (Build 201103280000)
Java: 1.6.0_23; Java HotSpot(TM) Client VM 19.0-b09
System: Windows XP version 5.1 running on x86; Cp1252; en_US (nb)
Userdir: C:\Documents and Settings\erra\.netbeans\7.0rc1
Comment 1 Marian Mirilovic 2011-04-04 20:38:15 UTC
nice ;(

Editor guys, please evaluate ASAP.
Comment 2 Jan Lahoda 2011-04-05 02:41:42 UTC
I think I can easily remove the lock that wraps the JavaSourceTaskFactory.reschedule which would most likely fix the problem. The question is whether this is the correct fix.
Comment 3 Tomas Zezula 2011-04-05 11:40:23 UTC
It may be problem even with other tasks. I am fixing it in TP.
Comment 4 Tomas Zezula 2011-04-05 12:58:16 UTC
Fixed jet-main 1b4a3c298ee8
Comment 5 Jan Lahoda 2011-04-05 13:45:06 UTC
Seems fine to me.
Comment 6 Tomas Zezula 2011-04-05 15:16:58 UTC
Integrated into 7.0
Comment 7 Jaroslav Tulach 2011-04-05 15:31:28 UTC
There is a way to check if a lock is being held: Thread.holdsLock. Thus:
1. adding new boolean parameter is not necessary, could be replaced with holdsLock call
2. you should add assertFalse(Thread.holdsLock(INTERNAL_LOCK)) into some of your tests, so they fail before your fix and pass now.
Those are my 2Kč. They probably do not influence your fix for 7.0, but at least one could be useful in long term.
Comment 8 Tomas Zezula 2011-04-05 15:37:02 UTC
For trunk I am planing a bit complex rewrite. But thanks Jardo anyway.
Comment 9 Quality Engineering 2011-04-06 08:45:27 UTC
Integrated into 'main-golden', will be available in build *201104060400* on (upload may still be in progress)
User: Tomas Zezula <>
Log: #197404:deadlock involving annotations and hints
Comment 10 Jaromir Uhrik 2011-04-08 09:24:02 UTC
No regression met during testing so marking this issue as Verified.

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