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 245406 - RuntimeException: Data frame is too big. Cannot handle it. Implementation should be rewritten.
Summary: RuntimeException: Data frame is too big. Cannot handle it. Implementation sho...
Status: RESOLVED DUPLICATE of bug 245410
Alias: None
Product: ide
Classification: Unclassified
Component: Extbrowser (show other bugs)
Version: 8.0
Hardware: All All
: P3 normal (vote)
Assignee: Tomas Mysik
URL:
Keywords: RANDOM
Depends on:
Blocks: 245747
  Show dependency tree
 
Reported: 2014-07-04 12:25 UTC by Vladimir Riha
Modified: 2014-07-30 04:53 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter: 210537

Attachments
stacktrace (3.80 KB, text/plain)
2014-07-04 12:25 UTC, Vladimir Riha 		Details
screencast (3.85 MB, video/ogg)
2014-07-28 07:49 UTC, Vladimir Riha 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Vladimir Riha 2014-07-04 12:25:25 UTC 
Build: NetBeans IDE Dev (Build 201407040001)
VM: Java HotSpot(TM) 64-Bit Server VM, 25.5-b02, Java(TM) SE Runtime Environment, 1.8.0_05-b13
OS: Windows 7

User Comments:
vriha: What I did:
 - create a new HTML5 sample project Responsive Rabbits
 - run the project in Chromium with NB integration
 - clicked on div.container-fluid in Browser DOM




Stacktrace: 
java.lang.RuntimeException: Data frame is too big. Cannot handle it. Implementation should be rewritten.
   at org.netbeans.modules.netserver.websocket.AbstractWSHandler7.readData(AbstractWSHandler7.java:353)
   at org.netbeans.modules.netserver.websocket.AbstractWSHandler7.readFinalFrame(AbstractWSHandler7.java:282)
   at org.netbeans.modules.netserver.websocket.AbstractWSHandler7.read(AbstractWSHandler7.java:126)
   at org.netbeans.modules.netserver.websocket.WebSocketServerImpl$WebSocketHandler.read(WebSocketServerImpl.java:207)
   at org.netbeans.modules.netserver.SocketFramework.readData(SocketFramework.java:179)
   at org.netbeans.modules.netserver.SocketFramework.process(SocketFramework.java:153)
Comment 1 Vladimir Riha 2014-07-04 12:25:26 UTC 
Created attachment 147882 [details]
stacktrace
Comment 2 Petr Jiricka 2014-07-18 11:46:48 UTC 
Tomas, any ideas what's going on here please?
Comment 3 Tomas Mysik 2014-07-18 12:05:15 UTC 
Sorry, likely I am not the proper guy to solve this issue (I know nothing about the code or websockets at all). Maybe Honza or David know?

Anyway, if there is really noone who can fix it, assign it to me but I cannot promise anything.
Comment 4 David Konecny 2014-07-21 09:56:08 UTC 
This was originally written by Denis. The error looks ominous! I have no idea how the internals of WebSocket server works.
Comment 5 Tomas Mysik 2014-07-21 10:55:35 UTC 
(In reply to David Konecny from comment #4)
> This was originally written by Denis.

Aha.

> The error looks ominous! I have no
> idea how the internals of WebSocket server works.

The same for me. OK, I will try to look at it...
Comment 6 David Konecny 2014-07-21 11:38:21 UTC 
I think the problem might be somewhere else - the requested size of the buffer is bigger than 2^32? There should not be such big resource to retrieve/post via WebSockets.
Comment 7 David Konecny 2014-07-21 11:59:29 UTC 
This is possible a bug in WebSockets impl in nightly build of Chrome 38. Or it is a WebSocket communication which is not handled correctly in the netserver module - hence the length of the buffer is wrong and invalid characters are passed into JSON deserialization (see issue 245410).
Comment 8 David Konecny 2014-07-21 12:00:22 UTC 
*** Bug 245410 has been marked as a duplicate of this bug. ***
Comment 9 Vladimir Riha 2014-07-24 17:13:39 UTC 
I tried it with Chrome 37 Beta and still reproducible, I got message as in issue 245410 when following steps from comment #2. More often the inspection simply crashes without any exception in IDE (IDE in some cases contains "Unexpected client data. Frame is not masked" - see issue 245411). 


Chrome Version 37.0.2062.35 beta-m (64-bit)
Product Version: NetBeans IDE Dev (Build 201407240001)
Java: 1.7.0_65; Java HotSpot(TM) 64-Bit Server VM 24.65-b04
Runtime: Java(TM) SE Runtime Environment 1.7.0_65-b19
System: Windows 7 version 6.1 running on amd64; Cp1252; en_US (nb)
Comment 10 Tomas Mysik 2014-07-28 07:21:53 UTC 
I cannot reproduce it with latest JDK7/JDK8 and Chromium Beta (v37). Marking as RANDOM. If there are exact steps to reproduce, please, let me know.

Thanks.
Comment 11 Vladimir Riha 2014-07-28 07:49:42 UTC 
Created attachment 148351 [details]
screencast

Here's a short screencast, maybe it will help. The CSS Styles window is not being populated after clicking on elements in browser, it could be related as it "generally" works.

Chromium 37.0.2062.20 Ubuntu 14.04 (283104)
Product Version: NetBeans IDE Dev (Build 201407280405)
Java: 1.8.0_05; Java HotSpot(TM) Client VM 25.5-b02
Runtime: Java(TM) SE Runtime Environment 1.8.0_05-b13
System: Linux version 3.13.0-32-generic running on i386; UTF-8; en_US (nb)
Comment 12 Tomas Mysik 2014-07-30 04:53:09 UTC 
Duplicate issue of #245410. There is a new WebSockets implementation in Chrome 37+.

*** This bug has been marked as a duplicate of bug 245410 ***