When we enumerate the libraries that are loaded in the libraries on Linux and Android, we call `getId(filename)` for each library in order to obtain the ELF build ID of the library. `getId` reads the file from disk: https://searchfox.org/mozilla-central/rev/eb554e155a28ad36aca62281406757833b9c467a/tools/profiler/core/shared-libraries-linux.cc#73-86 ```cpp // Get the breakpad Id for the binary file pointed by bin_name static nsCString getId(const char* bin_name) { using namespace google_breakpad; PageAllocator allocator; auto_wasteful_vector<uint8_t, kDefaultBuildIdSize> identifier(&allocator); FileID file_id(bin_name); if (file_id.ElfFileIdentifier(identifier)) { return IDtoUUIDString(identifier); } return ""_ns; } ``` This is problematic in two cases: - If the file has changed between being loaded in our process and now, then we get the ID of the new file but we want to have the ID of the old file. This means we can get bad symbols (bug 773890). - In child processes with restrictive sandboxes such as the GMP process, the file read is disallowed (bug 1770905). This means that we cannot get the ID with the current implementation, and then we cannot symbolicate stacks. Instead, we should get the ID from memory. We can get the base address where the library is loaded, so we should be able to parse the ELF commands in memory and find the build ID note.
Bug 1773313 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
When we enumerate the libraries that are loaded in the libraries on Linux and Android, we call `getId(filename)` for each library in order to obtain the ELF build ID of the library. `getId` reads the file from disk: https://searchfox.org/mozilla-central/rev/eb554e155a28ad36aca62281406757833b9c467a/tools/profiler/core/shared-libraries-linux.cc#73-86 ```cpp // Get the breakpad Id for the binary file pointed by bin_name static nsCString getId(const char* bin_name) { using namespace google_breakpad; PageAllocator allocator; auto_wasteful_vector<uint8_t, kDefaultBuildIdSize> identifier(&allocator); FileID file_id(bin_name); if (file_id.ElfFileIdentifier(identifier)) { return IDtoUUIDString(identifier); } return ""_ns; } ``` This is problematic in -two- three cases: - (*New:*) When using AAB builds on Android without "legacy packaging", there is no uncompressed libxul.so on the disk to read the ID from. We have switched to legacy packing in bug 1865634 to keep build ID reading working. (Bug 1867280 tracks not using legacy packaging.) - If the file has changed between being loaded in our process and now, then we get the ID of the new file but we want to have the ID of the old file. This means we can get bad symbols (bug 773890). - In child processes with restrictive sandboxes such as the GMP process, the file read is disallowed (bug 1770905). This means that we cannot get the ID with the current implementation, and then we cannot symbolicate stacks. Instead, we should get the ID from memory. We can get the base address where the library is loaded, so we should be able to parse the ELF commands in memory and find the build ID note.
When we enumerate the libraries that are loaded in the libraries on Linux and Android, we call `getId(filename)` for each library in order to obtain the ELF build ID of the library. `getId` reads the file from disk: https://searchfox.org/mozilla-central/rev/eb554e155a28ad36aca62281406757833b9c467a/tools/profiler/core/shared-libraries-linux.cc#73-86 ```cpp // Get the breakpad Id for the binary file pointed by bin_name static nsCString getId(const char* bin_name) { using namespace google_breakpad; PageAllocator allocator; auto_wasteful_vector<uint8_t, kDefaultBuildIdSize> identifier(&allocator); FileID file_id(bin_name); if (file_id.ElfFileIdentifier(identifier)) { return IDtoUUIDString(identifier); } return ""_ns; } ``` This is problematic in ~two~ three cases: - (*New:*) When using AAB builds on Android without "legacy packaging", there is no uncompressed libxul.so on the disk to read the ID from. We have switched to legacy packing in bug 1865634 to keep build ID reading working. (Bug 1867280 tracks not using legacy packaging.) - If the file has changed between being loaded in our process and now, then we get the ID of the new file but we want to have the ID of the old file. This means we can get bad symbols (bug 773890). - In child processes with restrictive sandboxes such as the GMP process, the file read is disallowed (bug 1770905). This means that we cannot get the ID with the current implementation, and then we cannot symbolicate stacks. Instead, we should get the ID from memory. We can get the base address where the library is loaded, so we should be able to parse the ELF commands in memory and find the build ID note.