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.
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*/
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?
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)?
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.
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.
Fixed in trunk: core/bootstrap/src/org/netbeans/ProxyClassLoader.java,v1.42 So it happened twice? Good to know....
We decided not to integrate this to NB 6, downgrading to P2. Also changing the component to core.
Verified. Not seen in latest builds.