What is the meaning of "*" in the procPath of a crash report?

Question

Kentzo OP

Created Jul ’24

Replies 1

Boosts 0

Participants 2

Recently Apple's remotepairingd crashed and the report had the following "Path":

/Library/Apple/*/RemotePairing.framework/Versions/A/XPCServices/remotepairingd.xpc/Contents/MacOS/remotepairingd

Why *? The actual path on disk is /Library/Apple/System/Library/PrivateFrameworks/RemotePairing.framework/Versions/A/XPCServices/remotepairingd.xpc/Contents/MacOS/remotepairingd.

Answered by DTS Engineer in 797755022

Why *? The actual path on disk is

I'm not sure of EXACTLY what happened here, but it was probably caused by one of two factors:

(Primary) One of the many details the symbolication handles is sanitizing files paths inside crash reports, primarily to remove any path that might be privacy sensitive. The details of that process can be quite involved and it's possible/likely that there are cases where it sanitizes data out that it didn't HAVE to.
(Secondary) For complicated reasons that I can't easily summarize, determining the exact path for a crashed process can be harder than it sounds. It's a situration where the "standard" approach works most of the time, followed by a bunch of weird edge cases that don't quite work. There's code in place that uses other APIs to cover those edge cases, but that "constructed" path can end up constructing paths like the one you're seeing.

In this particular case, I think this is an accidental side effect of unrelated checks inside #1. Arguably that's a bug, however, the EXACT path (particularly for system components) isn't all that relevant to the crash investigation process so it doesn't really matter. The basic "job" of the sanitization process is to remove any data while preserving enough information to determine the crashes basic "source" ("RemotePairing.framework") and what part of the system hierarchy it came from ("/Library/Apple"). As long as those to factor are met, hiding "too much" isn't really an issue.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Boost

Answer 1

DTS Engineer OP

Apple

Jul ’24

Accepted Answer

Recommended

Why *? The actual path on disk is

I'm not sure of EXACTLY what happened here, but it was probably caused by one of two factors:

(Primary) One of the many details the symbolication handles is sanitizing files paths inside crash reports, primarily to remove any path that might be privacy sensitive. The details of that process can be quite involved and it's possible/likely that there are cases where it sanitizes data out that it didn't HAVE to.
(Secondary) For complicated reasons that I can't easily summarize, determining the exact path for a crashed process can be harder than it sounds. It's a situration where the "standard" approach works most of the time, followed by a bunch of weird edge cases that don't quite work. There's code in place that uses other APIs to cover those edge cases, but that "constructed" path can end up constructing paths like the one you're seeing.

In this particular case, I think this is an accidental side effect of unrelated checks inside #1. Arguably that's a bug, however, the EXACT path (particularly for system components) isn't all that relevant to the crash investigation process so it doesn't really matter. The basic "job" of the sanitization process is to remove any data while preserving enough information to determine the crashes basic "source" ("RemotePairing.framework") and what part of the system hierarchy it came from ("/Library/Apple"). As long as those to factor are met, hiding "too much" isn't really an issue.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

0