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.
| Summary: | Deadlock in schema editor | ||
|---|---|---|---|
| Product: | xml | Reporter: | Nikita Krjukov <supernikita> |
| Component: | Schema Tools | Assignee: | Samaresh Panda <samaresh> |
| Status: | RESOLVED FIXED | ||
| Severity: | blocker | CC: | adrianriley, slunegov |
| Priority: | P1 | ||
| Version: | 6.x | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Attachments: |
Test XSD file. It has mistake intentionally
Thread dump |
||
|
Description
Nikita Krjukov
2009-03-12 19:25:28 UTC
Created attachment 78130 [details]
Test XSD file. It has mistake intentionally
Created attachment 78131 [details]
Thread dump
Preliminary analysis shows that the Schema model become valid and it starts notifying listeners. The notifications happens in the "Default RequestProcessor" thread: org.netbeans.modules.xml.schema.multiview.SchemaColumnViewMultiViewElement.recreateUI(SchemaColumnViewMultiViewElement.java:357) org.netbeans.modules.xml.schema.multiview.SchemaColumnViewMultiViewElement.propertyChange(SchemaColumnViewMultiViewElement.java:226) It seems the SchemaColumnViewMultiViewElement.recreateUI should be executed in AWT thread rather than in the "Default RequestProcessor". It looks like it comes to blocking AWT thread. There is another strange finding. It is a kind of performance issue. The recreated UI element corresponds to Schema tab, which is invisible. It can be initialized only when it is required. Otherwise editing of sources can come to frequent processing behind the scene. TODO: It's necessary to check the issue with a trunk build. It can be already fixed there. But it would be better to have it fixed in netbeans65_fixes anyway. The issue #116057 looks very similar. It seems they both have common reason - execution of java WindowsAPI functions out of event dispatch thread. Despite I can't reproduce it in trunk, I'm going to correct it everywhere. I bereave it's important because the risk of deadlock is quite high. The issue #116057 looks very similar. It seems they both have common reason - execution of java WindowsAPI functions out of event dispatch thread. Despite I can't reproduce it in trunk, I'm going to correct it everywhere. I bereave it's important because the risk of deadlock is quite high. The issue #116057 looks very similar. It seems they both have common reason - execution of java WindowsAPI functions out of event dispatch thread. Despite I can't reproduce it in trunk, I'm going to correct it everywhere. I bereave it's important because the risk of deadlock is quite high. I pushed changes to trunk: http://hg.netbeans.org/main/rev/851f66f426ad The fix delegates processing of events from schema model to event dispatch thread in case the events come from another thread. It is applied only for cases when event processing is done in favor of UI modification. It is required to do UI modification in the event dispatch thread. TODO: It maybe reasonable to check another XDM based models to vulnerability regarding the same reasons. For example WSDL model. I just tried reproduce the issue in the release65_fixes and failed. So I'm not sure if it worth to migrate the issue there. Integrated into 'main-golden', will be available in build *200903191401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/851f66f426ad User: supernikita@netbeans.org Log: Fix the issue #160206 - Deadlock in schema editor *** Issue 159183 has been marked as a duplicate of this issue. *** *** Issue 162770 has been marked as a duplicate of this issue. *** *** Bug 162106 has been marked as a duplicate of this bug. *** |