Need a method to ask for a core file for a failed to retrace crash
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| | Daisy |
Medium
|
Unassigned | ||
Bug Description
seb128 brought up the following crash about gnome-disk-utility, https:/
Even if the ddeb were to become available, we would not ask for a core file from another system experiencing this crash because the StacktraceAddre
It'd be useful if we could ask for the core file from the next crash with this SAS, or for any SAS for that matter.
| Brian Murray (brian-murray) wrote : | #1 |
| Brian Murray (brian-murray) wrote : | #2 |
It took a couple of days for another crash to come in, or for the amd64 retracers to get to a crash with the same SAS. But we eventually retraced it and now the SAS is part of a different crash signature.
indexes_
This ends up being the following problem:
One which had already been successfully retraced with the previous version of the package. Unfortunately, we still 60 instances of this crash that are in the original bucket, but this is a start.
| Brian Murray (brian-murray) wrote : | #3 |
Sebastien - You brought this matter up the other day regarding a gnome-disk-utility crash and I wanted to let you know it's been retraced now.
| Sebastien Bacher (seb128) wrote : | #4 |
thanks!
| Changed in daisy: | |
| importance: | Undecided → Medium |
| Brian Murray (brian-murray) wrote : | #5 |
I manually removed some SASes from the index again for compiz in vivid which had an SRU done to get debug symbols.
$ ./remove-
SAS removed from crash_signature index.
$ ./remove-
SAS removed from crash_signature index.
$ ./remove-
SAS removed from crash_signature index.
$ ./remove-

I removed one of the SAS from the 'crash_ signature_ for_stacktrace_ address_ signature' row from the indexes table to see if that'll get us a core file which will then be retraced.