-
Notifications
You must be signed in to change notification settings - Fork 571
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ASSERT dispatch.c:766 ks->depth > 2 && "stop_not_matching not allowed to clear kstack" #1140
Comments
From [email protected] on April 10, 2013 10:57:39 This issue was closed by revision r2044 . Status: Fixed |
From [email protected] on April 12, 2013 08:26:02 reopen it as it still fail on api.startstop on my machine. Status: Started |
From [email protected] on April 12, 2013 09:13:11 api.startstop calls to print function, which trigger the memory allocation system call ntdll!NtAllocateVirtualMemory The control is then transferred to dispatch with dcontext->last_exit pointing to the linkstub_native_exec_syscall => we came from a syscall hook that intends to stay native. The execution continue to handle_system_call, then then after the context switch The dcontext->last_exit is updated by in dispatch, dispatch_enter_dynamorio is called, and the assert is fired: |
From [email protected] on April 12, 2013 09:19:00 you're stepping through the wow64 "syscall": you must be using a 64-bit debugger the syscall enter-exit sequence should be ok b/c it should go through regular code that does KSTART on dispatch_num_exits so stack should not be empty when it comes back out. on a go-native sequence comes out empty (b/c it may not come out: so it clears kstack). |
From [email protected] on April 12, 2013 11:39:10 On calling ntdll!NtAllocateVirtualMemory, the control is transferred to dispatch. the value is decreased at dispatch_exit_fcache_stats: 0:000> ?? dcontext->thread_kstats->stack_kstats ChildEBP RetAddr00 2546ee2c 5ec97f22 dynamorio!dispatch_exit_fcache_stats+0x2624 [core\dispatch.c @ 1207] then the value is changed to 2 at dispatch_enter_dynamorio Later the the depth changes in pairs, i.e. START/STOP and finally end up in the assert, where depth is 2. |
From [email protected] on April 12, 2013 12:29:08 normal fcache entry does: both pops are avoided if we came from WHERE_APP which is fine if we next come to dispatch for dr_app_start dispatch_enter_native() for BACK_TO_NATIVE_AFTER_SYSCALL does: my fix seems incomplete: must have thought native_exec_syscalls went one way to fix for real: Owner: [email protected] |
From [email protected] on April 12, 2013 15:07:07 better fix: |
From [email protected] on April 13, 2013 20:42:26 still have problems. |
From [email protected] on April 13, 2013 20:57:37 Why do we have code in dispatch_enter_dynamorio like this:
It means dispatch_num_exits is start almost all the time. |
From [email protected] on April 07, 2014 11:45:16 Labels: Component-Tests |
From [email protected] on April 08, 2014 10:47:13 taking over after fixing issue #813 I fixed this one too: what I ended up doing was adding a check on KSWITCH_STOP_NOT_PROPAGATED for Owner: [email protected] |
From [email protected] on April 08, 2014 12:12:59 This issue was closed by revision r2640 . Status: Fixed |
From [email protected] on April 09, 2013 13:32:19
running startstop, in the main thread on entering dispatch on
dr_app_start().
05 00000000
bfe7eb70 00000000
15150141 dynamorio!internal_error+0x190 [d:\derek\dr\git\src\core\utils.c @ 190]06 00000000
bfe7ecf0 00000000
1514bf59 dynamorio!dispatch_enter_dynamorio+0xa61 [d:\derek\dr\git\src\core\dispatch.c @ 766]07 00000000
bfe7ee70 00000000
15360820 dynamorio!dispatch+0x19 [d:\derek\dr\git\src\core\dispatch.c @ 147]08 00000000
bfe7efe0 00000000
bfe61080 dynamorio!call_switch_stack+0x46 [D:\derek\dr\git\build_x64_dbg_tests\core\CMakeFiles\dynamorio.dir\x86\x86.asm.obj.s @ 1041]when we execute dr_app_stop() and go native we run this code:
dispatch_at_stopping_point():
KSTOP_NOT_MATCHING(dispatch_num_exits);
dr_app_start() should hit this in dispatch_enter_dynamorio():
KSTART_DC(dcontext, dispatch_num_exits);
so it thinks it's not the first entrance to DR, and thus dispatch_num_exits
should be on the kstats stack. but it is the first entrance.
0:000> ln @@(dcontext->last_exit)
(00000000
1546f81c) dynamorio!linkstub_native_exec_syscall | (00000000
1546f820) dynamorio!linkstub_shared_syscall_trace_fragmentExact matches:
dynamorio!linkstub_native_exec_syscall = struct _linkstub_t
0:000> ?? dcontext->next_tag
unsigned char * 0xffffffff`ffffffff
0:000> ?? dcontext->thread_record->under_dynamo_control
char 0n0 ''
=> we came from a syscall hook that intends to stay native.
normally, native_exec gateway xfer to native happens from code cache, so we
have dispatch_num_exits on kstack. but dr_app_stop() pops the kstack.
easiest solution: have entering_native() pop kstack
Original issue: http://code.google.com/p/dynamorio/issues/detail?id=1140
The text was updated successfully, but these errors were encountered: