You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
uftrace hope that functions follow the calling convention. but there is an exception like nodejs case. so, it is added restore-reset mechanism to uftrace. it still needs more precision.
I have two exceptional cases in v8 interpreter that uftrace crashed on.
reuse stack frame
v8 interpreter check the code objects which exist in javascript stack frame for some purpose. v8 interpreter use its own stack frame because it want to not affect to C stack frame. so, stack base frame does not changed in v8 interpreter logic. in this case, while v8 interpreter check the javascript stack frame, it find weird value mcount_return_fn that has been instrumented by uftrace. and occure crash.
let's see followed case:
d8> 1+1
Thread 2.1 "d8" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff2d90840 (LWP 118815)]
0x00005555555bd9bc in std::__Cr::__loadword<unsigned long> (__p=0x7ffff5580038) at ../../buildtools/third_party/libc++/trunk/include/utility:978
978 std::memcpy(&__r, __p, sizeof(__r));
(gdb) bt
#0 0x00005555555bd9bc in std::__Cr::__loadword<unsigned long> (__p=0x7ffff5580038) at ../../buildtools/third_party/libc++/trunk/include/utility:978
#1 0x00005555555d6ced in v8::base::AsAtomicImpl<long>::Relaxed_Load<unsigned long> (addr=0x7ffff5580038) at ../../src/base/atomic-utils.h:78
#2 0x00005555555d6bed in v8::internal::FullObjectSlot::Relaxed_Load (this=0x7fffffffb840) at ../../src/objects/slots-inl.h:43
#3 0x00007ffff6c0d294 in v8::internal::MemoryChunk::HasHeaderSentinel (slot_addr=140737310097407) at ../../src/heap/spaces-inl.h:209
#4 0x00007ffff6c0d1e5 in v8::internal::MemoryChunk::FromAnyPointerAddress (addr=140737310097407) at ../../src/heap/spaces-inl.h:213
#5 0x00007ffff6c072e1 in v8::internal::PagedSpace::Contains (this=0x55555569b8e0, addr=140737349680485) at ../../src/heap/spaces-inl.h:164
#6 0x00007ffff6bfd305 in v8::internal::Heap::GcSafeFindCodeForInnerPointer (this=0x5555568a8fe8, inner_pointer=140737349680485) at ../../src/heap/heap.cc:5699
#7 0x00007ffff7bbfd65 in __dentry__ () at /home/m/git/uftrace/arch/x86_64/dynamic.S:114
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
v8 interpreter crashed on here:
0x00007ffff6bfd305 in v8::internal::Heap::GcSafeFindCodeForInnerPointer (this=0x5555568a8fe8, inner_pointer=140737349680485) at ../../src/heap/heap.cc:5699
(gdb) p/x inner_pointer
$1 = 0x7ffff7bbfd65
(gdb) x/gx 0x7ffff7bbfd65
0x7ffff7bbfd65 <dynamic_return>: 0x245c894c60ec8348
as you can see, v8 interpreter working on same stack frame.
direct accessing previous RET
v8 interpreter does not follow calling convention as mention at first case. sometime v8 interpreter access previous stack frame directly. this used for read function arguments at normal case. but v8 interpreter access previous stack frame directly for read RET. this is not allowed in calling convention. in this time, mcount_return_fn address will be exist in RET because uftrace hook the RET to mcount_return_fn in reset function. so, v8 will crashed on.
Thread 2.1 "d8" hit Breakpoint 5, 0x00007ffff772ee24 in Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_NoBuiltinExit () from /home/m/git/v8/v8/out.gn/x64.debug/./libv8.so
$1 = 0x7fffffffcac8
so, rcx has 0x7fffffffcac8 + 0x8 = 0x7fffffffcad0.
let's see what value has stored in 0x7fffffffcad0.
uftrace hope that functions follow the calling convention. but there is an exception like nodejs case. so, it is added restore-reset mechanism to uftrace. it still needs more precision.
I have two exceptional cases in v8 interpreter that uftrace crashed on.
v8 interpreter check the code objects which exist in javascript stack frame for some purpose. v8 interpreter use its own stack frame because it want to not affect to C stack frame. so, stack base frame does not changed in v8 interpreter logic. in this case, while v8 interpreter check the javascript stack frame, it find weird value mcount_return_fn that has been instrumented by uftrace. and occure crash.
let's see followed case:
v8 interpreter crashed on here:
source codes :
v8 interpreter could not found the address of mcount_return_fn from its code object pool, obviously.
this is normal case:
see belowed instructions.
as you can see, v8 interpreter working on same stack frame.
v8 interpreter does not follow calling convention as mention at first case. sometime v8 interpreter access previous stack frame directly. this used for read function arguments at normal case. but v8 interpreter access previous stack frame directly for read RET. this is not allowed in calling convention. in this time, mcount_return_fn address will be exist in RET because uftrace hook the RET to mcount_return_fn in reset function. so, v8 will crashed on.
problem occurred at here:
value that keep in rcx register:
so, rcx has 0x7fffffffcac8 + 0x8 = 0x7fffffffcad0.
let's see what value has stored in 0x7fffffffcad0.
f
The text was updated successfully, but these errors were encountered: