Bug 416436

Summary:	Unrecognised instruction at address 0x1006037BD (__pthread_init.cold.2) macOS 10.15
Product:	[Developer tools] valgrind	Reporter:	Rhys Kidd <rhyskidd>
Component:	general	Assignee:	Rhys Kidd <rhyskidd>
Status:	CONFIRMED ---
Severity:	normal	CC:	jreiser, louis.brunner.fr
Priority:	NOR
Version First Reported In:	3.15 SVN
Target Milestone:	---
Platform:	macOS (DMG)
OS:	macOS
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:
Bug Depends on:
Bug Blocks:	412745
Attachments:	Valgrind verbose output Fix _pthread_init illegal instruction by providing ptr_munge

Description Rhys Kidd 2020-01-18 23:26:54 UTC

Created attachment 125232 [details]
Valgrind verbose output

SUMMARY
User bug report on macOS 10.15 Catalina, when compiled own valgrind with preliminary out-of-tree patches to support macOS 10.15. 

STEPS TO REPRODUCE
1. Compile master Valgrind + rebase https://github.com/LouisBrunner/valgrind-macos.git
2. ./vg-in-place -v --too=lackey pwd
3. Crash

OBSERVED RESULT
Debug log from bug reporter:

==6227== valgrind: Unrecognised instruction at address 0x1006037bd.
==6227==    at 0x1006037BD: __pthread_init.cold.2 (in /usr/lib/system/libsystem_pthread.dylib)
==6227==    by 0x10011472D: libSystem_initializer (in /usr/lib/libSystem.B.dylib)
==6227==    by 0x10002315C: ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==6227==    by 0x100023581: ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==6227==    by 0x10001DDC6: ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) (in /usr/lib/dyld)
==6227==    by 0x10001DD31: ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) (in /usr/lib/dyld)
==6227==    by 0x10001BE57: ImageLoader::processInitializers(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) (in /usr/lib/dyld)
==6227==    by 0x10001BEF7: ImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) (in /usr/lib/dyld)
==6227==    by 0x10000A66A: dyld::initializeMainExecutable() (in /usr/lib/dyld)
==6227==    by 0x10000FCCF: dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) (in /usr/lib/dyld)
==6227==    by 0x100009226: dyldbootstrap::start(dyld3::MachOLoaded const*, int, char const**, dyld3::MachOLoaded const*, unsigned long*) (in /usr/lib/dyld)
==6227==    by 0x100009024: _dyld_start (in /usr/lib/dyld)


EXPECTED RESULT


SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION
Bug reported on mailing list by Paul Floyd.

Comment 1 John Reiser 2020-01-19 19:49:20 UTC

The 'ud2' instruction is the calling convention to request that MacOS respond to a fatal error detected by run-time library code.  This is almost certainly a symptom that valgrind did not emulate a recent system call correctly.  See https://bugs.kde.org/show_bug.cgi?id=383723#c20 for a similar case more than 2 years ago.

Comment 2 Louis Brunner 2020-02-11 11:40:01 UTC

Created attachment 125843 [details]
Fix _pthread_init illegal instruction by providing ptr_munge

I have been investigating the problem and I have a fix (patch included).

Some context: it is difficult to be sure without the libpthread sources for 10.15, but if you check libpthread-330.250.2 (for 10.14), you will find a parse_ptr_munge_params function that tries to get ptr_munge value from the environment (through the Apple environment or an actual environment variable, PTHREAD_PTR_MUNGE_TOKEN). In previous versions, __pthread_init would just carry on even if the value wasn't defined, but while stepping through the code, I have found that macOS 10.15 seems to crash using the ud2 instruction just after the environment variable check, hinting that this value is now required.

My patch adds PTHREAD_PTR_MUNGE_TOKEN with a value of 1 everytime valgrind starts a program. Note that a value of 0 is considered an error by pthread.

Disclaimer: while I found where ptr_munge is generated (kernel) and used (some kind of conversion in jmp instructions in libplatform), I don't understand what it does exactly. On the other hand, the dummy value doesn't seem to make a difference when executing a program with valgrind.