Summary: | unhandled syscall: mach:41 (_kernelrpc_mach_port_guard_trap) | ||
---|---|---|---|
Product: | [Developer tools] valgrind | Reporter: | lou.salkind |
Component: | memcheck | Assignee: | Rhys Kidd <rhyskidd> |
Status: | RESOLVED FIXED | ||
Severity: | crash | CC: | rhyskidd |
Priority: | NOR | ||
Version: | 3.10 SVN | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | macOS | ||
See Also: | https://bugs.kde.org/show_bug.cgi?id=339745 | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: | Proposed patch |
Description
lou.salkind
2015-02-19 06:38:55 UTC
Refer related bug: https://bugs.kde.org/show_bug.cgi?id=339745 To solve this properly (as the PRE handler is already there in SVN trunk): 1. Review the comment after vg_assert(eq_SyscallStatus( &sci->status, &test_status )) at coregrind/m_syswrap/syswrap-main.c:1825 , and 2. Review the implementation of thread_fast_set_cthread_self. Created attachment 92918 [details]
Proposed patch
After reviewing osfmk/kern/syscall_sw.c and osfmk/mach/syscall_sw.h across OS X 10.8 - 10.10 it appears the #ifdef guard logic in Valgrind for the Mach syscalls across the interval [41,43] is incorrect. Am testing a proposed patch across each of those OS X releases, and may be able to simplify the logic further on OS X 10.9 specifically. Good news: I no longer get the unhandled syscall: mach:41 error with the patch. Bad news: valgrind now aborts later on because it can't decode an instruction: vex x86->IR: unhandled instruction bytes: 0x66 0xF 0x3A 0xB ==67715== valgrind: Unrecognised instruction at address 0x7ebb046. ==67715== at 0x7EBB046: __tanpi (in /usr/lib/system/libsystem_m.dylib) ==67715== by 0x58071F1: __CFBasicHashAddValue (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation) ==67715== by 0x5806BE5: CFBasicHashSetValue (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation) ==67715== by 0x5805F5C: CFDictionarySetValue (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation) ==67715== by 0x6F9F3C3: ___ZN18LSSharedMemoryPage16CopyForSessionIDE11LSSessionIDb_block_invoke11 (in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices) ==67715== by 0x7CAE56F: _dispatch_barrier_sync_f_invoke (in /usr/lib/system/libdispatch.dylib) ==67715== by 0x7CAE536: dispatch_barrier_sync_f (in /usr/lib/system/libdispatch.dylib) ==67715== by 0x7CB73D0: dispatch_barrier_sync (in /usr/lib/system/libdispatch.dylib) ==67715== by 0x6F9E71B: LSSharedMemoryPage::CopyForSessionID(LSSessionID, bool) (in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices) ==67715== by 0x6F9E482: LSSharedMemoryCopyForSessionID(LSSessionID, bool) (in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices) ==67715== by 0x6FAAE85: _LSCopyApplicationInformationItem (in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices) ==67715== by 0x8785032: __CGSNewConnection_block_invoke (in /System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics) ==67715== Your program just tried to execute an instruction that Valgrind ==67715== did not recognise. There are two possible reasons for this. ==67715== 1. Your program has a bug and erroneously jumped to a non-code ==67715== location. If you are running Memcheck and you just saw a ==67715== warning about a bad jump, it's probably your program's fault. ==67715== 2. The instruction is legitimate but Valgrind doesn't handle it, ==67715== i.e. it's Valgrind's fault. If you think this is the case or ==67715== you are not sure, please let us know and we'll try to fix it. ==67715== Either way, Valgrind will now raise a SIGILL signal which will ==67715== probably kill your program. ==67715== ==67715== Process terminating with default action of signal 11 (SIGSEGV) ==67715== Access not within mapped region at address 0xBF7FFFF4 ==67715== at 0x27794: SYSTEM_$$_REENABLE_SIGNAL$LONGINT$$BOOLEAN (in /Users/lou/idtest/build/ImageBrowser/i386-darwin-carbon/IDimagerSU) ==67715== If you believe this happened as a result of a stack ==67715== overflow in your program's main thread (unlikely but ==67715== possible), you can try to increase the size of the ==67715== main thread stack using the --main-stacksize= flag. ==67715== The main thread stack size used in this run was 8388608. Lou, great to confirm. That later issue is already being tracked in this bug report: https://bugs.kde.org/show_bug.cgi?id=346023. Resolved in r15297. |