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)
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.
| Reporter | ||
Comment 1•5 years ago
|
||
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.
Description
•