Bug #7235
openJavaScript error - exception_description: Not enough storage is available to complete this operation.
0%
Description
We have experienced that our application sometimes crashes client-side with the following javascript exception:
exception_description: Not enough storage is available to complete this operation.
So far we have only seen this issue with users running Internet Explorer. Do you have an idea of what could maybe cause this problem and if there is a simple way to get around this problem?
Files
Updated by Roel Standaert over 4 years ago
- Status changed from New to Feedback
I think that means you are bumping up against the limits of Internet Explorer. How big are your responses? I've seen some sources suggest that as soon as your responses start to get 100 MiB in size, this happens, or just in general when Internet Explorer is using a lot of memory (over 1.2 GiB).
I don't know if this is a symptom of an actual problem in Wt, if your application is simply that large, or whether the users just have many tabs, or other particularly memory-hungry tabs open.
I see that this is a fairly heavy update, but not megabytes in size.
I also see that you are using Wt 3.3.12. Can you try with Wt 3.4.1? There was a client-side memory leak that was fixed in Wt 3.4.0.
Updated by Christopher Bilberg over 4 years ago
Thank you for you reply. Sounds reasonable. I'm not quite sure how big our response is itself. Is there a way to check that through Wt?
We haven't really been able to reproduce the problem but tried to update to Wt 3.4.1 and will see if it happens again with this version.
Updated by Roel Standaert over 4 years ago
It's logging the JavaScript code that was sent to the browser, so I can see that it's big, but not huge. I usually keep an eye on the network tab in the web browser's development tools. You can also export that log as a HAR file, which is what I often ask for when trying to get to the bottom of an issue that's hard to reproduce.
I've never seen this "Not enough storage is available..." error, though. I think if you don't see it with Wt 3.4.1 anymore, the most likely scenario is that it is due to that JavaScript memory leak I mentioned.
Updated by Christopher Bilberg over 4 years ago
Okay, that's a good start. I will try to do that.
The problem is that we don't really have access to the browser/ device where the issue occurred, so hard to say if it could happen again. We have seen this error more than once at least but let's hope it will not be a problem after upgrading to 3.4.1.
Updated by Roel Standaert over 4 years ago
Other than looking at the network tab, the access log of wthttp also logs the number of bytes in the response. It's the last number, after the status code. It will only log individual responses in the access log if not using WebSockets, though.
If you are using WebSockets, you can turn on debug logging for wthttp but that's very verbose. You can compile Wt with CMake option -DDEBUG=1 and set the log-config to * -debug debug:wthttp, and it will log (among many other things) a message that says "wthttp: ws: sending a messsage, length = ...".