hi Anton, Iam running the standard test view-source:http://dromaeo.com/tests/dom-modify.html so i assume the test itself does not have any leaks.
On Tue, Oct 26, 2010 at 11:13 PM, Anton Muhin <[email protected]> wrote: > Good day, Zaheer. > > Thanks a lot for looking into it. > > However, I cannot immediately see how taking this path can make things > leak. And what exactly do you mean by leak here? The webcore strings allocated in ret = document.createTextNode(str); call are not being collected in the GC > Newly allocated > stringResource would be only deallocated when V8 JS String object > (referenced by v8String handle here) would go away, but that > eventually should happen for most of the objects, and if it won't > happen, typically v8 or script have good reasons to keep this object > for a long enough time. > The webcore string allocated for the argument str in document.createTextNode(str); is not going through this patch (ie. it doesnt create a string resource). Do you see any reason why it would be not marked as external from v8 engine? I think an easier think to check at your side would be run this test http://dromaeo.com/?dom and verify if there is no memory bloat. > > yours, > anton. > > On Tue, Oct 26, 2010 at 9:08 PM, Zaheer Ahmad <[email protected]> > wrote: > > hi Anton, > > Started to look at this furthur.. I can confirm GC gets triggered between > > the tests..I suspect leak happens in the else part - could you check my > > comments. > > Thanks, > > Zaheer > > WebCore/bindings/v8/V8Binding.cpp > > template <typename StringType> > > StringType v8StringToWebCoreString(v8::Handle<v8::String> v8String, > > ExternalMode external) > > { > > WebCoreStringResource* stringResource = > > WebCoreStringResource::toStringResource(v8String); > > if (stringResource) > > return > StringTraits<StringType>::fromStringResource(stringResource); > > int length = v8String->Length(); > > if (!length) { > > // Avoid trying to morph empty strings, as they do not have > enough > > room to contain the external reference. > > return StringImpl::empty(); > > } > > StringType result(StringTraits<StringType>::fromV8String(v8String, > > length)); >> string allocated here > > if (external == Externalize && v8String->CanMakeExternal()) { > > stringResource = new WebCoreStringResource(result); > > if (!v8String->MakeExternal(stringResource)) { >> resource > tracked > > by the v8 heap > > // In case of a failure delete the external resource as it > was > > not used. > > delete stringResource; > > } > > }else { > > __android_log_print(ANDROID_LOG_DEBUG, "hmm", > > "hmmmmmmmmmmmmmmmmmmmm"); >> leak happens if it goes here, I guess at > this > > point its not tracked by the heap, > > } > > return result; > > } > > > > > > On Thu, Oct 7, 2010 at 8:29 PM, Zaheer Ahmad <[email protected]> > wrote: > >> > >> On Thu, Oct 7, 2010 at 8:19 PM, Anton Muhin <[email protected]> > wrote: > >>> > >>> And what is amount of available RAM? > >> > >> 256M and the froyo is the initial version released in July i guess. > >>> > >>> yours, > >>> anton. > >>> > >>> On Thu, Oct 7, 2010 at 6:49 PM, Anton Muhin <[email protected]> > wrote: > >>> > On Thu, Oct 7, 2010 at 6:42 PM, Zaheer Ahmad <[email protected]> > >>> > wrote: > >>> >> On Thu, Oct 7, 2010 at 6:20 PM, Anton Muhin <[email protected]> > >>> >> wrote: > >>> >>> > >>> >>> On Thu, Oct 7, 2010 at 9:29 AM, Zaheer Ahmad <[email protected] > > > >>> >>> wrote: > >>> >>> > On Wed, Oct 6, 2010 at 7:50 PM, Anton Muhin <[email protected] > > > >>> >>> > wrote: > >>> >>> >> > >>> >>> >> That sounds bad. How do you run dromaeo? > >>> >>> > > >>> >>> > go to http://dromaeo.com/ and select DOM core tests > (modification > >>> >>> > and > >>> >>> > query > >>> >>> > test show the problem) > >>> >>> > >>> >>> Zaheer, I am curious what is HW you're using and what is the > browser. > >>> >>> In any event, that shouldn't be a problem with v8 per se, but > rather > >>> >>> with the way v8 is used in that browser. I'll try to sync up with > >>> >>> Android folks. > >>> >> > >>> >> Iam using android on a variant of bravo device with froyo. > >>> > > >>> > Thanks a lot. What is the exact version of Froyo? > >>> > > >>> >>> > >>> >>> > > >>> >>> >> > >>> >>> >> And what do you mean by 'to > >>> >>> >> track the caller on andriod'? > >>> >>> > > >>> >>> > I mean the call trace which is leaking. > >>> >>> > >>> >>> What do you mean by call trace which is leaking? Note that it's > not > >>> >>> like C++, leak means that GC for some reason failed to collect > >>> >>> already > >>> >>> unused objects. There are some tools which allow you to trace > leaks, > >>> >>> but they are usually not exposed to the user. > >>> >> > >>> >> Actually andriod does have pretty good call tracing capability :) > >>> >> here's the > >>> >> trace..as you can see its 43Meg [And btw i see this in a older > version > >>> >> of v8 > >>> >> too - the one in the froyo initial baseline] > >>> >> Allocations: 20886 > >>> >> Size: 2088 > >>> >> Total Size: 43609968 > >>> >> 8000b4c4 /system/lib/libc_malloc_debug_leak.so --- > leak_malloc > >>> >> --- > >>> >> > /local/mnt/workspace/froyo/bionic/libc/bionic/malloc_debug_leak.c:514 > >>> >> afd0cd40 /system/lib/libc.so --- afd0cd40 --- > >>> >> a836ce92 /system/lib/libwebcore.so --- > WTF::fastMalloc(unsigned > >>> >> int) > >>> >> --- > >>> >> > >>> >> > /local/mnt/workspace/froyo/external/webkit/JavaScriptCore/wtf/FastMalloc.cpp:239 > >>> >> a840d9de /system/lib/libwebcore.so --- > >>> >> WebCore::StringImpl::createUninitialized(unsigned int, unsigned > >>> >> short*&) --- > >>> >> > >>> >> > /local/mnt/workspace/froyo/external/webkit/WebCore/platform/text/StringImpl.cpp:938 > >>> >> a8484f42 /system/lib/libwebcore.so --- > >>> >> WTF::PassRefPtr<WebCore::StringImpl>::releaseRef() const --- > >>> >> > >>> >> > /local/mnt/workspace/froyo/external/webkit/JavaScriptCore/wtf/PassRefPtr.h:75 > >>> >> a84850a4 /system/lib/libwebcore.so --- > >>> >> > >>> >> > WebCore::StringTraits<WebCore::String>::fromV8String(v8::Handle<v8::String>, > >>> >> int) --- > >>> >> > >>> >> > /local/mnt/workspace/froyo/external/webkit/WebCore/bindings/v8/V8Binding.cp > >>> >> a84858d2 /system/lib/libwebcore.so --- > >>> >> WebCore::v8ValueToWebCoreString(v8::Handle<v8::Value>) --- > >>> >> > >>> >> > /local/mnt/workspace/froyo/external/webkit/WebCore/bindings/v8/V8Binding.cpp:133 > >>> >> a85822a2 /system/lib/libwebcore.so --- > >>> >> WebCore::V8Parameter<(WebCore::V8ParameterMode)0>::operator > >>> >> WebCore::String() --- > >>> >> > >>> >> > /local/mnt/workspace/froyo/external/webkit/WebCore/bindings/v8/V8Binding.h:199 > >>> >> a8595c8a /system/lib/libwebcore.so --- > >>> >> WebCore::DocumentInternal::createTextNodeCallback(v8::Arguments > >>> >> const&) --- > >>> >> > >>> >> > /local/mnt/workspace/froyo/out/target/product/qsd8250_ffa/obj/STATIC_LIBRARIES/libweb > >>> >> a8609bee /system/lib/libwebcore.so --- v8::internal::Object* > >>> >> v8::internal::HandleApiCallHelper<false>(v8::internal::(anonymous > >>> >> > namespace)::BuiltinArguments<(v8::internal::BuiltinExtraArguments)1>) > >>> >> --- > >>> >> a8609c48 /system/lib/libwebcore.so --- > >>> >> v8::internal::Builtin_HandleApiCall(v8::internal::(anonymous > >>> >> > namespace)::BuiltinArguments<(v8::internal::BuiltinExtraArguments)1>) > >>> >> --- > >>> >> /local/mnt/workspace/froyo > >>> >> Regards, > >>> >> Zaheer > >>> > > >>> > In many cases OOMs are due to v8 exhausting its heap which v8 manages > >>> > not via malloc. Even for WebCore data structures, they are often > >>> > retained from JS wrappers. So, even though malloc tracing is quite > >>> > helpful in many cases, esp. when the whole memory is managed via > C/C++ > >>> > memory management system, it won't give you the whole picture, esp. > in > >>> > the case when v8 is involved. > >> > >> Yes, i was not sure if its a leak or a behavior that happens by design > >> [the tests are crazy in that they do things in tight loops so it usually > >> doesnt represent a problem in a normal case]. Its quite strange that JSC > >> doesnt have this problem though [since they should also be creating text > >> nodes as in the trace] > >>> > >>> > > >>> > yours, > >>> > anton. > >>> > > >>> >> > >>> >>> > >>> >>> yours, > >>> >>> anton. > >>> >>> > >>> >>> > Thanks, > >>> >>> > Zaheer > >>> >>> >> > >>> >>> >> On Wed, Oct 6, 2010 at 6:03 PM, Zaheer Ahmad > >>> >>> >> <[email protected]> > >>> >>> >> wrote: > >>> >>> >> > dromaeo usally runs on android the last time i checked with v8 > >>> >>> >> > and > >>> >>> >> > currently > >>> >>> >> > the OOM gets invoked and browser is killed (i presume a GC > would > >>> >>> >> > interfere > >>> >>> >> > before that). i just checked JSC works fine. so most probably > >>> >>> >> > its an > >>> >>> >> > issue. > >>> >>> >> > is there a easy way to track the caller on android? > >>> >>> >> > Thanks, > >>> >>> >> > Zaheer > >>> >>> >> > > >>> >>> >> > On Wed, Oct 6, 2010 at 7:08 PM, Anton Muhin > >>> >>> >> > <[email protected]> > >>> >>> >> > wrote: > >>> >>> >> >> > >>> >>> >> >> Are you sure it's a leak? v8 uses GC and time when it > collects > >>> >>> >> >> garbage is roughly unpredictable. > >>> >>> >> >> > >>> >>> >> >> yours, > >>> >>> >> >> anton. > >>> >>> >> >> > >>> >>> >> >> On Wed, Oct 6, 2010 at 5:07 PM, Zaheer Ahmad > >>> >>> >> >> <[email protected]> > >>> >>> >> >> wrote: > >>> >>> >> >> > hi, > >>> >>> >> >> > Iam running dromaeo tests with latest BE (oct-1) and DOM > >>> >>> >> >> > modification > >>> >>> >> >> > tests > >>> >>> >> >> > seem to leak a lot (40M in 5s). Is this a known issue? > >>> >>> >> >> > thanks, > >>> >>> >> >> > Zaheer > >>> >>> >> >> > > >>> >>> >> >> > -- > >>> >>> >> >> > v8-users mailing list > >>> >>> >> >> > [email protected] > >>> >>> >> >> > http://groups.google.com/group/v8-users > >>> >>> >> >> > >>> >>> >> >> -- > >>> >>> >> >> v8-users mailing list > >>> >>> >> >> [email protected] > >>> >>> >> >> http://groups.google.com/group/v8-users > >>> >>> >> > > >>> >>> >> > -- > >>> >>> >> > v8-users mailing list > >>> >>> >> > [email protected] > >>> >>> >> > http://groups.google.com/group/v8-users > >>> >>> >> > >>> >>> >> -- > >>> >>> >> v8-users mailing list > >>> >>> >> [email protected] > >>> >>> >> http://groups.google.com/group/v8-users > >>> >>> > > >>> >>> > -- > >>> >>> > v8-users mailing list > >>> >>> > [email protected] > >>> >>> > http://groups.google.com/group/v8-users > >>> >>> > >>> >>> -- > >>> >>> v8-users mailing list > >>> >>> [email protected] > >>> >>> http://groups.google.com/group/v8-users > >>> >> > >>> >> -- > >>> >> v8-users mailing list > >>> >> [email protected] > >>> >> http://groups.google.com/group/v8-users > >>> > > >>> > >>> -- > >>> v8-users mailing list > >>> [email protected] > >>> http://groups.google.com/group/v8-users > > > > > -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
