|
From: Paul F. <pj...@wa...> - 2020-01-22 08:15:40
|
> On 19 Jan 2020, at 16:04, John Reiser <jr...@bi...> wrote: > >> ==== SB 2822 (evchecks 301498) [tid 1] 0x1005f5ecb __pthread_init+898 /usr/lib/system/libsystem_pthread.dylib+0xecb >> 0x1005F5ECB: call 0x1005FD7A6 >> 0x1005FD7A6: leaq 2759(%rip), %rcx >> 0x1005FD7AD: xorl %eax,%eax >> 0x1005FD7AF: movq %rcx,11002(%rip) >> 0x1005FD7B6: movq %rax,11043(%rip) >> 0x1005FD7BD: ud2 >> ==79936== valgrind: Unrecognised instruction at address 0x1005fd7bd. >> ==80006== at 0x1005FD7BD: __pthread_init.cold.2 (in /usr/lib/system/libsystem_pthread.dylib) > > The pthread library has detected an impossible situation regarding system calls, > and this is the calling sequence to report the fatal error to MacOS. > The bad emulation happened some time ago. > > See https://bugs.kde.org/show_bug.cgi?id=383723#c23 of 2.5 years ago where a similar ud2 > was found to result from an incomplete emulation of kevent_qos syscall. Hmm. In this case I don’t think that the open source Darwin code is going to help much. Perhaps now macOS is doing some chroot shenanigans, like iOS? A+ Paul |