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? 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. 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
