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 36672 - Deadlock after applying IMT
Summary: Deadlock after applying IMT
Status: VERIFIED DUPLICATE of bug 36681
Alias: None
Product: platform
Classification: Unclassified
Component: Window System (show other bugs)
Version: 3.x
Hardware: PC Windows XP
: P1 blocker (vote)
Assignee: _ tboudreau
Depends on:
Reported: 2003-10-18 20:24 UTC by _ gtzabari
Modified: 2008-12-22 21:45 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Source code which triggers deadlock (757 bytes, text/plain)
2003-10-18 20:25 UTC, _ gtzabari
full thread dump (17.66 KB, text/plain)
2003-10-20 09:10 UTC, Milan Kubec

Note You need to log in before you can comment on or make changes to this bug.
Description _ gtzabari 2003-10-18 20:24:41 UTC
dev build 200310170100
Sun JDK 1.4.2_01

1) I run the Import Management Tool on the
attached source.
2) It finds a single match for MailAddress at
3) I hit "FINISH" (hitting CANCEL works fine)
4) Netbeans deadlocks

    This is reproducible 100% of the time. Setting
to P2 due to severity and frequency of issue.
Comment 1 _ gtzabari 2003-10-18 20:25:39 UTC
Created attachment 11903 [details]
Source code which triggers deadlock
Comment 2 _ gtzabari 2003-10-18 20:28:32 UTC
BTW: org.apache.mailet comes from james.jar which is 350k. I could
attach it to this issue or you could retrieve it from Apache James
( You'll find it inside
the following path: <james install

SAR is some sort of packaging mechanism similar to JAR. Use any ZIP
handler to extract files from it.
Comment 3 Milan Kubec 2003-10-20 08:47:13 UTC
Please provide full thread dump. Thanks.
Comment 4 Milan Kubec 2003-10-20 09:10:00 UTC
Created attachment 11907 [details]
full thread dump
Comment 5 Milan Kubec 2003-10-20 09:10:51 UTC
I've managed to reproduce it, thread dump attached.
Comment 6 Milan Kubec 2003-10-20 09:26:33 UTC
Reproducible on any source code, even without any unresolved
identifiers => P1. Just click 'Finish'.
Comment 7 Miloslav Metelka 2003-10-20 10:13:21 UTC
Document locking gets deadlocked with accessing of the AWT tree lock.
IMHO the tree lock should not get accessed outside of AWT thread (by
Module-Actions in this case). I've seen that Jesse has integrated a
check for that in 1.87 of

            if (!EventQueue.isDispatchThread()) {
                new IllegalStateException("This must happen in the
event thread!").printStackTrace();

 so I would expect that there should be an ISE dump in the ide.log
logging the exception that should be thrown in that case. Milane could
you please check the ide.log for that? Thanks.

I believe that this deadlock should not be caused by the integration
of the locking fixes done in scope of issue 33165.
Comment 8 Milan Kubec 2003-10-20 10:23:57 UTC
You are right there is ISE thrown. I've already filed an issue #36681.
Comment 9 Miloslav Metelka 2003-10-20 10:27:05 UTC
Before 1.87 in o.o.a.Actions there used to be 

            // do in EventQueue
            Mutex.EVENT.readAccess (new Runnable () {
                public void run () {
                    updateState (ev.getPropertyName ());

which triggered

    private static void doEvent (Runnable run) {
        if (EventQueue.isDispatchThread ()) {
        } else {
            EventQueue.invokeLater (run);

that ensured the code to be running in EQ.

Not sure where exactly this should get fixed but reassigning to
Comment 10 Jesse Glick 2003-10-20 15:47:27 UTC
Issue #36681 is all there is to fix, IMHO.

*** This issue has been marked as a duplicate of 36681 ***
Comment 11 Marian Mirilovic 2004-02-29 09:29:02 UTC
verified duplicate