While trying to run my program with valgrind on VMWare fusion VM that runs 10.12 whereas the host machine also runs the same OS, I got errors about unhanded syscall : --8450-- WARNING: unhandled amd64-darwin syscall: unix:463 --8450-- You may be able to write your own handler. --8450-- Read the file README_MISSING_SYSCALL_OR_IOCTL. --8450-- Nevertheless we consider this a bug. Please report --8450-- it at http://valgrind.org/support/bug_reports.html. --8450-- WARNING: unhandled amd64-darwin syscall: unix:463 --8450-- You may be able to write your own handler. --8450-- Read the file README_MISSING_SYSCALL_OR_IOCTL. --8450-- Nevertheless we consider this a bug. Please report --8450-- it at http://valgrind.org/support/bug_reports.html. it seems like this error comes from libsqlite, as I'm using it to initialize some table that reside in global variable object. --8450-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option --8450-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 2 times) --8450-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 4 times) --8450-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 8 times) ==8450== Syscall param mach_msg("rcv_name") contains uninitialised byte(s) ==8450== at 0x102DE634A: mach_msg_trap (in /usr/lib/system/libsystem_kernel.dylib) ==8450== by 0x102DE5796: mach_msg (in /usr/lib/system/libsystem_kernel.dylib) ==8450== by 0x102F823F2: _os_trace_prefs_and_mode_refresh_slow (in /usr/lib/system/libsystem_trace.dylib) ==8450== by 0x102F82500: os_log_create (in /usr/lib/system/libsystem_trace.dylib) ==8450== by 0x100FC4FF1: openDatabase (in /usr/lib/libsqlite3.dylib) ==8450== by 0x100FC3809: ??? (in /usr/lib/libsqlite3.dylib) ==8450== by 0x1000D02F8: Database::Database(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) (Database.cpp:10) ==8450== by 0x1000D05AC: Database::Database(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) (Database.cpp:9) ==8450== by 0x1000B8933: Table::Table(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) (Table.cpp:10) ==8450== by 0x100093AC5: ClientGenericEventsTable::ClientGenericEventsTable(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) (ClientGenericEventsTable.cpp:7) ==8450== by 0x1000941CC: ClientGenericEventsTable::ClientGenericEventsTable(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) (ClientGenericEventsTable.cpp:8) ==8450== by 0x100039EBC: __cxx_global_var_init.10 (ClientGenericEvents.cpp:5) I've seen a similar issue #376870, but I think my syscall is different. How can I trace its true name in order to write a wrapper for it (as described in README_MISSING_SYSCALL_OR_IOCTL)? thanks
I've also double checked the the unknown fcntl calls are actually made using dtruss, and it indeed trace those calls. Their corresponding cmd number appears in bsd/sys/fcntl.h in xnu project. #ifdef PRIVATE #define F_OFD_SETLK 90 /* Acquire or release open file description lock */ #define F_OFD_SETLKW 91 /* (as F_OFD_SETLK but blocking if conflicting lock) */ #define F_OFD_GETLK 92 /* Examine OFD lock */ #define F_OFD_SETLKWTIMEOUT 93 /* (as F_OFD_SETLKW but return if timeout) */ #define F_OFD_GETLKPID 94 /* get record locking information */ #define F_SETCONFINED 95 /* "confine" OFD to process */ #define F_GETCONFINED 96 /* is-fd-confined? */ #endif
Valgrind is reporting that a Unix syscall is missing on the Darwin platform. The syscall number can be found in /usr/include/sys/syscall.h on your local machine. You should find that unix:463 is "openat". For an example of the way in which Darwin syscalls are added in valgrind, take a look at the patch on https://bugs.kde.org/show_bug.cgi?id=379748.
I tried to follow the documentation in README_MISSING_SYSCALL_OR_IOCTL and the example from the other bug you pointed me, but I still getting the assertion from eq_SyscallStatus (the 'impossible' happened) the printouts from that method are {78 0 43} {78 0 40} any idea how to decipher these figures ?
irad, can you attach or link to the patch you wrote locally when trying to address the missing openat syscall? That will allow me to figure out why it is still not working for you.