fix StacktraceAddressSignatures for frames without addresses
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Apport |
Confirmed
|
Medium
|
Brian Murray |
Bug Description
When adding gdb information to a report that is being retraced, the function crash_signature
1246 For signal crashes this the concatenation of ExecutablePath, Signal
1247 number, and StacktraceTop function names, separated by a colon. If
1248 StacktraceTop has unknown functions or the report lacks any of those
1249 fields, return None. In this case, you can use
1250 crash_signature
1251 based on addresses instead of symbol names.
I discovered this when trying to figure out why bug 1532722 didn't appear to have retraced. From the retracer log files:
./e-t-retracer-
./e-t-retracer-
./e-t-retracer-
Related branches
- Martin Pitt (community): Disapprove
-
Diff: 22 lines (+5/-1)1 file modifiedapport/report.py (+5/-1)
Changed in apport: | |
status: | Incomplete → Confirmed |
Changed in apport: | |
importance: | Undecided → Medium |
assignee: | nobody → Brian Murray (brian-murray) |
What is the exact issue here?
> the function crash_signature _addresses is used to create the StacktraceAddre ssSignature.
Yes, but that's not a bug, but by design. This is being used for client-side (whoopsie) duplicate detection, and we can't rely on a "real" crash signature on the client side. The retracer on the other hand should stop looking at SAS once it figured out a crash_signature(). We should not muddy the semantics of SAS by sometimes putting in different information.
Can you please explain what the real issue is here? I figure we need to change something in apport-retrace or crashdb.py, but I don't think this should change the behaviour of user boxes that report crashes.
Thanks!