Memory leak for V8 based JS engines in OBJLoader #9679

Closed
Cobertos opened this Issue Sep 13, 2016 · 2 comments

Comments

Projects
None yet
2 participants
@Cobertos
Contributor

Cobertos commented Sep 13, 2016

I'm not sure if you guys are interested in specific javascript engine based fixes like this but I thought I might submit the bug anyway as I need to implement a fix locally for my application which targets V8. I'm running three.js in Chrome Version 53.0.2785.101 m (64-bit) on Windows x64 with three.js r80. This does not seem to affect Firefox which I also tested.

OBJLoader causes three.js to leak a lot of memory when loading large .obj files in a V8 based engine. It seems as though in V8 based javascript engines, sliced strings will keep a reference to their parent which in the case of the OBJLoader is a massive .obj text file. The actual sliced string with the parent reference comes from loading the objects name in OBJLoader. This is shown in Chrome's memory profiler below.

memoryleakv8

This bug/feature has been documented on the Chromium bug tracker but it hasn't really gone anywhere.

The user who posted the problem suggests a simple fix to remove the parent reference, which is attached in the referenced pull request (#9680). I tested that this does not leak in my project.

@mrdoob

This comment has been minimized.

Show comment
Hide comment
@mrdoob

mrdoob Sep 13, 2016

Owner

Hmm... I'll see if I can ping some people to give more priority to that Chromium bug...

Owner

mrdoob commented Sep 13, 2016

Hmm... I'll see if I can ping some people to give more priority to that Chromium bug...

@mrdoob mrdoob closed this Sep 14, 2016

@Cobertos

This comment has been minimized.

Show comment
Hide comment
@Cobertos

Cobertos Jul 7, 2017

Contributor

As an addendum, I was profiling in Firefox and this exact same thing happens. It seems there's a base property of JSString objects in the Firefox profiler that retain the entire string after slicing (while applying some string operations I get "left child" also). The fix above should work (I messed around with long strings and memory snapshots in the Firefox console and I got it to discard the background reference) but I'm still seeing this in my app.

I figure this might be useful knowledge for anyone who stumbles upon this issue.

image

Contributor

Cobertos commented Jul 7, 2017

As an addendum, I was profiling in Firefox and this exact same thing happens. It seems there's a base property of JSString objects in the Firefox profiler that retain the entire string after slicing (while applying some string operations I get "left child" also). The fix above should work (I messed around with long strings and memory snapshots in the Firefox console and I got it to discard the background reference) but I'm still seeing this in my app.

I figure this might be useful knowledge for anyone who stumbles upon this issue.

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment