This bug's crashes happen during calls (in system code) to `libobjc.A.dylib`'s [`objc_addExceptionHandler`](https://github.com/apple-oss-distributions/objc4/blob/objc4-818.2/runtime/objc-exception.mm#L1160). This calls [`findHandler`](https://github.com/apple-oss-distributions/objc4/blob/objc4-818.2/runtime/objc-exception.mm#L1042), which attempts to find existing exception handlers by using the current instruction pointer to walk up the call stack. This bug's crashes happen during one of the ["steps" up the call stack](https://github.com/apple-oss-distributions/libunwind/blob/libunwind-201/libunwind/src/UnwindCursor.hpp#L2007). Specifically they happen when `libunwind.dylib` is trying to [decode a Dwarf "Frame Description Entry"](https://github.com/apple-oss-distributions/libunwind/blob/libunwind-201/libunwind/src/DwarfParser.hpp#L157), at the following line: `pint_t cfiLength = (pint_t)addressSpace.get32(p);` This is because `decodeFDE` is being called with a zero `fdeStart` parameter. (Note that this parameter is in the `$X0` register. The `addressSpace` parameter is compiled away because it always points to the same, static object.) The value of `fdeStart` comes from the lowest 24 bits of `_info.format` [here](https://github.com/apple-oss-distributions/libunwind/blob/libunwind-201/libunwind/src/UnwindCursor.hpp#L1063). `_info.format` ultimately gets set ([here](https://github.com/apple-oss-distributions/libunwind/blob/libunwind-201/libunwind/src/UnwindCursor.hpp#L1843)) to an "encoding" from the compact unwind section (`__unwind_info`) of the `__TEXT` segment. The 4 bits at `0x0F000000` determine what kind of unwind information the encoding refers to. `0x03000000` indicates Dwarf information, which is actually in another section (`__eh_frame`) of the `__TEXT` segment. In this case the lowest 24 bits are (or should be) an offset into the `__eh_frame` section. (See https://github.com/apple-oss-distributions/libunwind/blob/libunwind-201/libunwind/include/mach-o/compact_unwind_encoding.h for more information.) Here are some examples of Dwarf "encodings" from `XUL`'s `__unwind_info` section created by `ld64` on an Apple Silicon machine (from the output of `objdump -u XUL`): ``` [787]: function offset=0x000bb480, encoding[125]=0x03000014 [757]: function offset=0x00255bb8, encoding[126]=0x03000060 [758]: function offset=0x00255c28, encoding[125]=0x030000a8 ``` And here are some from `XUL`s `__unwind_info` section created by `lld`: ``` [824]: function offset=0x000bb480, encoding[24]=0x03000000 [793]: function offset=0x00255bd8, encoding[24]=0x03000000 [962]: function offset=0x0030ab9c, encoding[24]=0x03000000 ``` Notice that the offsets from `lld` are all `0`. This is the bug in `lld`, and the reason these crashes happen.
Bug 1782160 Comment 16 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
This bug's crashes happen during calls (in system code) to `libobjc.A.dylib`'s [`objc_addExceptionHandler`](https://github.com/apple-oss-distributions/objc4/blob/objc4-818.2/runtime/objc-exception.mm#L1160). This calls [`findHandler`](https://github.com/apple-oss-distributions/objc4/blob/objc4-818.2/runtime/objc-exception.mm#L1042), which attempts to find existing exception handlers by using the current instruction pointer to walk up the call stack. This bug's crashes happen during one of the ["steps" up the call stack](https://github.com/apple-oss-distributions/libunwind/blob/libunwind-201/libunwind/src/UnwindCursor.hpp#L2007). Specifically they happen when `libunwind.dylib` is trying to [decode a Dwarf "Frame Description Entry"](https://github.com/apple-oss-distributions/libunwind/blob/libunwind-201/libunwind/src/DwarfParser.hpp#L157), at the following line: `pint_t cfiLength = (pint_t)addressSpace.get32(p);` This is because `decodeFDE()` is being called with a zero `fdeStart` parameter. (Note that this parameter is in the `$X0` register. The `addressSpace` parameter is compiled away because it always points to the same, static object.) The value of `fdeStart` comes from the lowest 24 bits of `_info.format` [here](https://github.com/apple-oss-distributions/libunwind/blob/libunwind-201/libunwind/src/UnwindCursor.hpp#L1063). `_info.format` ultimately gets set ([here](https://github.com/apple-oss-distributions/libunwind/blob/libunwind-201/libunwind/src/UnwindCursor.hpp#L1843)) to an "encoding" from the compact unwind section (`__unwind_info`) of the `__TEXT` segment. The 4 bits at `0x0F000000` determine what kind of unwind information the encoding refers to. `0x03000000` indicates Dwarf information, which is actually in another section (`__eh_frame`) of the `__TEXT` segment. In this case the lowest 24 bits are (or should be) an offset into the `__eh_frame` section. (See https://github.com/apple-oss-distributions/libunwind/blob/libunwind-201/libunwind/include/mach-o/compact_unwind_encoding.h for more information.) Here are some examples of Dwarf "encodings" from `XUL`'s `__unwind_info` section created by `ld64` on an Apple Silicon machine (from the output of `objdump -u XUL`): ``` [787]: function offset=0x000bb480, encoding[125]=0x03000014 [757]: function offset=0x00255bb8, encoding[126]=0x03000060 [758]: function offset=0x00255c28, encoding[125]=0x030000a8 ``` And here are some from `XUL`s `__unwind_info` section created by `lld`: ``` [824]: function offset=0x000bb480, encoding[24]=0x03000000 [793]: function offset=0x00255bd8, encoding[24]=0x03000000 [962]: function offset=0x0030ab9c, encoding[24]=0x03000000 ``` Notice that the offsets from `lld` are all `0`. This is the bug in `lld`, and the reason these crashes happen.