Comment 3 for bug 1507711

On Tue, Oct 20, 2015 at 07:25:58AM -0000, Martin Pitt wrote:
> Ignoring the topmost function seems a bit dangerous to me, as it's
> usually the most important one. Imagine if the second and third etc.
> frames are only things like g_main_loop_process_event(), g_main_run(),
> and main(), and the topmost one is the particular callback. So entirely
> ignoring the first frame could easily lead to unifying crashes which are
> different.
>
> What is the rationale for this? I. e. as it's coming from you Brian I
> suppose this is somehow related to whoopsie and errors.u.c. Don't we use
> the StacktraceAddressSignature for duplication anyway, as that's pretty
> much always available (albeit an N:1 mapping)? What happens if there is
> an SAS, but no DuplicateSignature because of a missing/broken first
> frame?

Yes, we use the StacktraceAddressSignature for duplication. If there is
a SAS, but no DuplicateSignature then the DuplicateSignature is
failed:SAS. This can be seen in the following error:

https://errors.ubuntu.com/oops/52b2224c-6dbf-11e5-a87d-fa163e78b027

Notice how the Problem is just the SAS with failed: prepended.

> Depending on what we need this for, we could potentially be more clever
> here -- e. g. if we have 4 "named" frames, and the topmost one is ??, we
> could change the topmost one to be in the format of SAS, i. e.
> library+offset (based on the stack address). So instead of just having
> ?? we could have a "hybrid" DuplicateSignature like
>
> /lib/x86_64-linux-
> gnu/libc-2.19.so+36f79:connect_to_socket:wl_display_connect:_gdk_wayland_display_open:main()
>
> i. e. if your use case does not depend on having function names but you
> treat the DuplicateSignature as an opaque blob, that'd be fine.

Yes, the DuplicateSignature is just treated as an opaque blob.

--
Brian Murray