Page MenuHomePhabricator

eina list javascript leak
Open, NormalPublic

Description

using v8 / nodejs bindings call to efl.Evas.ObjectSmart seems to be leaking references to object members quite possibly as a consequence of eina_list not being freed when gc is being called. problem seems generic and affects current master. tested on x86_64 using following build flags:

--disable-silent-rules --disable-dependency-tracking --disable-physics --enable-i-really-know-what-i-am-doing-and-that-this-will-probably-break-things-and-i-will-fix-them-myself-and-send-patches-abb --disable-audio --disable-xinput2 --disable-xim --with-tests=none --with-x11=none --with-js=libv8 --disable-nls --disable-audio --disable-physics --disable-multisense --disable-libeeze --with-x11=none --disable-image-loader-pmaps --disable-image-loader-psd --disable-image-loader-tga --disable-image-loader-wbmp --disable-image-loader-webp --disable-image-loader-xpm --disable-image-loader-tgv --disable-image-loader-dds --disable-avahi --enable-cxx-bindings --disable-doc --disable-egl --disable-gstreamer --disable-gstreamer1 --disable-lua-old --disable-lua-old --disable-pulseaudio --disable-systemd --enable-wayland --disable-wayland-ivi-shell

following test

produces a leak of few MB per second (artificially increased) and ends up in a crash

Related Objects

buniofh created this task.Aug 23 2016, 5:18 AM
buniofh updated the task description. (Show Details)
vitor.sousa added a subscriber: vitor.sousa.
lauromoura added a comment.EditedAug 25 2016, 1:00 PM

Hi @buniofh . I managed to reproduce the error and indeed there seems to be an issue when getting the members of a smart object. I'm working on it.

On a side note, to make the example work with the latest code I replaced ObjectSmart with Efl.Canvas.Group and getMembers with iterateGroupChildren, along other minor stuff.

Oops. Link to the updated example:

hola @lauromoura , I did some debugging and think the problem is more general and comes down to v8 having a single entry for v8::Persistent::SetWeak() notification callback. called for the same v8 object that would cause a leak at efl::js level.

and I need to correct myself, did some more tests on the matter and it seems ptr's for the Persistents are the same which lead me to believe they are overrun but apparently Persistent is destroyed and callback for it simply not called.

buniofh added a subscriber: Poopi.Aug 29 2016, 12:06 AM

nodejs object wrap includes v8::Persistent::MakeIndependent() call to alongside SetWeak(). node::ObjectWrap::MakeWeak(). seems like after that callbacks are being called as expected.

buniofh added a comment.EditedSep 8 2016, 12:58 AM

seems I fixed it, for your review

I changed the patchset cause I went a little overboard with make_persistent, it didn't work for non-exposed globals. I'll correct it to include that because now the patchset doesn't account for exposed objects v8::GlobalHandles::Node leak - every wrapped eo using eolian constructor will create a persistent which will never be reset thus leaking inside v8.

think the best way to go is to move current make_persistent into global_ref as a local inline and create a new of the form I had earlier.

this one covers different make_persistent for globals. however... nice solution would involve a double reffed class which is weak only when not reffed from C++. this way globals would be always kept as persistents with ref>=1 and all others would simply have 0. similar solution is used in aforementioned node wrapper class.

stefan_schmidt triaged this task as Normal priority.Feb 10 2017, 6:56 AM
zmike edited projects, added Restricted Project; removed efl.Jun 11 2018, 6:59 AM
zmike removed a project: Restricted Project.Jun 11 2018, 9:24 AM