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.

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

Reply via email to