Bug #7023
closedWTableView updates causes application to crash with exception "Wt internal error; code: undefined, description: Cannot read property 'parentNode' of null"
0%
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
Updated by Roel Standaert almost 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...?
Updated by Christopher Bilberg almost 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.
Updated by Roel Standaert almost 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)?
Updated by Roel Standaert almost 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?
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 almost 5 years ago
- File updateModel_pseudo.cpp updateModel_pseudo.cpp added
- File valgrind_wt_analysis.txt valgrind_wt_analysis.txt added
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
wt3branch (andmasterbranch) related to updates of a model when using aWTableView. 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?
Updated by Roel Standaert almost 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?
Updated by Christopher Bilberg almost 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?
Updated by Roel Standaert almost 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.
Updated by Christopher Bilberg almost 5 years ago
Okay, sounds good. Thank you for your fast response. It has been a great help!
Updated by Roel Standaert almost 5 years ago
- File InvisJS.cpp InvisJS.cpp added
- Status changed from InProgress to Resolved
I pushed a commit that should normally fix this issue.
I attached the test case that I used to reproduce and fix it.
Updated by Roel Standaert over 4 years ago
- Status changed from Resolved to Closed