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 121545 - Deadlock while creating xml schema
Summary: Deadlock while creating xml schema
Status: VERIFIED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Module System (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: Marek Fukala
URL:
Keywords: RANDOM, THREAD
Depends on:
Blocks:
 
Reported: 2007-11-09 09:36 UTC by Jiri Skrivanek
Modified: 2008-12-23 08:41 UTC (History)
8 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jiri Skrivanek 2007-11-09 09:36:22 UTC
A deadlock appears in automated tests when the test is going to create an xml schema. See screen shot:

http://deadlock.netbeans.org/hudson/job/testsHistory/ws/results/netbeans_6.0_validation/20071109065752/quality_engineering-validation/deadlock/testrun_071109-080347/testbag_3/sys/ide/screenshots/screenshot-kill.png

IMO, there are two threads involved:

AWT-EventQueue-2 - xml.schema.wizard.SchemaWizardIterator.createPanels
Default RequestProcessor  - JspEditorWarmUpTask.isWebProjectOpened

Look for 0x5d9b4838 in the following thread dump

http://deadlock.netbeans.org/hudson/job/testsHistory/ws/results/netbeans_6.0_validation/20071109065752/quality_engineering-validation/deadlock/testrun_071109-080347/logs/xml_schema_qa-functional.log/*view*/
Comment 1 Samaresh Panda 2007-11-09 14:50:10 UTC
I do not see any issues with xml.schema.wizard code. Assigning to web-core for evaluation. BTW, I'm unable to reproduce
this. Is this a new test that got introduced recently? Are you able to reproduce the deadlock manually?
Comment 2 Marek Fukala 2007-11-11 08:27:21 UTC
I really have no idea what can be the problem, the "AWT-EventQueue-2" thread is runable in the thread dump - some
classloading is done there. The project classloader is synchronized on the mentioned monitor and the
JspEditorWarmUpTask.isWebProjectOpened() just waits for the monitor. 

I do not see any deadlock here, maybe there is something wrong with the classloading that it takes longer time??? Can
someone with deep knowledge of the classloading express his opinion?

Maybe some bug in the testing infrastructure? Is it reproducible (both AT and manual testing)?
Comment 3 Petr Nejedly 2007-11-11 22:24:43 UTC
Ugh, I have bad feeling I know what is this, see below.
Is this at least a little bit reproducible?
If reproduces, is the system idle or does java process keep burning CPU?

I suspect the problem is the HashMap being stuck in an infinite loop after a data race - it can happen that if one
thread modifies an unsynchronized HashMap the other thead is just traversing, the other thread might find an entry that
has the next pointer looped.

Please note that while the method is synchronized, the hash map in question is static, so it might happen that two
threads are accessing it concurrently, each under its own lock.

The fix for this is very simple - just wrap the map with a Collections.synchronizedMap() - and potentially very risky
as well (can introduce deadlocks). I'll try to analyze the code paths and verify whether the fix would be safe.

Comment 4 Jiri Skrivanek 2007-11-12 08:48:22 UTC
At the time I am not able to reproduce it neither in automated tests nor manually. It appeared in builds 20071109002746
and 20071109065752. After then the tests pass.
Comment 5 Petr Nejedly 2007-11-12 08:56:41 UTC
Fixed in trunk:
core/bootstrap/src/org/netbeans/ProxyClassLoader.java,v1.42

So it happened twice? Good to know....
Comment 6 Petr Jiricka 2007-11-12 10:39:23 UTC
We decided not to integrate this to NB 6, downgrading to P2. Also changing the component to core.
Comment 7 Jiri Skrivanek 2007-11-16 13:37:10 UTC
Verified. Not seen in latest builds.