Re: [v8-users] Possible reasons of Runtime_StackGuard

2019-03-13 Thread Jakob Kummerow 
To get debug symbols, you need a Debug build of V8 (or at least a Release
build with symbols). You can compile one yourself, see
https://v8.dev/docs/build-gn.

If possible, recreating the situation in a desktop application will
probably make debugging easier -- but I realize that for debugging a large
existing Android application, that might not be an option.

Is there a way for you to see stdout/stderr? V8_Fatal should print a
message before terminating the process, which should indicate which CHECK
has failed.


On Wed, Mar 13, 2019 at 7:33 AM Alexey Shcherbyna 
wrote:

> Hi Jacob, thank you for response.
>
> I understood the main error because I tried to use libv8-nosnapshot from
> old v8 version. I use v8 7.2.504, I have removed old no snapshot and added
> libv8_external_snapshot from this repository
>
> https://github.com/NativeScript/android-runtime
>
> https://github.com/NativeScript/android-runtime/tree/master/test-app/runtime/src/main/libs/arm64-v8a
> (they have updated to 7.3.4xx today
>
>
> I run it on Android device so I am not sure how to use debug  or enable
> symbols, I would appreciate very much if you could suggest where to find
> info how to do that.
>
> After I removed nosnapshot and added external snapshot , I see different
> error on the same place on gc moment
>
>
> v8::base::OS::Abort() 0x00736b999598
> V8_Fatal(char const*, int, char const*, ...) 0x00736b99873c
> v8::internal::GlobalHandles::InvokeFirstPassWeakCallbacks()
> 0x00736b2cd1a8
> v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector,
> v8::GCCallbackFlags) 0x00736b2d8148
> v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace,
> v8::internal::GarbageCollectionReason, v8::GCCallbackFlags)
> 0x00736b2d6894
> v8::internal::Heap::HandleGCRequest() 0x00736b2d58c0
> v8::internal::StackGuard::HandleInterrupts() 0x00736b2a57bc
> v8::internal::Runtime_StackGuard(int, unsigned long*,
> v8::internal::Isolate*) 0x00736b7fffb4
> Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_NoBuiltinExit
> 0x00736b91d16c
>  0x00735aea743c
> Builtins_InterpreterEntryTrampoline 0x00736b870794
> And so on "Trampolines"
> ...
>
> Any suggestion appreciated very much
> Thank you
>
>
> вторник, 5 марта 2019 г., 4:24:19 UTC+2 пользователь Jakob Kummerow
> написал:
>>
>> Runtime_StackGuard is the mechanism by which execution of (interpreted or
>> optimized) JavaScript code is interrupted by C++ code. From the next few
>> stack frames you can deduce the reason an interruption was requested:
>> generated code had performed enough allocations that it was time to do a
>> round of GC.
>>
>> The stack guard triggering mechanism is unrelated to the bug. The top 3
>> frames tell you that you've run into a CHECK/DCHECK failure in
>> DispatchPendingPhantomCallbacks; so the problem is likely related to weak
>> persistent handles with finalizer callbacks. The current V8 source doesn't
>> even have that function any more, and you didn't specify which version of
>> V8 you're using, so I can't make any further guesses. With a Debug (or at
>> least symbol-enabled) build you should be able to figure out which check is
>> failing, which should provide some information about where the bug is.
>>
>>
>> On Sun, Mar 3, 2019 at 10:03 AM Alexey Shcherbyna 
>> wrote:
>>
>>> Hi group
>>>
>>> I try to figure out possible issues in game engine using updated V8.
>>> Runtime_StackGuard error caught sometimes if run all functions together
>>> without pauses. Complete stack trace is
>>>
>>> v8::base::OS::Abort() 0x007375db9dec
>>> V8_Fatal(char const*, int, char const*, ...) 0x007375db9010
>>> v8::internal::GlobalHandles::DispatchPendingPhantomCallbacks(bool)
>>> 0x0073757f49a0
>>> v8::internal::GlobalHandles::PostGarbageCollectionProcessing(v8::
>>> internal::GarbageCollector, v8::GCCallbackFlags) 0x0073757f49f0
>>> v8::internal::Heap::PerformGarbageCollection(v8::internal::
>>> GarbageCollector, v8::GCCallbackFlags) 0x0073757fe868
>>> v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::
>>> internal::GarbageCollectionReason, v8::GCCallbackFlags)
>>> 0x0073757fcfc4
>>> v8::internal::Heap::HandleGCRequest() 0x0073757fc068
>>> v8::internal::StackGuard::HandleInterrupts() 0x0073757cca98
>>> v8::internal::Runtime_StackGuard(int, v8::internal::Object**, v8::
>>> internal::Isolate*) 0x007375d58e9c
>>>  0x00735a55c74c
>>> ...
>>>
>>>
>>>
>>> I understand that it is related either to gc incremental marking or to
>>> wrong Locker used somewhere or both. I try to find why this type of errors
>>> is called by can not figure out why. Please give me some tips why this
>>> usually happens.
>>>
>>> --
>>> --
>>> v8-users mailing list
>>> v8-u...@googlegroups.com
>>> http://groups.google.com/group/v8-users
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "v8-users" group.
>>> To unsubscribe from this group and stop receiving

[v8-users] Re: [blink-dev] Intent to Ship: WebAssembly non-trapping float-to-int conversions

2019-03-13 Thread Adam Klein 
LGTM!

On Tue, Mar 12, 2019 at 5:31 PM Ben Smith  wrote:

> Contact emails
>
> bi...@chromium.org
>
> Spec
>
> https://github.com/WebAssembly/nontrapping-float-to-int-conversions
> 
>
> Summary
>
> WebAssembly shipped with trapping float-to-int conversions, which are
> difficult for tools to use correctly, because the behavior differs from
> native machines. This proposal provides new instructions that are
> non-trapping equivalents of the original conversions.
>
>
> Interoperability and Compatibility risk
> This is a phase 4 WebAssembly proposal
> , so the compatibility risk is
> low.
>
> Edge: Implemented 
> Firefox: Shipped
> 
> Safari: No signals
>
> Is this feature fully tested?
>
> Yes, tested in wasm cctests:
> https://cs.chromium.org/chromium/src/v8/test/cctest/wasm/test-run-wasm.cc?l=3165.
> Also passes spec tests:
> https://github.com/WebAssembly/nontrapping-float-to-int-conversions/blob/master/test/core/conversions.wast#L252
>
>
> Tracking bug
>
> *https://crbug.com/v8/7226 *
>
>
> Entry on the feature dashboard 
>
> https://www.chromestatus.com/feature/4611843511287808
>
>
> Requesting approval to ship?
>
> Yes. Note that since this is a V8/Wasm feature, this post is just an FYI
> to blink-dev — no sign off from Blink API owners is required.
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/72c6d3c4-2e9a-43e2-ab6a-946a2ba7ec68%40chromium.org
> 
> .
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] Possible reasons of Runtime_StackGuard

2019-03-13 Thread Alexey Shcherbyna 
Hi Jacob, thank you for response. 

I understood the main error because I tried to use libv8-nosnapshot from 
old v8 version. I use v8 7.2.504, I have removed old no snapshot and added 
libv8_external_snapshot from this repository 

https://github.com/NativeScript/android-runtime
https://github.com/NativeScript/android-runtime/tree/master/test-app/runtime/src/main/libs/arm64-v8a
 
(they have updated to 7.3.4xx today


I run it on Android device so I am not sure how to use debug  or enable 
symbols, I would appreciate very much if you could suggest where to find 
info how to do that.

After I removed nosnapshot and added external snapshot , I see different 
error on the same place on gc moment


v8::base::OS::Abort() 0x00736b999598
V8_Fatal(char const*, int, char const*, ...) 0x00736b99873c
v8::internal::GlobalHandles::InvokeFirstPassWeakCallbacks() 
0x00736b2cd1a8
v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, 
v8::GCCallbackFlags) 0x00736b2d8148
v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, 
v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) 
0x00736b2d6894
v8::internal::Heap::HandleGCRequest() 0x00736b2d58c0
v8::internal::StackGuard::HandleInterrupts() 0x00736b2a57bc
v8::internal::Runtime_StackGuard(int, unsigned long*, 
v8::internal::Isolate*) 0x00736b7fffb4
Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_NoBuiltinExit 
0x00736b91d16c
 0x00735aea743c
Builtins_InterpreterEntryTrampoline 0x00736b870794
And so on "Trampolines"
...

Any suggestion appreciated very much
Thank you


вторник, 5 марта 2019 г., 4:24:19 UTC+2 пользователь Jakob Kummerow написал:
>
> Runtime_StackGuard is the mechanism by which execution of (interpreted or 
> optimized) JavaScript code is interrupted by C++ code. From the next few 
> stack frames you can deduce the reason an interruption was requested: 
> generated code had performed enough allocations that it was time to do a 
> round of GC.
>
> The stack guard triggering mechanism is unrelated to the bug. The top 3 
> frames tell you that you've run into a CHECK/DCHECK failure in 
> DispatchPendingPhantomCallbacks; so the problem is likely related to weak 
> persistent handles with finalizer callbacks. The current V8 source doesn't 
> even have that function any more, and you didn't specify which version of 
> V8 you're using, so I can't make any further guesses. With a Debug (or at 
> least symbol-enabled) build you should be able to figure out which check is 
> failing, which should provide some information about where the bug is.
>
>
> On Sun, Mar 3, 2019 at 10:03 AM Alexey Shcherbyna  > wrote:
>
>> Hi group
>>
>> I try to figure out possible issues in game engine using updated V8. 
>> Runtime_StackGuard error caught sometimes if run all functions together 
>> without pauses. Complete stack trace is
>>
>> v8::base::OS::Abort() 0x007375db9dec
>> V8_Fatal(char const*, int, char const*, ...) 0x007375db9010
>> v8::internal::GlobalHandles::DispatchPendingPhantomCallbacks(bool) 
>> 0x0073757f49a0
>> v8::internal::GlobalHandles::PostGarbageCollectionProcessing(v8::internal
>> ::GarbageCollector, v8::GCCallbackFlags) 0x0073757f49f0
>> v8::internal::Heap::PerformGarbageCollection(v8::internal::
>> GarbageCollector, v8::GCCallbackFlags) 0x0073757fe868
>> v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::
>> internal::GarbageCollectionReason, v8::GCCallbackFlags) 
>> 0x0073757fcfc4
>> v8::internal::Heap::HandleGCRequest() 0x0073757fc068
>> v8::internal::StackGuard::HandleInterrupts() 0x0073757cca98
>> v8::internal::Runtime_StackGuard(int, v8::internal::Object**, v8::
>> internal::Isolate*) 0x007375d58e9c
>>  0x00735a55c74c
>> ...
>>
>>
>>
>> I understand that it is related either to gc incremental marking or to 
>> wrong Locker used somewhere or both. I try to find why this type of errors 
>> is called by can not figure out why. Please give me some tips why this 
>> usually happens.
>>
>> -- 
>> -- 
>> v8-users mailing list
>> v8-u...@googlegroups.com 
>> http://groups.google.com/group/v8-users
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "v8-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to v8-users+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.