Bug 1801419 Comment 12 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

(Following up comment #5)

You know, it's odd that a module that belongs to the dyld shared cache doesn't get loaded into the `firefox` process along with its other constituent modules, like `libobjc.A.dylib` and `AppKit`.
(Following up comment #5)

You know, it's odd that a module that belongs to the dyld shared cache doesn't get loaded into the `firefox` process along with its other constituent modules, like `libobjc.A.dylib` and `AppKit`.

It's just possible that Firefox could to work around these crashes by explicitly linking against `/System/Library/PrivateFrameworks/SidebandCore.framework/SidebandCore` on startup (using `dlopen()` or otherwise).
(Following up comment #5)

You know, it's odd that a module that belongs to the dyld shared cache doesn't get loaded into the `firefox` process along with its other constituent modules, like `libobjc.A.dylib` and `AppKit`.

It's just possible that Firefox could work around these crashes by explicitly linking against `/System/Library/PrivateFrameworks/SidebandCore.framework/SidebandCore` on startup (using `dlopen()` or otherwise).
(Following up comment #5)

You know, it's odd that a module that belongs to the dyld shared cache doesn't get loaded into the `firefox` process along with its other constituent modules, like `libobjc.A.dylib` and `AppKit`.

It's just possible that Firefox could work around these crashes by explicitly linking against `/System/Library/PrivateFrameworks/SidebandCore.framework/SidebandCore` on startup.
(Following up comment #5)

You know, it's odd that a module that belongs to the dyld shared cache doesn't get loaded into the `firefox` process along with its other constituent modules, like `libobjc.A.dylib` and `AppKit`.

It's just possible that Firefox could work around these crashes by explicitly linking against `/System/Library/PrivateFrameworks/SidebandCore.framework/SidebandCore`.
(Following up comment #5)

You know, it's odd that a module that belongs to the dyld shared cache doesn't get loaded into the `firefox` process along with its other constituent modules, like `libobjc.A.dylib` and `AppKit`.

It's just possible that Firefox could work around these crashes by explicitly linking against `/System/Library/PrivateFrameworks/SidebandCore.framework/SidebandCore`. `dlopen()` might not work. It's already being used by the `AppKit` framework (via `_NSSoftLinkingLoadFramework()`) to load `/System/Library/PrivateFrameworks/SidebandUI.framework/SidebandUI`, which itself is explicitly linked against `SidebandCore` (from the results of `otool -Lv SidebandUI`).
(Following up comment #5)

You know, it's odd that a module that belongs to the dyld shared cache doesn't get loaded into the `firefox` process along with its other constituent modules, like `libobjc.A.dylib` and `AppKit`.

It's just possible that Firefox could work around these crashes by explicitly linking against `/System/Library/PrivateFrameworks/SidecarCore.framework/SidecarCore`. `dlopen()` might not work. It's already being used by the `AppKit` framework (via `_NSSoftLinkingLoadFramework()`) to load `/System/Library/PrivateFrameworks/SidecarUI.framework/SidecarUI`, which itself is explicitly linked against `SidecarCore` (from the results of `otool -Lv SidecarUI`).
(Following up comment #5)

You know, it's odd that a module that belongs to the dyld shared cache doesn't get loaded into the `firefox` process along with its other constituent modules, like `libobjc.A.dylib` and `AppKit`.

It's just possible that Firefox could work around these crashes by explicitly linking against `/System/Library/PrivateFrameworks/SidecarCore.framework/SidecarCore`. `dlopen()` might not work. It's already being used by the `AppKit` framework (via `_NSSoftLinkingLoadFramework()`) to load `/System/Library/PrivateFrameworks/SidecarUI.framework/SidecarUI`, which itself is explicitly linked against `SidecarCore` (from the results of `otool -Lv SidecarUI`).

But in this context `dlopen()` is being called with `mode` == `RTLD_FIRST`. *That* might be the problem. If so, Firefox could work around these crashes by using `RTLD_NOW`, or perhaps `RTLD_LAZY`.

Back to Bug 1801419 Comment 12