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 229651 - Temporary freeze when page inspection is started
Summary: Temporary freeze when page inspection is started
Status: RESOLVED FIXED
Alias: None
Product: web
Classification: Unclassified
Component: Inspection (show other bugs)
Version: 7.4
Hardware: All All
: P3 normal (vote)
Assignee: Jan Stola
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-05-13 11:55 UTC by Jan Stola
Modified: 2013-05-13 12:36 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
thread dump (25.18 KB, text/plain)
2013-05-13 11:56 UTC, Jan Stola
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Stola 2013-05-13 11:55:39 UTC
Sometimes when the page inspection is started it takes significant time (~10s) for Browser DOM view to populate. The console shows several warnings about getDocument() returning null when the view is populated finally. The attachment shows the thread dump taken during the "freeze".
Comment 1 Jan Stola 2013-05-13 11:56:31 UTC
Created attachment 134360 [details]
thread dump
Comment 2 Jan Stola 2013-05-13 12:11:09 UTC
The thread dump shows that "org.netbeans.modules.web.inspect.webkit.WebKitPageModel" thread waits in sendBlockingCommand("DOM.getDocument"). The expected response should be delivered by "WebSocketServer" thread. "WebSocketServer" thread attempts to enter DOM.handleDocumentUpdated, but it waits for DOM.this lock that is held by "org.netbeans.modules.web.inspect.webkit.WebKitPageModel" thread.

This would be a deadlock if there weren't a timed wait in sendBlockingCommand().

This is a race condition. It occurs when documentUpdated event is delivered while we are waiting for response for DOM.getDocument message.
Comment 3 Jan Stola 2013-05-13 12:36:41 UTC
Fixed by http://hg.netbeans.org/web-main/rev/5546f36fe1c3