Project

General

Profile

Actions

Bug #7023

closed

WTableView updates causes application to crash with exception "Wt internal error; code: undefined, description: Cannot read property 'parentNode' of null"

Added by Christopher Bilberg over 5 years ago. Updated about 5 years ago.

Status:
Closed
Priority:
Urgent
Assignee:
Roel Standaert
Target version:
-
Start date:
05/01/2019
Due date:
% Done:

0%

Estimated time:

Description

We are using a WTableView widget to show live data in a table. When new data is received a postAll call is made to update the tables for all sessions, which inserts new rows in the table followed by a triggerUpdate call. This however causes the application to crash with the following error:

[error] "WApplication: JavaScript error: {""exception_description"":""Cannot read property 'parentNode' of null"",""exception_js"":"\"Wt.p.response(1900349351);{Wt3_3_12.remove('ogd7opp');Wt3_3_12.remove('ogd7oq1') ...

We are currently running Wt version 3.3.12. I tried to break on the exception and the problem seems to be that Wt tries to access an element which is non existing, resulting in a null element. The following lines seems to break the application (line 102-104 in the attached file):

var j100049 = Wt3_3_12.$('ovx3l77'); // j100049 = null

var j100050 = document.createElement('div');

j100049.parentNode.replaceChild(j100050, j100049); // Trying to get parenNode of null

Is there anything that can be done to solve/avoid this issue?


Files

parentNode_null_bug.js (124 KB) parentNode_null_bug.js Christopher Bilberg, 05/01/2019 09:21 AM
updateModel_pseudo.cpp (1.08 KB) updateModel_pseudo.cpp "Pseudo code" showing how the data is updated in the table. Christopher Bilberg, 05/03/2019 10:10 AM
valgrind_wt_analysis.txt (2.49 KB) valgrind_wt_analysis.txt Valgrind output Christopher Bilberg, 05/03/2019 10:10 AM
InvisJS.cpp (1.91 KB) InvisJS.cpp Roel Standaert, 07/11/2019 04:30 PM
Actions #1

Updated by Roel Standaert over 5 years ago

  • Status changed from New to InProgress
  • Assignee set to Roel Standaert

I don't suppose you have a bit of (preferably self-contained) code that can reproduce your issue?

Is this always an issue, or just sometimes, or only when you're scrolling the WTableView, or...?

Actions #2

Updated by Christopher Bilberg over 5 years ago

No, unfortunately not. The code as it is now, contains several dependencies. I can try to see if I can reproduce it in a small example.

It is not always an issue, but always happens after some time. It happens without any interaction with the application from the user (scrolling, clicking etc.) but when a server initiated event updates the WTableView.

Actions #3

Updated by Roel Standaert over 5 years ago

Are you only doing insertions of new rows or also some other modifications? There was a bug that is now fixed in the wt3 branch (and master branch) related to updates of a model when using a WTableView. That was a bug that caused memory errors, though. Do you have any of those (I don't know what platform you develop for, I use valgrind or address sanitizer on Linux)?

Actions #4

Updated by Roel Standaert over 5 years ago

I expect that the problem goes away with a higher two phase rendering threshold? It is set to 5000 bytes by default, but what happens if you set it to a megabyte or something?

https://www.webtoolkit.eu/wt/wt3/doc/reference/html/classWt_1_1WApplication.html#a63d991e268c9af8898329217a1242563

Can you confirm that that makes the problem go away? Of course, this shouldn't be a problem, but if you can confirm then I know a bit better where to look.

Updated by Christopher Bilberg over 5 years ago

Roel Standaert wrote:

Are you only doing insertions of new rows or also some other modifications? There was a bug that is now fixed in the wt3 branch (and master branch) related to updates of a model when using a WTableView. That was a bug that caused memory errors, though. Do you have any of those (I don't know what platform you develop for, I use valgrind or address sanitizer on Linux)?

We are inserting rows in the the top of the table, setting the data, and in case the number of rows exceeds a maximum number, the bottom rows are removed. I have attached a small piece of code showing how it is done.

I have tried to run it through valgrind (Wt 3.3.12) and there seems to be some memory leaks, yes. I did it previously, running on wt 3.3.4 where I don't remember seeing the same issues. I attached the valgrind output (10 blocks possibly lost and 2 blocks definitely lost), but maybe they are related to the fix on master?

Actions #6

Updated by Roel Standaert over 5 years ago

Thank you for clarifying how the model is being updated.

That valgrind output seems unrelated. Where memory is definitely lost, new is being called from the constructor of DispatcherApplication, not from Wt code. If you compile with sufficient debug info you should get line numbers in valgrind, too, but this leak seems unrelated.

The issue that I'm talking about did not cause leaks: it caused out of bounds memory accesses (undefined behavior).

Can you confirm that the issue disappears with a high two phase rendering threshold?

Actions #7

Updated by Christopher Bilberg over 5 years ago

Okay, I will try to look into that.

I have now tried to increase the two-phase rendering threshold and it does seem to fix the issue. I have increased it to 1 MB and am no longer able to reproduce the error. Seems like a reasonable workaround, thanks. Does it have any side-effects besides maybe increasing the latency of the visible rendering?

Actions #8

Updated by Roel Standaert over 5 years ago

It will cause pretty much every update to send all visible and invisible changes to the browser in one go, so you should only get a somewhat increased latency.

It should not introduce new issues, and it will actually reduce occurrence of issues like this. Of course, this is indeed still an issue and it should be fixed.

Actions #9

Updated by Christopher Bilberg over 5 years ago

Okay, sounds good. Thank you for your fast response. It has been a great help!

Actions #10

Updated by Roel Standaert over 5 years ago

I pushed a commit that should normally fix this issue.

I attached the test case that I used to reproduce and fix it.

Actions #11

Updated by Roel Standaert about 5 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF