Adam rightfully pointed out that we shouldn't use the kernel architecture in SAS as one can run an i386 package on an am64 (i. e. x86_64) kernel. We don't have access to the package architecture at the point when we generate the SAS yet though, so we could just use readelf.
However, thinking about it again: There is indeed not a compelling reason to include it in the first place. Initially I added it to make it easier to see which SAS comes from which architecture in a duplicate db. But on errors we always have the Architecture and Uname fields for every report anyway, so this information is still available. I also thought we needed it for disambiguating different crashes, but I guess the probability that two different crashes on two different architectures cause the exact same sequence of addresses in the same libraries is negligible. So I'd instead just like to simplify this by dropping the architecture from the SAS field altogether. This should be ok as we can allow some jitter in them: There has always been a many-to-one relation from SAS to a symbolic stack trace signature (i. e. an unique error), so the only thing that this causes is that at the transition every crash duplicate needs one more core dump uploaded and processed. But at the same time we also identify SASes from the same package architecture on different kernels, which may make up for this a bit. :-) -- 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
