PYTHON - KERN_INVALID_ADDRESS at 0xa90667faa9056ffc -> 0x000067faa9056ffc (possible pointer authentication failure)

Question

Created Apr ’22

Replies 1

Boosts 0

Views 1.8k

Participants 2

Seeing this crash info when trying to run my python application (full crash report is attached). Does anyone know what might be happening here?

Process: Python [5883] Path: /Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.8/Resources/Python.app/Contents/MacOS/Python

Identifier: Python

Version: 3.8.9 (3.8.9)

Build Info: python3-103000000000000~1538

Code Type: ARM-64 (Native)

Parent Process: Python [5881]

Responsible: iTerm2 [901]

User ID: 501

Date/Time: 2022-04-06 06:35:05.775 -0400 OS Version: macOS 11.6.2 (20G314) Report Version: 12 Anonymous UUID: F1B3654D-EF65-27C9-8D0C-4B1C82217421

Sleep/Wake UUID: 086CF930-9C99-4633-BEA1-2704C9016B77

Time Awake Since Boot: 2800 seconds Time Since Wake: 110 seconds

System Integrity Protection: enabled

Crashed Thread: 5

Exception Type: EXC_BAD_ACCESS (SIGSEGV)

Exception Codes: KERN_INVALID_ADDRESS at 0xa90667faa9056ffc -> 0x000067faa9056ffc (possible pointer authentication failure)

Exception Note: EXC_CORPSE_NOTIFY

Boost

Answer 1

DTS Engineer OP

Apple

Apr ’22

full crash report is attached

Thanks for that.

Consider this:

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0xa90667faa9056ffc …

The process has crashed because it tried to access invalid memory. Now look at the backtrace of the crashing thread:

Thread 5 Crashed:
0   ???                        … 0 + 114326275190780
1   libxml2.2.dylib            … xmlCharEncCloseFunc + 120
2   libxml2.2.dylib            … xmlOutputBufferClose + 108
3   etree.cpython-38-darwin.so … __pyx_f_4lxml_5etree__tostring + 1356
4   etree.cpython-38-darwin.so … __pyx_pw_4lxml_5etree_33tostring + 6224
5   com.apple.python3          … _PyObject_MakeTpCall + 372
6   com.apple.python3          … call_function + 448
7   com.apple.python3          … _PyEval_EvalFrameDefault + 23692
……
116 com.apple.python3          … _PyEval_EvalFrameDefault + 23424
117 com.apple.python3          … function_code_fastcall + 120
118 com.apple.python3          … method_vectorcall + 264
119 com.apple.python3          … PyVectorcall_Call + 104
120 com.apple.python3          … t_bootstrap + 80
121 com.apple.python3          … pythread_wrapper + 28
122 libsystem_pthread.dylib    … _pthread_start + 320
123 libsystem_pthread.dylib    … thread_start + 8

Frame 121 indicates that this a Python thread. The rest of the frames, all the way to 5, show the Python code running. In frame 4 Python has bounced out to native code. The library name contains etree, suggesting that this is code to support the etree module. At frame 2 that calls out to libxml2 which has then crashed.

The interesting thing is frame 0. That caused me to look at this:

Thread 5 crashed with ARM Thread State (64-bit):
    …
    sp: 0x000000016f84a170   pc: 0xa90667faa9056ffc …

Note that the pc register is the crashing address. In short, the native code has jumped to a completely bogus address.

You can see this code in the Darwin source for that routine for libxml2. Unfortunately the symbolication didn’t yield a line number, so it’s hard to see exactly what’s going on.

There’s one more complexity here:

Binary Images:
       …
       0x121188000 -        0x12126ffff +libxml2.2.dylib (0) 
       <7BBC6740-932A-3683-B442-8FE610931295> 
       /opt/homebrew/*/libxml2.2.dylib
       …
       0x1927f7000 -        0x1928e3fff  libxml2.2.dylib (34.10) 
       <87318271-CBFF-3BB1-9047-242A8752EAA3> 
       /usr/lib/libxml2.2.dylib

You have two copies of libxml2 loaded in your app. One is built in to the system itself and the other is something you added. Now look at this:

Thread 5 Crashed:
…
1   libxml2.2.dylib 0x0000000192815c8c xmlCharEncCloseFunc + 120
2   libxml2.2.dylib 0x00000001211b6f88 xmlOutputBufferClose + 108

This time I’ve not elided the addresses associated with the frames, so you can see that frame 1 is from the system copy of the library (0x192815c8c is in the range 0x1927f7000…0x1928e3fff) and frame 2 is from your copy (0x1211b6f88 is in the range 0x121188000…0x12126ffff). That’s quite worrying. In general, it’s not save to mix’n’match like that, especially on Apple silicon where the system frameworks are built for arm64e.

The last time I saw something like this it was because the third-party libraries were built with a flat namespace, something that I generally recommend against. See this thread for the details about that issue.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0