Describe the bug
Within a tabbed page with a large b-table on each tab (~1500 rows), switching back and forth between the tabs too quickly will cause JVM memory usage to continue climbing until the browser tab and/or window crashes.
Steps to reproduce the bug
- Create a single page application within Vue.
- In the new application, create two components. Each component should be displayed within the SPA when clicking on their tab/link, and hidden when clicking on another component's tab. This should resemble a basic tab layout, such as a tab layout within a browser.
- Each component should have only a b-table within them. The items array can be hardcoded within the component, retrieved from a Vuex store, etc. The storage location of the items doesn't seem to make a difference.
- While monitoring the JVM memory, start to switch back and forth between the two components. JVM heap size will begin to climb, with no garbage collection occurring.
The b-table should only load the items into memory once. The b-table should reuse the values already within memory, rather than seemingly copying it to a new array.
- BootstrapVue: 2.21.2
- Vue: 2.6.14
- Vuex: 3.6.2
- Device: Multiple Dell laptops
- OS: Windows 10
- Browser: Chrome
- Version: 105.0.5195.125
This seems similar to Issue 5784. We are loading a couple large tables all at once for our users to scroll through, and while clicking back and forth between two tabs without reloading the page, we've managed to leak enough memory that Chrome would crash. Memory profiling shows a large array being duplicated and held in memory, which is never garbage collected until reloading the current page and cache.
Worth noting that wrapping the b-table in a tag seems to make garbage collection work as expected after some time, but doesn't stop memory usage from climbing. This also seems to prevent hitting enough memory usage that the browser will crash. My best guess is that there is some kind of race condition going on when loading and reloading the same table with a large data set, causing the in-memory values to get orphaned.
From troubleshooting, I can confirm that there was no orphaned DOM objects, nor was the table trying to fetch the item array again (when used with a Vuex store). Memory leaks still seemed to happen with smaller tables, but getting into pages that had longer loading times were more likely to develop a leak with the b-table. Removing the b-table from the components or removing the item array from the b-table removes the memory leak completely, which means it is related to management of the items.