Closed Bug 1382325 Opened 8 years ago Closed 5 years ago

The symbol dumps don't seem to contain sections for "function.cold.number" functions

Categories

(Socorro :: Symbols, task)

All
Linux
task
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: mstange, Unassigned)

Details

Here's a profile from a linux64 nightly: https://perfht.ml/2tPVgkV If you collapse the mozilla::PresShell::HandleEvent node, you can see a node for ComputeWhereToScroll under it which calls mozilla::PresShell::HandleEvent inside it. However, this makes no sense; ComputeWhereToScroll contains no such call. This problem is caused by incomplete information in the breakpad symbol dump of the libxul.so from this build: https://tools.taskcluster.net/groups/bY1ZO7i5SBiev_Y7BUsP0w/tasks/UYPg5QgrRO6cNq5QBkToqw/runs/0/artifacts The symbol dump for libxul.so is at http://symbols.mozilla.org/libxul.so/2766DE43E8F5506063461E03577B988C0/libxul.so.sym . Specifically, the problem is that addresses between 0x1e3c402 and 0x1e3e0ec get assigned to ComputeWhereToScroll instead of to mozilla::PresShell::HandleEvent. Here's what the symbol dump has to say about that range: > FUNC 1e3c30d cf 0 ComputeWhereToScroll > 1e3c30d 1a 3366 6203 > 1e3c327 6 3370 6203 > 1e3c32d 5 3371 6203 > 1e3c332 5 3374 6203 > 1e3c337 c 3377 6203 > 1e3c343 28 3384 6203 > 1e3c36b 11 90 10749 > 1e3c37c f 3385 6203 > 1e3c38b 4 3386 6203 > 1e3c38f 4 3385 6203 > 1e3c393 4 3386 6203 > 1e3c397 15 90 10749 > 1e3c3ac 3 3388 6203 > 1e3c3af a 3390 6203 > 1e3c3b9 4 3391 6203 > 1e3c3bd e 3393 6203 > 1e3c3cb 3 3390 6203 > 1e3c3ce 3 3391 6203 > 1e3c3d1 b 3393 6203 > FUNC 1e3e0ec 72 0 mozilla::AccessibleCaretEventHub::HandleEvent > 1e3e0ec 6 484 6194 > 1e3e0f2 7 481 6194 You can see that it does not contain any information about addresses between 1e3c3d1 and 1e3e0ec. Here's the output of nm around those addresses: > 0000000001e3bf4c t _ZN7mozilla9PresShell23ScrollFrameRectIntoViewEP8nsIFrameRK6nsRectN12nsIPresShell10ScrollAxisES7_j.cold.622 > 0000000001e3c30d t _ZL20ComputeWhereToScrollsiiiiiPiS_ > 0000000001e3c3dc t _ZN7mozilla9PresShell6FreezeEv.cold.623 > 0000000001e3c3e0 t _ZN7mozilla9PresShell15SetCaretEnabledEb.cold.624 > 0000000001e3c402 t _ZN7mozilla9PresShell11HandleEventEP8nsIFramePNS_14WidgetGUIEventEbP13nsEventStatusPP10nsIContent.cold.625 > 0000000001e3e0ec t _ZN7mozilla23AccessibleCaretEventHub11HandleEventEPNS_11WidgetEventE > 0000000001e3e15e t _ZN12nsIPresShell26SetPointerCapturingContentEjP10nsIContent You can see that, unlike in the breakpad symbol dump, here we have three functions between ComputeWhereToScroll and AccessibleCaretEventHub::HandleEvent: - mozilla::PresShell::Freeze() (.cold.623) - mozilla::PresShell::SetCaretEnabled(bool) (.cold.624) - mozilla::PresShell::HandleEvent(nsIFrame*, mozilla::WidgetGUIEvent*, bool, nsEventStatus*, nsIContent**) (.cold.625) So nm knows about the entry of mozilla::PresShell::HandleEvent, which is the one we care about here. It looks like the breakpad symbol dumper on Linux just ignores these .cold.* functions completely. Fixing this would make profiles from Linux less misleading.

I don't see any .cold symbols in recent libxul.so binaries, maybe due to a compiler change.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.