Drop the offset from the signature for .so crashes like we do .dlls
Categories
(Socorro :: Signature, task, P2)
Tracking
(Not tracked)
People
(Reporter: jrmuizel, Assigned: willkg)
References
Details
Attachments
(1 file)
Bug 1218607 has a bunch of different signatures but we want them all in the same bucket. I believe we did something like this for dlls in bug 1515487.
|
Assignee | |
Comment 1•4 months ago
|
||
What has two thumbs and did the dll work 6 years ago and completely forgot? :thumb: this socorro engineer!
I'll take this. I can do what we did with dlls.
Example problematic crash reports:
- 46011b6c-0bf2-4f2a-a2a0-7ced10240505
- 20a0196b-df05-4cae-8222-dec560240504
|
|
Assignee | |
Comment 2•4 months ago
|
||
The signature code actually adds the @0xnnnnnn bit to the frame symbol for frames where there is a module, but no function symbol. Given that we want to drop the @0xnnnnnnn for .dll and .so frames, I think I may remove that code. Further, I'm adding .so to the "let's drop repeating frames" code.
Here are some interesting consequences of those two changes:
app@socorro:/app$ socorro-cmd signature 46011b6c-0bf2-4f2a-a2a0-7ced10240505
Crash id: 46011b6c-0bf2-4f2a-a2a0-7ced10240505
Original: libGLESv2_adreno.so@0x11dc50
New: libGLESv2_adreno.so
Same?: False
Crash id: c99eac85-479f-4c75-8fc9-8d91f0240506
Original: libgdk-3.so.0@0x5e360
New: libgdk-3.so.0
Same?: False
Crash id: a1fbe752-1002-4ea6-8894-445b20240506
Original: libxul.so@0x556573f | libxul.so@0x818069f | libxul.so@0x96333ff | libxul.so@0x5565c02 | libxul.so@0x5565cc4 | libxul.so@0x5575105 | libxul.so@0x5553319 | libxul.so@0x963f03f | libxul.so@0x5559f5c | clock_gettime@@GLIBC_2.17
New: libxul.so
Same?: False
Crash id: 5393413c-ec8f-4b36-9e6a-4d7bb0240506
Original: (unloaded windows.storage.dll@0xff734) | tmmon64.dll | <unknown in ntdll.pdb>
New: (unloaded windows.storage.dll) | tmmon64.dll | <unknown in ntdll.pdb>
Same?: False
Jeff: How does that look?
Gabriele: Do you think these are ok changes to make?
|
||
Comment 3•4 months ago
|
||
Yes! I often find myself adding lots of different signatures under the same bug which is a chore and usually causes us to underestimate the volume of a bug (see bug 1773125 for example). The only downside of this is that it will probably cause some unrelated signatures to merge, but IMHO that's a good thing because they'll be more visible and force us to find the symbols we're missing so that we can tell them apart.
|
|
Assignee | |
Comment 4•4 months ago
|
||
|
Reporter | |
Comment 5•4 months ago
|
||
(In reply to Will Kahn-Greene [:willkg] ET needinfo? me from comment #2)
Jeff: How does that look?
Looks good to me. Presumably this will also effect .dylib files too?
|
|
Assignee | |
Comment 6•4 months ago
|
||
Yes. With the changes in PR 6610, we get this:
app@socorro:/app$ socorro-cmd signature cd7a425f-38cc-4649-bc8b-a36ef0240507
Crash id: cd7a425f-38cc-4649-bc8b-a36ef0240507
Original: libcryptoki.4.1.4.dylib@0x14580
New: libcryptoki.4.1.4.dylib
Same?: False
|
|
Reporter | |
Comment 7•4 months ago
|
||
Cool
|
|
Assignee | |
Comment 8•4 months ago
|
||
|
|
Assignee | |
Comment 9•4 months ago
|
||
Once this autodeploys to our stage environment (give it an hour), we'll start seeing the outcome of the changes. I'll wait for interesting things there to make sure I understand the change.
When we do a prod deploy, I'll notify stability and crashreporting-wg so everyone has a heads-up about the change because it is a fundamental change to signature generation.
|
|
Assignee | |
Comment 10•4 months ago
|
||
I sent an fyi email to stability and crashreporting-wg mailing lists earlier today.
I did a prod deploy just now in bug #1896001. Looks like this is working. If we see any issues, we can reopen this bug or open a new depending on the circumstances. Marking as FIXED.
Description
•