Hello everyone,
With the latest release of the Memory Profiler Package, version 0.1.0-Preview.7, we’ve added a pop-up notification to alert you that your Memory Profiler snapshot files contain a full copy of the managed heap. This aspect of the Memory Profiler snapshot feature might not have been obvious so we have updated our documentation with more detailed information on the potential contents of these files.
We treat snapshot files sent in with bug reports confidentially. However, we have no control over how you choose to share these snapshots and thought it’d be best to map out potential issues in more detail as well as indicate what’s possible via the new pop-up notification.
As the newly Updated documentation now states:
The memory snapshots you take with the Memory Profiler UI or the Memory Profiler API contain the entire contents of the managed heap of the Player or Editor instance you are capturing.
You can see most of the data through the Memory Profiler UI in this package with the exception of managed allocations that do not have a garbage collection handle. These allocations might be related to Mono type data, leaked managed data, or allocations that the garbage collector has already collected and released but the memory section they were located in hasn’t been overwritten with new data. The latter happens because garbage-collected memory is not “stomped” for performance reasons.
The kind of data that you can explore in areas such as the All Managed Objects view gives you an idea of what data could be included in the memory snapshot. Any object instance of a class, all fields on that object, as well as the class’ statics excluding literals such as const values are included.
Fields are stored depending on the data type: Value types are stored by their value, and reference types are stored as pointer addresses. The UI resolves any pointer address as a link to the object the address points to.
For example, string type fields might indicate via their name what the string they are pointing to means. So searching for a field named “Password”, “Credentials” or “Token” could identify strings with sensitive data. However, if the object that points to the string, or even the string itself has been garbage collected, the data might still be there, but is no longer easily identifiable, unless you have a rough idea what you’re looking for or part of the string value to search for.
Note: The above section only mentions string data as potentially problematic, however, this issue is not exclusive to strings and could come in other forms as well, including as field or type names.
One way to safeguard against accidentally disclosing personally-identifying information, credentials or similar confidential data when you share snapshot files outside of your teams, is to put that data into constant fields. Constant fields bake that data into the binary executable, which is not captured by the Memory Profiler. However, be aware that a binary executable might be de-compiled by users and expose the data that way.
Taking a memory snapshot is currently only possible in development Players, so these fields could be non-const in release builds, which will make it trickier to get to the data, albeit not entirely impossible.
If you have any further questions regarding this topic, please let us know.
2 Likes
