<!-- The first four sections: "Problem to solve", "Intended users", "User experience goal", and "Proposal", are strongly recommended, while the rest of the sections can be filled out during the problem validation or breakdown phase. However, keep in mind that providing complete and relevant information early helps our product team validate the problem and start working on a solution. --> ### Problem to solve Fuzz testing today reports crashes with the raw information produced. This includes stack traces and raw memory addresses (such as `0x6008293`) to point to where crashes occurred. Users very much care about where in their code a crash occurred, but raw memory addresses are difficult to read and understand. They can also potentially change from one test to the next if certain operating system or application settings are in use (such as [Address Space Layout Randomization](https://en.wikipedia.org/wiki/Address_space_layout_randomization)) ### Intended users * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) * [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst) ### User experience goal <!-- What is the single user experience workflow this problem addresses? For example, "The user should be able to use the UI/API/.gitlab-ci.yml with GitLab to <perform a specific task>" https://about.gitlab.com/handbook/engineering/ux/ux-research-training/user-story-mapping/ --> Our goal with this feature is to provide the user more information to easily identify their next step to address and and resolve the crash. Our goal is to reduce frustration and the amount of time to go from a fuzz testing result to having a fix for the underlying issue. ### Proposal <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> When presenting fuzz test crash locations, present a _re-symbolicated_ crash location rather than the raw hex address. `Re-symbolicated` means a human-readable location that corresponds to the source code location. Generate the metadata needed to do this by default as part of a fuzz testing job, rather than requiring a user to take an additional step. #### Scope Focus on C, C++, Go, Swift, Rust, and Java languages. ### Further details <!-- Include use cases, benefits, goals, or any other details that will help us understand the problem better. --> The metadata needed to do this can generally be exported when building the app as a map file, then the map file used for doing symbol lookup. Consider the two stack traces below for the same example application. One is listing only raw addresses and the other has been re-symbolicated to indicate the precise crash location. In our fuzz testing screens, we should show symbolicated results, as in the second image, rather than raw hex addresses as in the first image. #### With no symbolication  #### With symbolication  Note how this example clearly calls out `main.c:5:34`. That is immediately actionable by developers, since they can open the `main.c` file, and go to line 5, column 34 to find the crash. #### Other languages: https://gitlab.com/gitlab-org/gitlab/-/issues/224518