The address signature isn't built during retracing, but directly on the
affected machine when Apport post-processes the initial crash file. It's
used for client-side detection of duplicates and for uploading to
whoopsie, so it would be entirely useless to only generated it in the
data center during retracing (then we don't need it at all, we can just
use the symbolic stack trace). There is nothing else than os.uname()
that we can use at this point -- add_os_info() does the same but is
called *at the same time* (during initial processing by apport), so
replacing it with report['Architecture'] would behave exactly the same.
To ensure that I understand how you run into this -- are you trying to
generate an SAS for crashes which previously had a broken one due to the
gdb bug? In this case we could replace os.uname() with
report['Architecture'] to make things easier for you. But this shouldn't
matter on a "normal" crash/process/upload/retrace cycle, right?
** Changed in: apport (Ubuntu)
Importance: Critical => Low
** Changed in: apport (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1336565
Title:
apport-retrace generates a different StacktraceAddressSignature
depending on retracing architecture
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1336565/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
