1330013 - Fix incorrect symbol file paths in Firefox Linux builds

Status: RESOLVED FIXED

(Toolkit :: Telemetry, defect, P3)

Description

[Georg Fritzsche [:gfritzsche]]

Bug 1299773 ran into the issue that the symbol path from ... is "/home/<user>/firefox/libxul.so", but the symbol server expects it to be just "libxul.so".

This apparently happens with both the Ubuntu package and the official Mozilla Linux build.

The module information comes from MozStackWalk() here:
https://dxr.mozilla.org/mozilla-central/rev/7011ed1427de2b6f075c46cc6f4618d3e9fcd2a4/toolkit/components/telemetry/Telemetry.cpp#525

Then later we get the module paths here:
https://dxr.mozilla.org/mozilla-central/rev/7011ed1427de2b6f075c46cc6f4618d3e9fcd2a4/toolkit/components/telemetry/Telemetry.cpp#2928

So it seems we should either fix the profiler addon or do the path fixup on all platforms.

Comment 1

[Georg Fritzsche [:gfritzsche]]

(In reply to Georg Fritzsche [:gfritzsche] from comment #0)
> So it seems we should either fix the profiler addon or do the path fixup on
> all platforms.

Gabriele, do you know about this and could advise? Or do you know who can?

Comment 2

[Gabriele Svelto [:gsvelto]]

I'm not super-familiar with the profiler but for regular crashes symbols never use the absolute path for libxul.so (i.e., it's just libxul.so) so my gut feeling is that we should fix the profiler add-on. That being said Ted might know more so I'm needinfo'ing him too.

Comment 3

[(not currently active) Ted Mielczarek]

I'm not totally sure about the profiler bits. I think for local builds it can pull symbols from the files on disk, so having the full path there makes sense. If it's sending requests to the snappy server then it definitely wants just the filename at that point.

Comment 4

[Georg Fritzsche [:gfritzsche]]

Talking to mstange on IRC, the profiler is collecting stacks in "tools/profiler/core/GeckoSampler.cpp".
This uses `SharedLibraryInfo` and needs the full path for local developer builds.
So, we should leave `SharedLibraryInfo` alone.

We can however fixup the path in Telemetry.cpp for all platforms as the profiler is not affected by that.

Comment 5

[Iaroslav Sheptykin]

Attachment: Bug 1330013: Correcting module names for captured stacks.

Review commit: https://reviewboard.mozilla.org/r/103990/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/103990/

Comment 6

[Georg Fritzsche [:gfritzsche]]

Comment on attachment 8825933 [details]
Bug 1330013: Correcting module names for captured stacks.

https://reviewboard.mozilla.org/r/103990/#review104858

::: toolkit/components/telemetry/Telemetry.cpp:2932
(Diff revision 1)
>  #ifdef MOZ_ENABLE_PROFILER_SPS
>    for (unsigned i = 0, n = rawModules.GetSize(); i != n; ++i) {
>      const SharedLibrary &info = rawModules.GetEntry(i);
>      const std::string &name = info.GetName();
>      std::string basename = name;
> -#ifdef XP_MACOSX
> +#if defined(XP_MACOSX) || defined(XP_LINUX)

We should check if Windows builds have the same problem.

Comment 7

[Georg Fritzsche [:gfritzsche]]

Comment on attachment 8825933 [details]
Bug 1330013: Correcting module names for captured stacks.

https://reviewboard.mozilla.org/r/103990/#review104862

::: toolkit/components/telemetry/Telemetry.cpp:2932
(Diff revision 1)
>  #ifdef MOZ_ENABLE_PROFILER_SPS
>    for (unsigned i = 0, n = rawModules.GetSize(); i != n; ++i) {
>      const SharedLibrary &info = rawModules.GetEntry(i);
>      const std::string &name = info.GetName();
>      std::string basename = name;
> -#ifdef XP_MACOSX
> +#if defined(XP_MACOSX) || defined(XP_LINUX)

Alessio confirmed that we don't see the same issue on Windows.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7dd21e62c1f8
Correcting module names for captured stacks. r=gfritzsche

Comment 9

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/7dd21e62c1f8